REDHAT-BUG-2571730: Medium severity vulnerability
The AAP/Gateway operator creates or reads a protected resource-server Secret (Secret/<aap-name>-resource-server, key controllerresourceserversecret) and then copies the plaintext value into the generated AutomationController Custom Resource under spec.extrasettings as RESOURCESERVER.SECRETKEY (alongside URL: <Gateway internal URL> and VALIDATEHTTPS: false). This breaks the expected OpenShift RBAC separation between reading an AutomationController CR and reading the corresponding Kubernetes Secret: a principal with permission to read the Controller CR can recover the service credential without permission to read the Secret. The operator uses nolog to prevent the value from appearing in its logs, but then serializes the same value into the CR. The value may also propagate into Kubernetes API/etcd storage, Argo diffs and history, rendered GitOps artifacts, support bundles, audit data, and command output. Relevant operator code: roles/ansibleautomationplatform/tasks/initializegateway.yml, roles/ansibleautomationplatform/tasks/injectgwsettingsincontroller.yml, roles/ansibleautomationplatform/vars/main.yml. Confirmed in build aap-operator.v2.6.0-0.1792661545; likely all AAP versions since the introduction of the gateway operator (AAP 2.5). The value is intended for trusted Gateway-to-Controller service authentication; a user who can read the Controller CR may be able to impersonate a trusted Controller service and access privileged service-index APIs. Depending on the service authorization policy, potential impact includes reading protected service-index data, creating or modifying role assignments, modifying RBAC-related resources, and escalating AAP user privileges potentially to superuser-equivalent actions.
Affected Software
Event History
Frequently Asked Questions
Who can recover the credential?
Any principal that can read the generated AutomationController custom resource can recover the resource-server credential from spec.extra_settings, even if that principal has no permission to read the corresponding Kubernetes Secret.
What access is required to exploit this issue?
An attacker needs read access to the AutomationController custom resource created by the AAP/Gateway operator. Direct access to Secret/<aap-name>-resource-server is not required.
How can I determine whether a deployment is affected?
Inspect the generated AutomationController custom resource for RESOURCE_SERVER.SECRET_KEY under spec.extra_settings. If that setting contains the resource-server secret value, the credential has been exposed through the custom resource.
Where else might the exposed credential be present?
Because the value is serialized into the custom resource, it may also be present in Kubernetes API and etcd storage, Argo diffs or history, rendered GitOps artifacts, support bundles, audit data, and command output.
Does suppressing operator logs prevent the exposure?
No. The operator uses no_log to avoid logging the value, but it still writes the plaintext value into the AutomationController custom resource.