A flaw was found in the AAP Controller's HashiCorp Vault credential plugin. The kubernetes_auth() function in awx_plugins/credentials/hashivault.py reads the controller pod's Kubernetes service account token and sends it to an attacker-controlled URL when a HashiCorp Vault Secret Lookup credential with kubernetes_role authentication is tested. An authenticated attacker with credential-creation privileges can exfiltrate the service account token, gaining Kubernetes API access to the control plane namespaces with full pod CRUD and secret read permissions, including database credentials and the Django SECRET_KEY.
The following practices would help for avoiding exposure and mitigate this flaw:
- Restrict network egress from controller pods using Kubernetes NetworkPolicy to prevent outbound connections to untrusted destinations. Only allow connections to known Vault server endpoints.
- Review and restrict the RBAC permissions of the automation-controller service account to follow the principle of least privilege. Remove unnecessary secret read access.
- In AAP Cloud environments, audit credential-creation activity for suspicious HashiCorp Vault credentials with external or unusual URLs.
- Monitor Kubernetes audit logs for unexpected API calls using the automation-controller service account, particularly secret reads and pod operations from EE pods.
- Rotate the automation-controller service account token if unauthorized access is suspected.
- Consider restricting the "create credential" privilege to only trusted administrators until the fix is available.