2.4 support for multiple vault passwords, looking for feedback

641 views
Skip to first unread message

Adrian Likins

unread,
Jul 26, 2017, 10:09:50 AM7/26/17
to ansible...@googlegroups.com
I've been working on some vault related 2.4 roadmap[1] features,
namely "Support for multiple vault passwords. ".

The current pr is at https://github.com/ansible/ansible/pull/22756

The roadmap feature is based on RFE
https://github.com/ansible/ansible/issues/13243


Looking for feedback from vault users on the proposed interface and approach.


For convenience, I'll include the summary of the proposed changes from
https://github.com/ansible/ansible/pull/22756#issue-215127152 inline
here, but may be easier to read on the issue:




The main user facing changes are:

- Cli now supports a new '--vault-id' option that can specify a
password file or 'prompt'

     "ansible-playbook --ask-vault-pass --vault-id ~/dev_password
--vault-id prompt some_playbook.yml"

      - Will prompt for a vault password (it will ask for the
'default' password in this example)
      - Will read a password from ~/dev_password

      For example above, the ~/dev_password file would be tried first,
then the password from the prompt


- Cli now supports providing --vault-password-file multiple times

   "ansible-playbook --vault-password-file ~/dev_password
--vault-password-file ~/prod_password  some_playbook.yml"

  The default behavior is to try all of the specified vault
secrets/passwords in the order they were specified, until one work
  the new '--vault-id' option can be mixed in with the existing
--vault-password-file and --ask-vault-pass as well

- internally vault can add the vault-id label to the vault format

- vault format is rev'ed to 1.2
  (but anything that can read 1.1 format can read 1.2 as well)

- When decrypting a 1.2 format with a 'vault-id', the vault secrets
that match that vault id will be tried first

- The --vault-id option also allows specifying a vault id label and
the secret type

    "ansible-playbook --vault-id prod_keychain@prod_password_file
--vault-id stage_keychain@prompt some_playbook.yml"

   tTat will read ./prod_password_file and then prompt the user for
the password for the 'stage_keychain' vault id

- A playbook can have have vaulted files that uses different passwords
in the same 'ansible-playbook' run

- A playbook can have embedded vaulted variables with different
passwords in the same playbook (even in same file)

So a ansible project like:

           secrets/dev_password
           secrets/qa_password
           playbooks/
           playbooks/inventory   # encrypted with dev password
           playbooks/site.yml
           playbooks/vars/main.yml       # with multiple embedded
vars, each with a different password and/or vault id

dev_password would be loaded from file, and there will be an
interactive prompt for 'prod' vault_id/password



* Not quite done but close

  config option and/or cli option to enforce matching vault_id and vault_secret

  If a vault is of label 'dev_keychain', then decrypting will
'require'[1] a vault id for 'dev_keychain' is provided

            # with "enforcing" enabled in config
            ansible-playbook --vault-id dev_password
playbook_that_has_vaults_for_dev_keychain.yml

  will fail indicating that '--vault-id dev_keychain@dev_password' is needed

  This will help with the case where multiple vault items with
different vault ids also happen to all use the same password.

[1] require and enforcing in scare quotes, because that would be app
level logic and not a cryptographic requirement. ie, I could edit the
vault cipher text to change the vault id to 'dev' and above command
would succeed. (The vault-id is primarily a nickname used in the UX,
it is not signed or encrypted since that would require changing the
vault format in a non backwards compatible way).


* Not for 2.4

automatically choosing what vault passwords to interactively prompt
for based on which playbook content is loaded.
(that would be nice UX, but ansible doesn't know what it needs to
decrypt until way too late (in the worker processes...). We can fix
that, but it may need some significant changes to other parts of
ansible.


* Partial for 2.4

the secret/password callbacks mentioned in the roadmaps.
Same issue as above. It could work in my branch for non-interactive
callbacks, but the normal interactive console prompts do not.




[1] https://github.com/ansible/ansible/blob/devel/docs/docsite/rst/roadmap/ROADMAP_2_4.rst#vault
Reply all
Reply to author
Forward
0 new messages