Application Credential support

[Deydra71]

Jira: https://issues.redhat.com/browse/OSPRH-16626

Adds end-to-end support for consuming Keystone Application Credentials (AC) in the nova-operator, enabling Nova control plane components (NovaAPI, Scheduler, Conductors/Cells, Metadata NoVNCProxy) to use AC-based authentication when available.

API changes:

Adds an optional authentication field to the Nova CR:

• spec.auth.applicationCredentialSecret — name of the Secret that contains the Keystone Application Credential ID and Secret (AC_ID and AC_SECRET).

Reconcile behavior:

• Reads spec.auth.applicationCredentialSecret.
• Attempts to load AC_ID / AC_SECRET from the referenced Secret (via the Keystone helper).
• If the Secret is missing or incomplete, it falls back to password authentication (AppCred auth is optional and not treated as an error).

Once the AC Secret is ready with valid AC_ID and AC_SECRET fields:

• Templates AC credentials into the rendered nova.conf for relevant auth sections (e.g. [keystone_authtoken] and service client auth stanzas such as [placement] / [neutron] / [glance] / [cinder] / [barbican] / [service_user], where applicable).
• The configuration hash includes AC values, triggering rolling updates when credentials rotate.
• A single Nova service user (nova) is used, and the same AC Secret is propagated across Nova subcomponents so all Nova pods authenticate consistently via the same credential source.
• Config template structure is updated so password-auth fields are not rendered when AppCred is used

Depends-on: openstack-k8s-operators/keystone-operator#567

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Deydra71
Once this PR has been reviewed and has the lgtm label, please assign seanmooney for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Deydra71]

I left out app cred auth from oslo_limit config section, because it needs system-scoped token, and our app creds are tied to user and project.

Kuttl tests will be added soon.

[softwarefactory-project-zuul]

Build failed (check pipeline). Post recheck (without leading slash)
to rerun all jobs. Make sure the failure cause has been resolved before
you rerun jobs.

https://softwarefactory-project.io/zuul/t/rdoproject.org/buildset/2e7e6c4092c549b9b63701580d6c34f4

✔️ openstack-meta-content-provider SUCCESS in 2h 41m 25s
✔️ nova-operator-kuttl SUCCESS in 42m 40s
✔️ nova-operator-tempest-multinode SUCCESS in 2h 17m 26s
❌ nova-operator-tempest-multinode-ceph FAILURE in 24m 26s

[SeanMooney]

This has the same design question as the watcher CRDs

specficily should the applaiction credtail secret be watched by the top level nova contoler only and embeded into the per servce cr screats that we generated or should each contoller monitor the applciation credetial secreate sepreatly.

the later will increase the load on the k8s api/etcd server and is really only useful if and only if we intended to be able to have nova-schduler use a diffent appclaition credetial form nova-conductor

if that is not the intent (i dont think it is) we shoudl not add the auth section ot the sub CRs for nova-api nova schduler ectra and should only add it to the top levele nova CRD

i dont think we have a usecase today to have seperate applciation creditals per cell but that might be reasonable so that you can rotate each cells seperately since that requires dataplane deployment to complete.

that probaly need wider dicsusion with kamil and gibi before proceeding

[softwarefactory-project-zuul]

Build failed (check pipeline). Post recheck (without leading slash)
to rerun all jobs. Make sure the failure cause has been resolved before
you rerun jobs.

https://softwarefactory-project.io/zuul/t/rdoproject.org/buildset/bc2c43d9a4bd4faca56dd814cfd0698b

✔️ openstack-meta-content-provider SUCCESS in 2h 39m 42s
✔️ nova-operator-kuttl SUCCESS in 43m 29s
✔️ nova-operator-tempest-multinode SUCCESS in 2h 03m 32s
❌ nova-operator-tempest-multinode-ceph FAILURE in 25m 53s

[mrkisaolamb]

This has the same design question as the watcher CRDs

specficily should the applaiction credtail secret be watched by the top level nova contoler only and embeded into the per servce cr screats that we generated or should each contoller monitor the applciation credetial secreate sepreatly.

the later will increase the load on the k8s api/etcd server and is really only useful if and only if we intended to be able to have nova-schduler use a diffent appclaition credetial form nova-conductor

if that is not the intent (i dont think it is) we shoudl not add the auth section ot the sub CRs for nova-api nova schduler ectra and should only add it to the top levele nova CRD

i dont think we have a usecase today to have seperate applciation creditals per cell but that might be reasonable so that you can rotate each cells seperately since that requires dataplane deployment to complete.

that probaly need wider dicsusion with kamil and gibi before proceeding

I agree that we need to discuss this when Gibi becomes available. In my opinion, a global plus per-cell secret should be sufficient. We will also likely need to discuss and test the oslo configuration with unified limits

[softwarefactory-project-zuul]

Merge Failed.

This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset.
Warning:
Error merging github.com/openstack-k8s-operators/nova-operator for 1055,34547a16fa6dc2ec61ce5718e0d854674a279300

[softwarefactory-project-zuul]

Merge Failed.

This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset.
Warning:
Error merging github.com/openstack-k8s-operators/nova-operator for 1055,b457838f7989365b2f3ad8b866b4e91af1b21190

[Deydra71]

@SeanMooney @amoralej I updated the PR to follow the same pattern as in watcher-operator. Could you please re-review? I'm also starting to do kuttl test in both oeprators.

[softwarefactory-project-zuul]

Build failed (check pipeline). Post recheck (without leading slash)
to rerun all jobs. Make sure the failure cause has been resolved before
you rerun jobs.

https://softwarefactory-project.io/zuul/t/rdoproject.org/buildset/f52acde840ac4de6b7d7d5805232d8d3

✔️ openstack-meta-content-provider SUCCESS in 3h 08m 11s
✔️ nova-operator-kuttl SUCCESS in 45m 49s
❌ nova-operator-tempest-multinode FAILURE in 21m 10s
✔️ nova-operator-tempest-multinode-ceph SUCCESS in 2h 37m 33s

[mrkisaolamb]

So we only need to wait for the KUTTL tests and QA feedback from @auniyal61. Thanks @Deydra71.

[mrkisaolamb]

I think this is also a place where we should use app credentials if they are used