In our organization each user must use his own credentials for audit purposes so i can’t have one central key for awx. Therefore every user will define his own machine type credential with his ssh key attached to it.
My question is how do i set the job template that the job will pick the credential for the user that is logged in awx? Prompt on launch would work but i was hoping awx would be smart enough to do this on it’s own.
Any ideas?
Adrian Sebastian Dutu (dutu.adrian90@gmail.com) said:
In our organization each user must use his own credentials for audit
purposes so i can't have one central key for awx. Therefore every user will
define his own machine type credential with his ssh key attached to it.
My question is how do i set the job template that the job will pick the
credential for the user that is logged in awx? Prompt on launch would work
but i was hoping awx would be smart enough to do this on it's own.
Any ideas?
A user could have 5/10/100 different 'personal' credentials that they could
be using for different use cases, so I'm not sure how you would codify
picking just one.
It’s not really that hard if they want to do it. Just consider the logged in user as a variable and if you name the credentials the same for each user, it would be pretty easy to do a lookup after that. Or even make a new type of credential. It’s not something that wasn’t done before.
Bumping because I also would like to have some sort of way to pass currently logged in user credentials through to a playbook without having to store those credentials or prompt/survey them again. I know you can use the tower_user_name variable to pass the currently logged in user’s username but there doesn’t seem to be any way to pass the encrypted password or call some kind of logged in user object to a playbook for credential use. This would be highly desirable!
We’re about to merge secrets management system support into AWX, this might be a better solution for you though not exactly “automatic”. You could store credentials in something like hashi vault and reference the secrets that way.
Looks like the PR was merged after the 4.0.0 release. If you’re building off the devel branch you can get the external secrets management bit. Docs look like they’re still being finalized. Here are the bits that I found so far