Uploaded image for project: 'Red Hat OpenStack Services on OpenShift'
  1. Red Hat OpenStack Services on OpenShift
  2. OSPRH-26805

openstack-operator sets Octavia ApplicationCredentialSecret on wrong spec path

XMLWordPrintable

    • 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

       

          1. 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
      ```

          1. 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":

      { "applicationCredentialSecret": "ac-octavia-secret" }

      }
      }
      }
      }'
      ```

      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
         

              rh-ee-millevy Milana Levy
              rh-ee-millevy Milana Levy
              rhos-dfg-security
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: