Tower External SSH Data

the-plan.md

First setup (pre ssh certificate signing)

Short term description of how things will work for early beta:

• Joe wants to run some automation across pages-fe hosts
• Joe opens a pull request to the pages-fe-ansible repo with a new Ansible playbook and configuration to add it to AWX.
• Joe get’s peer review
• Joe does a branch deploy of pages-fe-ansible, which updates AWX config to use his branch for that project, and adds the new playbook as a “template”.
• Joe then browses to gtower.githubapp.com and logs in with his LDAP credentials
• Joe browses to the new template and clicks to execute.
• Joe is prompted to select a credential to use. Joe select’s “joes-vault-backed-ssh-key” credential which only Joe is allowed to use
• Joe is prompted for the passphrase for that credential and puts it in.
• AWX starts the execution.
• AWX uses a Vault token to access the secret path configured for “joes-vault-backed-ssh-key” in order to pull out the private key data .
• AWX combines that data with the passphrase it has within a task space and uses that as the credential to log into the remote machines listed in the playbook that joe added
• Things work, or not, the task finishes or fails. AWX destroys any bits that were on the disk for that run, discards the passphrase from memory, etc.
• the cycle repeats.

Trust Summary:

• We trust vault to store the encrypted private key bits for each user
• We trust AWX with a vault credential to fetch the private bit on demand
• We trust AWX to enforce access controls to limit use access to credentials to specific users (one user per credential)
• We prompt the user for the passphrase to unlock the private bits that are fetched
• We trust AWX to discard the private data when the task is complete
• We only use this access path until we can migrate to signed SSH certs
• We demand users create new ssh keys specifically for AWX, which will be removed when we migrate to SSH certs

Future with SSH Certificate Signing

How it should work

• Joe wants to run some automation across pages-fe hosts
• Joe opens a pull request to the pages-fe-ansible repo with a new Ansible playbook and configuration to add it to AWX.
• Joe get’s peer review
• Joe does a branch deploy of pages-fe-ansible, which updates AWX config to use his branch for that project, and adds the new playbook as a “template”.
• Joe then browses to gtower.githubapp.com and logs in with his LDAP credentials
• Joe browses to the new template and clicks to execute.
• Joe's template is set to use the gtower credential in the GitHub organization
• AWX starts the execution.
• AWX uses a Vault K/V token to access the secret path configured for gtower in order to pull out the private key data.
• AWX uses a Vault SSH Signing token with metadata to sign the public side of the gtower credential, using the logged in user (Joe) as the principal to sign the key for.
• AWX combines the fetched private gtower key data with the signed cert within a task space and uses that as the credential to log into the remote machines listed in the playbook that joe added, as the joe user.
• Things work, or not, the task finishes or fails. AWX destroys any bits that were on the disk for that run, discards the signed content from memory, etc.
• the cycle repeats.

Key functionality

• A single org Machine credential, with a single private/public pair.
• Vault SSH Signing plugin configuration that sources the logged in user as the principal to sign for
• Credential configuration to use the logged in user as the username to connect as on the remote host