Goal:
The primary goal of this effort is to enable OpenShift to trust and directly consume access tokens from external OIDC providers (such as Keycloak or Entra ID), effectively bypassing the built-in OpenShift OAuth server. This aligns OpenShift's authentication architecture with upstream Kubernetes standards.

Operator Impact Checklist
Teams should review their operators against these criteria. If the answer to any of the first three checks is Yes, the operator is impacted and requires changes.

• Creates OAuthClients: Does the operator create or manage OAuthClient resources?
○ Status: Impacted. These will fail when the OAuth server is disabled.

• Deploys OAuth-proxy sidecars: Does the operator deploy oauth-proxy sidecars for authentication?
○ Status: Impacted. This is deprecated in this mode and must be migrated.

• Queries User/Group APIs: Does the operator query APIs like /apis/user.openshift.io/v1/users or /groups?
○ Status: Impacted. These APIs will be unavailable; logic must shift to using IDP claims.

• Uses ServiceAccounts only: Does the operator rely solely on ServiceAccounts?
○ Status: Not Impacted.

• Uses Standard RBAC only: Does the operator rely solely on standard Kubernetes RBAC/RoleBindings?
○ Status: Not Impacted.

If a team identifies their operator as Impacted, the primary remediation is often migrating from OAuth-proxy to kube-rbac-proxy.

Migration: oauth-proxy to kube-rbac-proxy

Because the internal OpenShift OAuth server is disabled in this mode, oauth-proxy sidecars will stop functioning. You must replace them with kube-rbac-proxy, which delegates authentication to the Kubernetes API Server.

• Replace the Sidecar: Swap the oauth-proxy container image in your operator or application deployment with the kube-rbac-proxy image.
• Change Authentication Method: Unlike oauth-proxy (which performs an OAuth flow), kube-rbac-proxy validates tokens by performing a TokenReview against the Kubernetes API Server.
• Enforce Authorization: Configure KRP to use SubjectAccessReviews (SAR) to enforce access control. It will check if the authenticated user (from the external IDP) has the required RBAC permissions to access the service.
• Update RBAC: Ensure your RoleBindings and ClusterRoleBindings reference the new users and groups coming from your external Identity Provider (IDP), as the internal OpenShift users/groups will no longer exist.

This ensures your layered products continue to function using standard Kubernetes primitives, even without the internal OAuth server.

Requirements
Operator teams must document the findings from their self-identification checklist to confirm readiness:

• Impact Status: Document if the operator is Impacted or Not Impacted based on its use of OAuthClient, oauth-proxy, or User/Group APIs.
• Remediation Plan: If impacted, document the plan to migrate from oauth-proxy to kube-rbac-proxy and how reliance on OpenShift User/Group APIs will be removed.
• Tracking: Update the central status spreadsheet with these findings to track readiness across layered products.

Cluster Administration & Safety

For the cluster itself, the following must be documented for the operations team before enabling the feature:

• Break-Glass Access: Document the specific method for emergency cluster access (e.g., a kubeconfig file with client certificates) to be used if the external IDP becomes unavailable.
• Configuration Backups: Document that a backup of all existing Users, Groups, and OAuthClients has been taken, as these resources will become inaccessible once the OpenShift OAuth server is disabled.
• Disabled Functionality: Create a warning list of oc adm commands (e.g., oc adm groups sync) that will no longer function.
• Upgrade Restrictions: If using the TechPreview feature set, document that the cluster cannot be upgraded while this feature is enabled.

Reference/Support
https://notebooklm.google.com/notebook/4c8e93ed-d2aa-44c7-8735-327392c00771