Goal: 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.

Migration: oauth-proxy to kube-rbac-proxy
If a team identifies their operator as Impacted, the primary remediation is often migrating from 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.

Steps:
• Replace the Sidecar: Swap the oauth-proxy container image with the kube-rbac-proxy image
• Change Authentication Method: 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
• Update RBAC: Ensure RoleBindings and ClusterRoleBindings reference the new users and groups from your external IDP

Requirements:
Operator teams must document:
• Impact Status: Document if the operator is Impacted or Not Impacted
• Remediation Plan: If impacted, document the plan to migrate from oauth-proxy to kube-rbac-proxy and how reliance on User/Group APIs will be removed
• Tracking: Update the central status spreadsheet with these findings

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