How do you handle password rotation for local users?

Get Help
1

Hi all!

For most of our servers, we use an external IDM for managing our users and such. As a backup solution, we still have our root user in play but currently we’re not changing the password on an automated way. We’d prefer to find a way where the password isn’t stored within Ansible or on an external service (such as Hashicorp Vault).

What I have so far is; generating a random string, save this value to a location so it’s shown on console. After this I generate a password using the random seed and some other communicated string.

I’m not entirely happy with this solution so I’m curious how you guys handle password rotation. Do you use Ansible vault or external tools?

Thanks for your inspiration!

Eli

2

Hi there!

It’s a difficult matter, looking at my own experiences, I’m still working on the best approach for this. My design currently looks like this (it’s all in my head still, no systems/code to make it a reality, yet!):

  • The password vault (bitwarden, hashivault, w/e) holds the current up to date passwords for the host. All of them, root, sudo (for the ansible service account) etc.
  • The only means for Ansible to enter a machine is through an SSH key (the SSH server does not allow logging in with passwords), elevation is granted with a sudo password, individual for that machine.
  • Ansible maintains the local useraccounts with information gathered from the password store, on each run. This has an important chicken/egg situation, e.g. changing the sudo password for ansible needs to be updated on 2 systems.
  • I don’t want to see tasks that report a change on every run, so in the case of local linux users, passwords are set with a predetermined (static) salt

But I also know this isn’t the only solution (not to mention that not all services/software support ‘idempotent’ password changing). I’ve also played with the idea of having a service account for Ansible in IdM, but that has other drawbacks (no IdM, no elevation, unless it has been cached, a.k.a. it’s hairy)

However, depending on the situation you’re in, you could start with a playbook that will do the following:

  • Validate access to a system
  • Generate a new secret and save it to the vault (I know there’s a hashi module that can add info to a vault)
  • Set the secret on the target host

And I’d make this playbook do only this, nothing else, and have it fail early and hard.

3

Hi! Thanks for your ideas. I’ll let you know what I’ve come up with and share it here.