Securely Storing Personal Credentials for Ansible Without Compromising Convenience

Get Help
,
1

Hello Ansible Community,

I’m encountering a challenge in managing personal authentication credentials (like Active Directory and vCenter logins) in my Ansible project, which is located on a shared, Proof of Concept (POC) Ansible server in my home directory. My goal is to secure these credentials in a way that they are not easily decrypted by others with sudo access, while also avoiding manual entry for each playbook execution.

Currently, I’m considering the following approaches:

  1. Using a password-protected Ansible Vault file: This method seems secure, but it’s causing issues with Ansible-Lint as per this forum thread.

  2. Implementing PAM as suggested in the Redhat documentation: This appears to require extensive infrastructure setup (like trust relationships with AD and internal PKI), which is not feasible at the moment.

I’m seeking advice or alternative solutions that balance security with ease of use. How can I effectively manage personal credentials in this shared environment without extensive infrastructure changes?

Appreciate any insights or experiences you can share!

2

I suggest you have a look at git-secret which I believe can be characterized as an extension to git that facilitates storing secrets in git repos through gpg. (Not to be confused with the also useful git-secrets tool which preemptively scans for secrets in attempted git commits.)

I have no problem with ansible-vault style vaulted scalar variable values or whole files from a cryptographic standpoint. My tiny soap-box on the subject is that the class of secrets for which ansible-vault is appropriate is limited. We take the attitude that sooner or later both our repositories with vaulted secrets and our vault password(s) will be exposed. Therefore it makes sense to vault only those secrets which (a) are themselves ephemeral and which (b) can be easily changed — (a) because the repo will contain all prior values of a given secret in addition to the current one, and (b) because they will all need to be changed in short order in those circumstances.

For example, our repository for our backend single sign-on service necessarily holds keys generated by every subscribing service. If they were exposed, every service owner - hundreds at this point - would need to regenerate keys and coordinate their redeployment with the sso service owner. That’s a huge undertaking, which alone under (b) disqualifies it for vaulting. Instead the keys are managed with git-secret, and the deployment mechanism has gpg credentials - which are subject to repudiation - which can decrypt the service keys at the point they are installed on the sso server(s). Credential repudiation is crucial, and is something outside the scope of Ansible vault password management.

3 Likes
3

In addition to the info @utoddl just provided above, there are quite a bunch of other methods to manage sensible data apart from ansible-vault, which is actually pretty basic and doesn’t provide strong security measures such as MFA and so forth. However, some of them may not suit you, depending on your Ansible environment (are you running playbooks via CLI on the controller? Or else, are you using AWX / AAP?)

Anyway, I believe this is a great topic to discuss here, so I’ll give you several options and leave to you if those are a good fit.

On the one hand, there is the community.general.bitwarden lookup plugin which I have to tell, I’ve been wanting to try for the time being since I’m a big fan of Bitwarden (you can have your own hosted / private BW instance, aka Vaultwarden). This option has it’s limitations though (check-out the docs)

On the other hand, there is also the community.hashivault collection, which I’m itching to try but again, since I worked all this time on a very safe environment, I did not have the need to use. Also, I’m aware of the CyberArk namespace which include a couple of collections, but I wasn’t able to find a lot of documentation right now.

Now, the one method I’ve already tried on production and worked pretty well for me, is vCenter credential type on AWX / AAP.

Again, since you didn’t provide many details about your environment, I’m just shooting a few ideas into the air…

Well, summing-up, you might want to check these two ways to learn further about keeping sensitive data safe while running Ansible pb’s.

1. On CLI / TUI → You could use different types of lookup plugin to get the job done (most of them already on the community namespace)

2. On AWX / AAP → In addition to (1) check out the AAP’s credentials documentation, see if there is anything that could save the day for you.

See you around!

3 Likes
4

Another possible solution is to use SOPS together with the community.sops collection. SOPS allows you to encrypt values and comments in YAML, JSON, INI, .env files, while keeping the keys readable. (It can also encrypt binary files, though since it uses Base64 this is not a good idea for huge files.)

You can use SOPS with GPG and AGE keys, or with keys from several cloud KMSes like AWS KMS, GCP KMS, Azure Key Vault. Using GPG and AGE allows you to work completely offline (so you’re not depending on some service).

I personally prefer SOPS over Ansible Vault, and I think SOPS scales better for small teams since you don’t have to exchange the password, but instead only exchange public keys. I have no idea how well it works with larger teams that need to access secrets; vault services (like HashiVault, BitWarden, etc.) might be better suited for these situations, also since they have more flexible access control.

(Disclaimer: I’m maintaining community.sops and since some time I’m also helping maintaining sops itself, so I’m kind of biased :slight_smile:)

3 Likes
5

How would this look in terms of configuration and usage?
I’m currently using Ansible in an ad-hoc manner from a server opposed to AWX/Tower.

My goal is to have a set of credentials, personal and directly tied to myself, that ansible can pull from for specific tasks such as authenticating to vCenter or running configurating tasks on windows workstations using my Active Directory Domain account.
I want those to be local to my profile, NOT shared or accessible to the team, but have been running into some challenges doing that.
My current approach is to have ansible-playbook prompt me for the password that unlocks my personal credentials file that’s read via vars_file, however ansible-lint does not seem to like this, and is unable to parse anything in playbooks I’ve done this in.

I’m trying to avoid storing the encrypted content AND decryption key/passphrase within my profile, so my criteria would be.

  • Decryption key cannot be stored locally on the host.
  • Decryption key cannot be visible in command shell history.
6

Hello @gawainsr,

Let’s recap our discussion a bit:

You’ve expressed a preference for maintaining a balance between security and ease of use, aiming to manage personal credentials within a shared environment without making extensive infrastructure changes, as mentioned in your earlier post:

Given this, it seems you’re inclined to proceed with the ansible-vault method, despite considering alternative options previously suggested to you, is that correct?

On the other hand, you’ve also set specific constraints regarding the use of ansible-vault:

Considering these constraints, the safest and most user-friendly way I can think of is to temporarily store your vault password in volatile memory (environment variable), so it doesn’t stick around after logging-out of your session or a reboot. You could set this up to kick in when you log in and wipe it from memory when you log out, maybe using something like a .profile setup and so on (I remember using a similar approach with ansible-navigator, which should also work similarly for ansible-playbook CLI command). Here’s a link to the ansible-navigator docs that might help (notice that it gives details on how to set-up the vault password on an environment variable while preventing storing it on the shell history):

Honestly, I can’t think of a better way to meet your needs just using ansible-vault right now. If anyone else has different ideas or improvements, I’m all ears! :blush:

1 Like
7

What I’ve ended up doing is using GPG and pass with a custom lookup to store the values, which gives me a fairly secure method for storing non-shared secrets.

1 Like
8

I had landed on using GPG and Pass along with a custom lookup to accomplish my needs.

1 Like
9

Nice! I believe that’s what @utoddl suggested you on the very first answer , right?

If that’s so, could you kindly tick the solved check on his answer so this thread appears as solved on the get-help category, please? Thanks a lot for the feedback also! :relieved:

10

Sort of it uses GPG as well but it stores everything in a local database opposed to within git. Pass is moreso the mechanism https://www.passwordstore.org/

1 Like