Mixes well with the host grouping concept, e.g. the tester person can use secrets in the test environment, but they can't use secrets in the prod environment.
Authorisation per secret, per environment, etc. Allow multiple developers to share ansible playbooks without having to share secret keys. encode the public RSA + encrypted AES key pair as special headers for encrypted files or variables, such that it's more seamless (but at the expense of really long encrypted variables, given each RSA key is typically 4KB!).ĭoing the above properly helps meet the following use cases: Similarly, when needing to change the value, a user can edit the decrypted version, and re-generate a random AES key, and re-using the list of public keys, re-encrypt the new AES key with all the other user's RSA public keys.Īlternatively, instead of using additional vault object of sorts, maybe try to manage the necessary metadata / keys with an embedded approach (this could be better than Chef vault which gets messy with broken references to encrypted data_bags, etc). When wanting to authorise other users/systems to be able to read the secret, the creator of the secrete can simply loop through all the RSA keys allowed to 'unlock' the secret. Then, when an authorised ansible user/system wants to 'unlock' that secret, they can decrypt the per variable AES key using their RSA private key. What gets stored in the vault item/metadata is a list of pairs, each pair being the RSA public key itself and the AES key encrypted with that RSA key. If one wants to permit many different people or hosts from 'unlocking' the same secret, then encrypt that same AES key with each individual's RSA public key. Ansible already leverages this for connections, so why not re-purpose it? Instead of leaving those AES key part in plaintext, the vault item/metadata protects each AES key with the user's (or service account's, e.g. A vault item/metadata of sorts (as advocated in a comment above, e.g.vault), can maintain a list of named variables/files, and contain the protected AES key to unlock it (will explain more now), thereby linking each key to the encrypted values it's able to decrypt. By using multiple AES keys, different secrets can unlocked by different people/systems, e.g. Every secret/file is encrypted with it's own AES shared key. And SSH public/private keys are already part of how ansible works (at least for Linux). Consider adding in use of asymmetric / public key crypto (which is how Chef Vault works, and in practise uses similar concepts to TLS/SSL/SSH). Originally, chef had the same "shared secret" issue where, if multiple people work on a project, sharing secrets introduces security risks. Right now, ansible-vault looks like it's stuck at the same base 'encrypted databag' feature level of Chef, and while simple, lags in terms of security options. They too needed a better solution to manage thier shared-secret encrypted databags. 
I can recommend looking at Chef Vault as an example. Reply to this email directly, view it on GitHub You are receiving this because you commented. Granted, it does not help with the prompts, but that's one way to address "knows" the vault-key association, no configuration necessary. Vault1.key and vault2.key, by convention ? That way, ansible-vault just Let's say I have two vault files, vault1.yml and vault2.yml, eachĮncrypted with a different key file.
#Peek a phone pirate vault password password#
On Tue, at 10:12 AM, Nicolas Moreau a little convention can help with the "which password for which I'm not sure how much this will matter when Ansible Tower is open sourced
Need to give it more thought if that would actually help us (with or without a restructuring). So the only use case for my situation might then be on group level. The idea of might have use, but in our case we generally already have split off dev, qa, stg, prd environments into multiple inventory files. If we can limit this by using at least the same variable evaluation as is currently in place, that will already help. I can see that idea of work, but I do worry about the case where someone with "lesser" access starts to deploy something and finds out halfway that it breaks due to some missing variable in another vault.
This allows you to keep some maintenance sanity when you can use grep -R or ag to scan a repository for variable use prior to a refactoring. One of the things we now use is variable files where we refer to vault variables with a vault_ prefix so you know that it will actually do a lookup in a vault file. Right now we have to work around this with a lot of inventory duplication and group_vars repeating. This would be extremely useful for where I work since we are frequently running into this problem as security audits and frameworks require us to separate dev/qa/stg/prd and limit access to those environments.
0 kommentar(er)
