A flaw was found in the AAP Controller's HashiCorp Vault credential integration. When a HashiCorp Vault Secret Lookup credential is configured with kubernetes_role authentication, the credential test endpoint (POST /api/controller/v2/credentials/{id}/test/) triggers the kubernetes_auth() function which reads the controller pod's Kubernetes service account token from /var/run/secrets/kubernetes.io/serviceaccount/token and POSTs it as {"jwt": "<sa_token>", "role": "<role>"} to the user-supplied vault URL. There is no validation or restriction on the vault URL target. An authenticated attacker with credential-creation privileges can set the vault URL to an attacker-controlled server and capture the SA token. The exfiltrated token (system:serviceaccount:ansible-automation-platform:automation-controller) has broad Kubernetes RBAC permissions including: full pod CRUD (get,list,watch,create,update,patch,delete) in both ansible-automation-job and ansible-automation-platform namespaces, and individual secret access (get,create,delete) in both namespaces. This allows the attacker to read database credentials, the Django SECRET_KEY, and access all 31+ pods in the AAP platform namespace. In AAP Cloud (managed service) environments, this constitutes a tenant-to-infrastructure escape as the control plane is managed by Red Hat. The token has an approximately 1-year lifetime.

    Upstream: https://github.com/ansible/awx (awx_plugins/credentials/hashivault.py)
    Affected function: kubernetes_auth() at hashivault.py:462-468
    Reporter: Chris Meyers (internal — cmeyers)
    Tested against: platform.cus-0616.aws.ansiblecloud.com (AAP Cloud, ROSA)