I've managed to write a workaround, by writing a playbook which runs the get-admin-credential command task, with "delegate_to: localhost". >From this I build a dictionary with the parsed values for host/login/password from the command output, and in the ansible inventory file I do a hostvars lookup of these values.
An inventory plugin could also work, thanks for the tip I'll check that out later. On Thu, Mar 26, 2020 at 9:49 AM 'J Hawkesworth' via Ansible Project < [email protected]> wrote: > Would constructing your own lookup plugin be an option? > > There seem to be lots of lookup plugins that look things up in various > kinds of vaults: > https://docs.ansible.com/ansible/latest/plugins/lookup.html#plugin-list > Could you create one of your own. > > If you created an inventory plugin, rather than an older style dynamic > inventory script, I believe the inventory plugins can make use of the > internal cache, so you might be able to cache credentials for a little > while, which might speed things up, but I'd be inclined to see if you could > create your own lookup plugin. > > Hope this helps, > > Jon > > On Tuesday, March 17, 2020 at 7:49:01 PM UTC, Gregory Storme wrote: >> >> Hi, >> >> We have a couple of hundred Windows hosts, with each host having >> different credentials (both login and password), which are stored in an >> on-premise, in-house developed "vault" system. >> A dream scenario would be to install win32-openssh on all of them, and >> use ssh key authentication :) however until there's MSI(X) support for >> win32-openssh and/or it goes out of beta, this is not an option. >> >> We have an API to access our vault, which returns the >> hostname/username/password for the host. >> As a workaround now, I've written a simple wrapper for ansible-playbook >> which works, but the disadvantage is that each host is a new playbook run. >> I'm looking for a solution to run a playbook, and where ansible polls the >> hostname/username/password for each alias in the ansible inventory. >> Tried looking to patch the winrm.py connection plugin, but this didn't >> work, and I think it would poll for each task that's executed by the winrm >> plugin instead of only once? >> >> Solution I'm using now: >> >> ansible hosts file: >> >> [windows] >> L001 >> L002 >> L003 >> >> ansible-playbook wrapper: >> >> #!/bin/bash >> >> CONNECTION="ansible_connection=winrm ansible_port=5985 >> ansible_winrm_transport=credssp" >> >> for host in `cat ~/.ansible/hosts` >> do >> SECRET=`/opt/scripts/vault-functions/bin/console >> app:get-admin-credential --tag=$host` >> HOST=`echo $SECRET | cut -d ';' -f1` >> LOGIN=`echo $SECRET | cut -d ';' -f2` >> DOMAIN=`echo $SECRET | cut -d ';' -f3` >> PWD=`echo $SECRET | cut -d ';' -f4` >> >> if [ -z "$DOMAIN" ]; then >> ansible-playbook -i ~/.ansible/hosts ~/.ansible/windows.yml -e >> "ansible_host=$HOST ansible_user=$LOGIN ansible_password=$PWD $CONNECTION" >> else >> ansible-playbook -i ~/.ansible/hosts ~/.ansible/windows.yml -e >> "ansible_host=$HOST ansible_user=$LOGIN@$DOMAIN ansible_password=$PWD >> $CONNECTION" >> fi >> done >> >> This works, but as stated before this runs an ansible-playbook for each >> host. >> Could someone point me in the right direction on how to be able to run an >> ansible-playbook, upon which ansible does a lookup of the >> ansible_hostname/ansible_user/ansible-password during the connection phase >> to the host? >> >> Important detail, once a secret is requested from our vault, the password >> will be reset within a couple of hours. So it's not possible for us to >> build a static (encrypted) inventory. >> Building a dynamic inventory is also not desired, because of the large >> amount of hosts and the time it takes to request the credentials, this >> would take too long and by the time it's finished, it's possible the >> credentials of the first hosts have already been reset. >> >> So I'm looking for something that can pull data ad-hoc upon the ansible >> connection, like the wrapper above does, but whilst staying in 1 playbook >> run ... tips are much appreciated! >> >> -- > You received this message because you are subscribed to a topic in the > Google Groups "Ansible Project" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/ansible-project/bc28M8NwuvA/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/42d09dda-7d9d-440e-b5dd-cb3612990aea%40googlegroups.com > <https://groups.google.com/d/msgid/ansible-project/42d09dda-7d9d-440e-b5dd-cb3612990aea%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CACoGJjtbDqpdKYr9%3DUD9gJL%3DMKEpjCPgpY0NmFiURbWagq94%2BQ%40mail.gmail.com.
