-JP
--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Hi,
Why not use the 'password' lookup plugin (with_password or {{ lookup('password',...) }}) or 'file' lookup plugin? This way all confidential variables can be stored in a directory 'credentials' and either you do not commit them at all (the ones who have it could use it) or use .zip/.rar with password or encrypted loopback image and commit the encrypted archive?
Greetings,
gw
--
secret_vars:
- mysql_root_password
- some_api_key
mysql_root_password: mykey!cXd5OGduMzQ1MjM0I2VyQCMmXiozNGdRVyM=
some_api_key:
anotherkey!M2N2OTIzNDVqdm5zZGZnOTVmcmU5NTR2ei8jIw==
[shared_key_mykey]
cipher=AES
keyfile=/path/to/mykeyfile
[shared_key_anotherkey]
cipher=DES
keyfile=/path/to/anotherkeyfile
I generally am not a fan of lookup plugin syntax, especially when it has to return a data structure. It's fine for some things, but the main intention of lookup plugins were to enable things like "with_items" and then they got used for things like file lookups later, and the syntax is ok... but it's something I find myself using rarely.
I really like the vault idea because it would work transparently with vars_files and other things, and *not* require extra syntax.
I am tentatively thinking
ansible-vault --unlock <path>ansible-vault --lock <path>
And then when ansible runs if a vault is used, it would prompt for the unlock password for that vault.
The question is do you need multiple vault passwords at the same time or not.
[vault_main]
path=/path/to/vaults/main
[vault_custom]
path=/path/to/vaults/custom
password_file=/path/to/vault_passwords/custom
cipher=Twofish
The other slight thing is you want to make sure none of your files get checked into git while locked down though, which might be a little tricky... I would hate to have to have people to know how to set up git triggers for this, but that might be the only way.
--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
-JP
On Mon, 1 Jul 2013 16:19:45 +0200, Jan-Piet Mens wrote:
I'm also finding the interface somewhat confusing because it's still using lookup plugins (which I asked that it not),I don't understand. It's a Jinja2 filter. Where's the lookup plugin? (Maybe I'm confusing the terminology.)
But it could probably be simply rewritten to be a lookup plugin, right?
To me the most obvious approach that doesn't add new concepts is to use it as a lookup plugin and storing passwords in individual files, exactly how the password lookup plugin does it. So you would put in your inventory things like:
mysql_password: "{{ lookup('decrypt', 'credentials/path/to') }}"
Although this is pretty similar to what can be done with this Jinja2 filter (if I'm not mistaken):mysql_password: "{{ lookup('file', 'credentials/path/to')|vault }}"
After thinking about this.. Actually all lookup plugins could have 1:1 mapping with Jinja2 filters, like this:
{{ mysql_config_file|file }}
{{ "mysql/mysqld.conf"|file }}
{{ user_password_path|password }}{{ lookup('XXX', YYY) }} --> {{ YYY|XXX }}{{ "credentials/user_password"|password }}{{ mysql_password_file|file|vault }}
This would look much nicer and more intuitive to use, or not? Thoughts?
Greetings,
gw
--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Most vars will not be encrypted. This is meant as a protection to vars
which contain sensitive data -- basically clear-text passwords that
nobody wants to have floating around in files that get added to
repositories, etc.
I don't think encrypting vars files completely is useful: makes things
like `grep', and `diff' impossible to use.
On the other hand, allowing more than a single key is useful in
multi-tenant situations, but more than a single key is not required.