-
Bug
-
Resolution: Done-Errata
-
Major
-
4.12
-
-
-
Important
-
No
-
ShiftStack Sprint 238, ShiftStack Sprint 239, ShiftStack Sprint 240
-
3
-
Rejected
-
False
-
-
-
Bug Fix
-
Done
-
Customer Escalated
Description of problem:
After all cluster operators have reconciled after the password rotation, we can still see authentication failures in keystone (attached screenshot of splunk query)
Version-Release number of selected component (if applicable):
Environment: - OpenShift 4.12.10 on OpenStack 16 - The cluster is managed via RHACM, but password rotation shall be done via "regular" OpenShift means.
How reproducible:
Rotated the OpenStack credentials according to the documentation [1] [1] https://docs.openshift.com/container-platform/4.12/authentication/managing_cloud_provider_credentials/cco-mode-passthrough.html#manually-rotating-cloud-creds_cco-mode-passthrough
Additional info:
- we can't trace back where these authentication failures come from - they do disappear after a cluster upgrade (so when nodes are rebooted and all pods are restarted which indicates that there's still a component using the old credentials) - The relevant technical integration points _seem_ to be working though (LBaaS, CSI, Machine API, Swift)
What is the business impact? Please also provide timeframe information.
- We cannot rely on splunk monitoring for authentication issues since it's currently constantly showing authentication errors - We cannot be entirely sure that everything works as expected since we don't know the component that doesn't seem to use the new credentials
- blocks
-
OCPBUGS-17160 OpenShift on OpenStack: Password Rotation of OSP User still leads to unknown authentication failures in Keystone
- Closed
- is cloned by
-
OCPBUGS-17160 OpenShift on OpenStack: Password Rotation of OSP User still leads to unknown authentication failures in Keystone
- Closed
- links to
-
RHEA-2023:5006 rpm
(1 links to)