[RFE] Allow Approle and LDAP/AD Auth Mechanisms for AWX/Hashicorp Vault Token Integration

[hiyokotaisa]

ISSUE TYPE

• Feature Idea

SUMMARY

Currently, only static tokens are allowed as the inputs to integrate Hashicorp Vault with AWX. Customer wants the following:

For Approle:
Input approle_id (which exists on the Hashicorp Vault side) in a Vault Signed SSH and Vault Secrets credential. The resultant output of this will be the Secret Token being filled in and returned from the API call to Hashicorp Vault.
Docs >>>>> https://www.vaultproject.io/docs/auth/approle.html

For AD/LDAP:
Input username and password (AD/LDAP integration exists on the Hashicorp Vault side) in a Vault Signed SSH and Vault Secrets credential. The resultant output of this will be the Secret Token being filled in and returned from the API call to Hashicorp Vault.
Docs >>>>> https://www.vaultproject.io/docs/auth/ldap.html

Each time the credential is used, this API call should be made and the secret token should be updated. This will allow for short-lived TTLs on secret tokens and reduces the amount of manual effort to update secret tokens.

[kawsark]

PR: #6220
Testing steps: https://github.com/kawsark/awx-approle-ansible

[ItayZviCohen]

Really want this feature to exist. I'm working for a very large corporation and what we did is to store Vault credential as a custom secret.

[Tioborto]

+1

[Fredki2]

+1

[kdelee]

@one-t could you take a look at this sometime

[one-t]

This one is somewhat complex. The AppRole piece should fit in pretty easily but the LDAP part requires that hashicorp vault be configured to use LDAP for auth, which means running a few commands in the container and having it use the existing Red Hat Directory Server. We would also either need to make this a separate class or use it function scope since it would alter the configuration of the vault significantly.

Flow would look like this for the LDAP portion

1. Provision the Vault deployment
2. Create a user with a name matching one in the LDAP directory
3. Create a secret that this user has access to
4. Execute the command inside the container to enable ldap auth
5. Execute a command delivering a JSON payload with LDAP config info
6. Create the credential in tower using the ldap creds
7. Pull the secret

Gotchas to worry about:

• Exposure of LDAP Credentials, since we're storing them statically here.
• Creates an additional dependency for the external directory server
• Error handling for invalid LDAP creds
  • Make sure it's an invalid username and not an invalid password. Don't want to get the account locked.
• Error handling for locked accounts (The default behavior for LDAP directories is usually to lock an account if 5 failed logins happen).
  • This could be replicated by just having a locked account in the directory and using it in a test.

[one-t]

I also think this might be a good issue for someone to pair up with me on because it touches a couple of external systems that a lot of QE folks haven't touched yet.

[one-t]

Putting this back in needs_devel, there are unmerged PRs - #6158 #6159

[ryanpetrello]

@wenottingham is this a near-term priority that we should track more closely as an enhancement in the next major release?

[wenottingham]

The approle bits were already merged, it is just LDAP/AD which is not.

[Tioborto]

Hi @wenottingham, @ryanpetrello , any idea about the resolution of this topic ? please

[wenottingham]

The prior comment stands - part of the subject of this issue had a pull request that was merged (AppRole)... there has been no changes for LDAP auth, so it remains open.