-
Bug
-
Resolution: Unresolved
-
Critical
-
None
-
None
-
0
-
False
-
-
False
-
?
-
rhos-ops-platform-services-security
-
None
-
-
-
-
DFG Security: Sprint 21
-
1
-
Critical
When application credentials (ZDPR) are enabled globally and for Octavia, the openstack-operator
creates the KeystoneApplicationCredential CR (ac-octavia) and the keystone-operator successfully
creates the app cred in Keystone. However, Octavia continues to use password authentication
because the app cred secret name is set on the wrong path in the Octavia CR.
To Reproduce Steps to reproduce the behavior:
1. Deploy RHOSO 18 with the ZDPR-enabled openstack-operator (PR #1430 merged)
2. Deploy Octevia if not deployed.
3. Enable application credentials globally and for Octavia:
```
spec:
applicationCredential:
enabled: true
octavia:
applicationCredential:
enabled: true
```
4. Wait for the CR to reconcile ("Setup complete")
5. Check the Octavia CR auth field:
```bash
oc get octavia octavia -n openstack -o jsonpath='{.spec.auth}'
```
6. See: `{}` (empty - auth secret not set)
7. Check Octavia config:
```bash
oc exec -n openstack <octavia-api-pod> -c octavia-api – grep "^auth_type" /etc/octavia/octavia.conf
```
8. See: `auth_type = password` (not using app creds)
Expected behavior
The Octavia CR should have `spec.auth.applicationCredentialSecret: "ac-octavia-secret"` and
Octavia should be configured with `auth_type = v3applicationcredential`.
Bug impact
Octavia does not use application credentials even when ZDPR is enabled. It silently falls back
to password authentication. This means:
- Octavia is excluded from app cred rotation
- Password rotation procedures must still account for Octavia
- ZDPR testing shows Octavia as not participating in app cred auth
-
-
- Root Cause*
-
In `internal/openstack/octavia.go` (~line 130), the openstack-operator sets the secret on
the OctaviaAPI sub-spec:
```go
instance.Spec.Octavia.Template.OctaviaAPI.Auth.ApplicationCredentialSecret = acSecretName
```
But the octavia-operator (PR #543) reads from the top-level Octavia spec `spec.auth`, which
is populated from `OctaviaSpecBase`, not `OctaviaAPISpecCore`.
The fix is:
```go
instance.Spec.Octavia.Template.Auth.ApplicationCredentialSecret = acSecretName
```
-
-
- Known Workaround*
-
Patch the OpenStackControlPlane CR to manually set the auth secret at the correct template level:
```bash
oc patch openstackcontrolplane controlplane -n openstack --type=merge -p '{
"spec": {
"octavia": {
"template": {
"auth":
}
}
}
}'
```
Note: Patching the Octavia CR directly does NOT work because the openstack-operator owns
the CR and overwrites it during reconciliation.
Also ensure the ac-octavia KeystoneApplicationCredential CR has roles: ["service", "admin"]
(admin role is required per octavia-operator reviewer gthiemonge in PR #543).
Additional context
- - openstack-operator PR #1430 (AppCred support) - contains the bug
- - octavia-operator PR #543 (AppCred support) - working correctly
- - keystone-operator PR #567 (AppCred controller) - working correctly
- - JIRA: OSPRH-21647
- - Discovered during manual ZDPR testing on RHOSO 18, Feb 19, 2026
- impacts account
-
OSPRH-17090 Downstream testing for Applicaiton Credentials
-
- In Progress
-
- links to