Enable usage of vault client script in Ansible Tower

[lucas-benedito]

ISSUE TYPE

• Feature Idea

SUMMARY

From Ansible CLI it is possible to use a vault client script to run playbooks as the example below: ansible-playbook --vault-id vaulttest@vaulttest.py my_playbook.yml

The same cannot be achieved in AWX/Tower when using the Vault credential as it does not have a place to set the vault client script and setting it on the field "Vault identifier" doesn't work either.

[shanemcd]

This maybe belongs as a new credential type / plugin in AWX.

[wenottingham]

Does it not work if that script is available in the environment where playbooks are executed? If so, how does it fail?

We just recently removed storing of arbitrary script code in the database... we would not bring that back.

[lucas-benedito]

this fails even if the vaulttest.py is available at the project level as it is not possible to specify the file on the vault identifier

[AlanCoding]

To clarify what we're talking about here

https://docs.ansible.com/ansible/latest/user_guide/vault.html#managing-multiple-passwords-with-vault-ids

The source can be a prompt, a file, or a script, depending on how you are storing your vault passwords.

Right now we do the @prompt for any vault password with an id.

https://github.com/ansible/awx/blob/3414cae677c7342983d93d84a29ecd699d58b001/awx/main/tasks.py#L1777-L1778

So the thought here is to support files and scripts in source control along-side the playbook? @lucas-benedito

This maybe belongs as a new credential type / plugin in AWX.

I have a strong hesitation at this idea, because we have code to enforce uniqueness of the vault id. If you introduce a new credential type, then it needs to be exclusive with the vault credential type. We have no other place where 2 different credential types have a mutual exclusivity rule.

It's fairly impractical for us to validate whether the file or script exists before running a job. If a simplistic version of this would be acceptable, then I would find it fairly easy to add a new input field to the existing vault credential that simply tells the task code to construct the @ bit differently. This would assume the user only uses the credential for a job / inventory from a project with that file.

[lucas-benedito]

@AlanCoding your assumption is correct. The requester expects the vault credential from tower to work as it does in CLI by allowing the vaulttest@vaulttest.py.

[AlanCoding]

Here's the current Credential Type definition:

https://github.com/ansible/awx/blob/3414cae677c7342983d93d84a29ecd699d58b001/awx/main/models/credential/__init__.py#L634-L652

Option 1

• Add a new input, "source" or something, which defaults to "prompt", but the user can override
  • explain that if a non-default value is given, it needs to be the location (in the project) of a file or a script that produces the password
• make vault_password no longer required

Option 2

• Add a new input "source" with options of "prompt" or "file"
  • explain in help text that if set to "file" then vault_password needs to be the location (in the project) of a file or script that produces that password instead of the password itself

Either one of these would facilitate the needed communication between the user intent and our task preparation code.

Which option we choose is a user interface decision. Either would work. @jbradberry @ffirg opinions?

[ffirg]

I definitely agree with Bills July remark of not landing any arbitrary code in the DB. Looks like we're not doing that with either of those 2 options here, so all good on that front. Option 2 sounds the best to me. The onus then remains on the user to ensure sensible security measures around that repo/script etc.