-
Bug
-
Resolution: Won't Do
-
Critical
-
None
-
4.16.z
-
Quality / Stability / Reliability
-
False
-
-
None
-
Important
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
Description of problem:
After upgrading OpenShift cluster from 4.14.35 to 4.16.25, RBAC permissions are degraded for users despite having correct group memberships and role bindings. The cluster-reader role permissions are not properly propagated, affecting user access to critical resources like node/status. This issue blocks further cluster upgrades due to RBAC uncertainty.
Version-Release number of selected component (if applicable):
OpenShift Container Platform Current Version: 4.16.25 Upgraded From: 4.14.35 Component: RBAC/Authentication Controller
How reproducible:
Always reproducible in the affected environment after upgrade from 4.14.35 to 4.16.25
Steps to Reproduce:
Set up OCP 4.14.35 cluster with LDAP integration
Configure ClusterRoleBinding for group "_DRV_rvEvolution_Openshift_Cluster_audit_LABOR" to cluster-reader role
Verify permissions work correctly
Upgrade cluster to 4.16.25
Login as user belonging to the LDAP group
Attempt to access node/status or view nodes in web console
Actual results:
Users cannot access node/status despite proper group membership
oc auth can-i shows limited permissions
Web console shows restricted views
Missing managedFields section in cluster-reader ClusterRole
Role aggregation appears broken
Direct user binding shows different results between API permissions and actual access
Expected results:
Users should maintain all cluster-reader permissions after upgrade
Access to node/status and other resources should work as before
Web console should show all authorized resources
Role aggregation should work properly
Permissions should be consistent between API and actual access
Additional info:
Environment Details:
Infrastructure: vSphere
Authentication: LDAP integrated
Configuration managed via GitOps/Argo
Issue only present in upgraded cluster
Same configuration works correctly in other clusters
Adding users to cluster-admin group temporarily resolves the issue
Problem affects cluster lifecycle as it blocks further upgrades
Verification Tests:
Compared configurations across clusters
Tested direct role bindings
Verified LDAP group membership
Confirmed OAuth and authentication operator status
Tested with private browser sessions
Logs and outputs available from:
Authentication operator logs
OAuth apiserver logs
RBAC permission comparisons
ClusterRole configurations