Ansible configuration policy for the private network/home lab of Dustin C. Hatch
http://dustin.hatch.name/
By default, `sudo` requires users to authenticate with their passwords before granting them elevated privileges. It can be configured to allow (some) users access to (some) privileged commands without prompting for a password (i.e. `NOPASSWD`), however this has a real security implication. Disabling the password requirement would effectively grant *any* program root privileges. Prompting for a password prevents malicious software from running privileged commands without the user knowing. Unfortunately, handling `sudo` authentication for Ansible is quite cumbersome. For interactive use, the `--ask-become-pass`/`-K` argument is useful, though entering the password for each invocation of `ansible-playbook` while iterating on configuration policy development is a bit tedious. For non-interactive use, though, the password of course needs to be stored somewhere. Encrypting it with Ansible Vault is one way to protect it, but it still ends up stored on disk somewhere and needs to be handled carefully. *pam_ssh_agent_auth* provides an acceptable solution to both issues. It is better than disabling `sudo` authentication entirely, but a lot more convenient than dealing with passwords. It uses the calling user's SSH agent to assert that the user has access to a private key corresponding to one of the authorized public keys. Using SSH agent forwarding, that private key can even exist on a remote machine. If the user does not have a corresponding private key, `sudo` will fall back to normal password-based authentication. The security of this solution is highly dependent on the client to store keys appropriately. FIDO2 keys are supported, though when used with Ansible, it is quite annoying to have to touch the token for _every task_ on _every machine_. Thus, I have created new FIDO2 keys for both my laptop and my desktop that have the `no-touch-required` option enabled. This means that in order to use `sudo` remotely, I still need to have my token plugged in to my computer, but I do not have to tap it every time it's used. For Jenkins, a hardware token is obviously impossible, but using a dedicated key stored as a Jenkins credential is probably sufficient. |
||
---|---|---|
.certs@13f97e4fa1 | ||
certs | ||
ci | ||
group_vars | ||
host_vars | ||
passwords/kojiweb_secret | ||
roles | ||
vars | ||
vault | ||
.gitignore | ||
.gitmodules | ||
.vault-secret.sh | ||
alertmanager.yml | ||
ansible.cfg | ||
ansible.yml | ||
aria2.yml | ||
base.yml | ||
bitwarden_rs.yml | ||
blackbox-exporter.yml | ||
burp-client.yml | ||
burp-server.yml | ||
certbot.yml | ||
collectd.yml | ||
dch-gw.yml | ||
dch-proxy.yml | ||
dch-root-ca.crt | ||
dch-vpn.yml | ||
dhcpcd.yml | ||
dhcpd.yml | ||
docker.yml | ||
domain-controller.yml | ||
dyngroups.yml | ||
facts.yml | ||
fileserver.yml | ||
firewalld.yml | ||
frigate.yml | ||
gitea.yml | ||
grafana.yml | ||
graylog.yml | ||
hassdb.yml | ||
homeassistant.yml | ||
hostname.yml | ||
hosts | ||
hosts.gw | ||
hosts.offline | ||
jellyfin.yml | ||
jenkins-slave.yml | ||
journal2ntfy.yml | ||
koji-builder.yml | ||
koji-hub.yml | ||
koji-web.yml | ||
koji.yml | ||
kube-root-ca.crt | ||
metricspi.yml | ||
minio.yml | ||
motioneye.yml | ||
named-server.yml | ||
net-ifaces.yml | ||
network.yml | ||
nextcloud.yml | ||
ntp.yml | ||
nut.yml | ||
postgresql.yml | ||
protonvpn.yml | ||
pxe.yml | ||
pyrocufflink.yml | ||
radius.yml | ||
radvd.yml | ||
remount.yml | ||
repohost.yml | ||
rngd.yml | ||
samba-dc.yml | ||
smtp-relay.yml | ||
squid.yml | ||
synapse.yml | ||
systemd-networkd.yml | ||
systemd-resolved.yml | ||
taiga.yml | ||
unifi.yml | ||
victoria-metrics.yml | ||
vmhost.yml | ||
websites.yml | ||
wheelhost.yml | ||
zabbix-agent.yml | ||
zabbix-server.yml | ||
zabbix.yml | ||
zezere.yml | ||
zigbee2mqtt.yml | ||
zwavejs2mqtt.yml |