Feature Overview

Introduce a native "Authentication Policy" mechanism that projects an OIDC Provider configuration to a selected set of managed clusters allowing users to authenticate external tools against the entire fleet using a single identity.

Goals

• Federated Trust: Allow external tools (e.g., MCP Servers, IDEs, CI/CD) to authenticate once against an IdP and use that single token to access any cluster in the fleet.
• Policy-Driven: Use standard RHACM Placement rules to target specific clusters (e.g., env=prod), rather than a binary "all or nothing" approach.
• Drift Remediation: Ensure that if a managed cluster's OAuth configuration is altered manually, the policy controller reverts it to the federated standard.
• Zero-Trust Enablement: Eliminate the need to distribute long-lived kubeconfig files or ServiceAccount tokens to external agents.

Requirements

Use Cases

External tooling

• External tools (like an MCP Server for AI agents) currently require a unique kubeconfig for every cluster they manage. For a fleet of 100 clusters, this is 100 secrets to rotate and secure.
• With this feature, the MCP server is configured with one OIDC Client ID. It authenticates with the IdP (e.g., Keycloak) to get a JWT. Because RHACM has enforced that same IdP trust on all 100 clusters, the MCP server can directly query the API of any managed cluster using that single JWT.

Questions to answer

Out of Scope

• …

Background, and strategic fit

This Section: What does the person writing code, testing, documenting
need to know? What context can be provided to frame this feature?

Assumptions

• ...

Customer Considerations

• ...

Documentation Considerations

Questions to be addressed:

• What educational or reference material (docs) is required to support this
  product feature? For users/admins? Other functions (security officers, etc)?
• Does this feature have a doc impact?
• New Content, Updates to existing content, Release Note, or No Doc Impact
• If unsure and no Technical Writer is available, please contact Content
  Strategy.
• What concepts do customers need to understand to be successful in
  [action]?
• How do we expect customers will use the feature? For what purpose(s)?
• What reference material might a customer want/need to complete [action]?
• Is there source material that can be used as reference for the Technical
  Writer in writing the content? If yes, please link if available.
• What is the doc impact (New Content, Updates to existing content, or
  Release Note)?