|
1 | 1 | ---
|
2 | 2 | title: Add Missing Authentication Configuration Fields to OpenShift API
|
3 | 3 | authors:
|
4 |
| - - @ShazaAldawamneh |
| 4 | + - "ß@ShazaAldawamneh" |
5 | 5 | reviewers: # Include a comment about what domain expertise a reviewer is expected to bring and what area of the enhancement you expect them to focus on. For example: - "@networkguru, for networking aspects, please look at IP bootstrapping aspect"
|
6 |
| - - TBD |
| 6 | + - "@everettraven" |
| 7 | + - "@ibihim" |
| 8 | + - "@liouk" |
7 | 9 | approvers: # A single approver is preferred, the role of the approver is to raise important questions, help ensure the enhancement receives reviews from all applicable areas/SMEs, and determine when consensus is achieved such that the EP can move forward to implementation. Having multiple approvers makes it difficult to determine who is responsible for the actual approval.
|
8 |
| - - TBD |
| 10 | + - "@sjenning" |
9 | 11 | api-approvers: # In case of new or modified APIs or API extensions (CRDs, aggregated apiservers, webhooks, finalizers). If there is no API change, use "None"
|
10 |
| - - TBD |
| 12 | + - "@JoelSpeed" |
| 13 | + - "@everettraven" |
11 | 14 | creation-date: 2025-03-03
|
12 | 15 | last-updated: 2025-03-03
|
13 | 16 | tracking-link: # link to the tracking ticket (for example: Jira Feature or Epic ticket) that corresponds to this enhancement
|
14 |
| - - https://issues.redhat.com/browse/CNTRLPLANE-127 |
| 17 | + - "https://issues.redhat.com/browse/CNTRLPLANE-127" |
15 | 18 | see-also:
|
16 |
| - - "/enhancements/this-other-neat-thing.md" |
| 19 | + - "https://issues.redhat.com/browse/OCPSTRAT-306" |
17 | 20 | replaces:
|
18 |
| - - "/enhancements/that-less-than-great-idea.md" |
| 21 | + - "" |
19 | 22 | superseded-by:
|
20 |
| - - "/enhancements/our-past-effort.md" |
| 23 | + - "" |
21 | 24 | ---
|
22 |
| -# Neat Enhancement Idea |
23 |
| - |
24 |
| -Add Missing Authentication Configuration Fields to OpenShift API |
| 25 | +# Add Missing Authentication Configuration Fields to OpenShift API |
25 | 26 |
|
26 | 27 | ## Summary
|
27 | 28 |
|
28 |
| -This enhancement proposal adds several missing authentication fields to the OpenShift API to improve flexibility, security, and interoperability with different identity providers. The key additions include Issuer fields (DiscoveryURL, AudienceMatchPolicy) for better OIDC configuration, ClaimMappings (UID, Extra) for customizable user identity resolution, ClaimValidationRules to enable advanced token validation through CEL expressions, and UserValidationRules to enforce security policies on usernames and groups. These enhancements ensure stronger identity validation, support for complex authentication setups, better multi-tenancy management, and improved RBAC enforcement, making OpenShift authentication more robust and adaptable to various enterprise use cases. |
| 29 | +This enhancement proposal adds missing authentication fields to the structured authentication configuration in the OpenShift API, improving flexibility, security, and interoperability with identity providers. |
| 30 | + |
| 31 | +Key additions include: |
| 32 | +- **Issuer fields** (`DiscoveryURL`, `AudienceMatchPolicy`) for advanced OIDC configuration. |
| 33 | +- **ClaimMappings** (`UID`, `Extra`) for customizable user identity resolution. |
| 34 | +- **ClaimValidationRules** to enable advanced token validation via CEL expressions. |
| 35 | +- **UserValidationRules** to enforce security policies on usernames and groups. |
| 36 | + |
| 37 | +These changes enhance identity validation, support complex authentication setups, strengthen multi-tenancy, and improve RBAC enforcement. For reference, these updates align with Kubernetes' authentication configuration model: [Kubernetes Authentication Configuration](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#using-authentication-configuration). |
29 | 38 |
|
30 |
| -## Motivation |
31 |
| -The current OpenShift authentication API lacks key fields that are essential for organizations needing advanced OIDC configurations, fine-grained identity control, and enhanced security enforcement. By adding missing fields such as Issuer configurations (DiscoveryURL, AudienceMatchPolicy), ClaimMappings (UID, Extra), ClaimValidationRules, and UserValidationRules, we address critical gaps in authentication flexibility, security, and multi-tenancy support. |
| 39 | +## Motivation |
32 | 40 |
|
| 41 | +The current OpenShift authentication API lacks key fields necessary for organizations that require advanced OIDC configurations, fine-grained identity control, and stronger security enforcement. By adding missing fields such as **Issuer configurations** (`DiscoveryURL`, `AudienceMatchPolicy`), **ClaimMappings** (`UID`, `Extra`), **ClaimValidationRules**, and **UserValidationRules**, this enhancement addresses critical gaps in authentication flexibility, security, and multi-tenancy support. |
33 | 42 |
|
34 |
| -### User Stories |
35 |
| -- As a customer, I want to configure the DiscoveryURL and AudienceMatchPolicy in OpenShift so that I can ensure my OIDC provider’s metadata is correctly accessed and that tokens are validated for the correct audience, even in complex networking setups or multi-cluster environments. |
| 43 | +## User Stories |
36 | 44 |
|
37 |
| -- As an enterprise administrator, I want to define UID mappings and store extra claim data for my users, allowing me to customize OIDC claims and uniquely identify users across multiple tenants, while also supporting flexible roles and permissions. This will help me integrate with external identity providers and enforce role-based access control (RBAC) based on custom claims. |
| 45 | +- **As a customer**, I want to configure the `DiscoveryURL` and `AudienceMatchPolicy` in OpenShift so that my OIDC provider’s metadata is correctly accessed, and tokens are validated for the correct audience—even in complex networking setups or multi-cluster environments. |
38 | 46 |
|
39 |
| -- As a security engineer, I want to use ClaimValidationRules with CEL expressions to enforce advanced token validation logic (e.g., checking token expiration or validating multiple claims) and implement UserValidationRules to prevent the use of reserved system usernames and groups. This ensures that only valid, authorized users are allowed access, reducing security risks and preventing privilege escalation. |
| 47 | +- **As an enterprise administrator**, I want to define `UID` mappings and store extra claim data, allowing me to customize OIDC claims and uniquely identify users across multiple tenants. This ensures seamless integration with external identity providers and supports **role-based access control (RBAC)** based on custom claims. |
40 | 48 |
|
41 |
| -### Goals |
| 49 | +- **As a security engineer**, I want to use **ClaimValidationRules** with **CEL expressions** to enforce advanced token validation logic (e.g., checking token expiration or validating multiple claims). Additionally, I want to implement **UserValidationRules** to prevent the use of reserved system usernames and groups, reducing security risks and preventing privilege escalation. |
42 | 50 |
|
43 |
| -1. Allow administrators to configure and validate advanced authentication settings, including DiscoveryURL, AudienceMatchPolicy, UID, Extra claims, ClaimValidationRules, and UserValidationRules. |
44 |
| -2. Enable flexible claim mapping, multi-cluster support, and integration with external identity providers. |
45 |
| -3. Enhance security by enforcing advanced validation and user identity rules for proper access control. |
| 51 | +## Goals |
46 | 52 |
|
47 |
| -### Non-Goals |
| 53 | +1. Enable administrators to configure and validate advanced authentication settings, including `DiscoveryURL`, `AudienceMatchPolicy`, `UID`, `Extra` claims, `ClaimValidationRules`, and `UserValidationRules`. |
| 54 | +2. Support flexible claim mapping, multi-cluster authentication, and integration with external identity providers. |
| 55 | +3. Strengthen security by enforcing advanced validation rules and identity policies to ensure proper access control. |
48 | 56 |
|
49 |
| -1. Does not include new authentication mechanisms outside of OIDC. |
| 57 | +## Non-Goals |
50 | 58 |
|
| 59 | +- This enhancement does **not** introduce new authentication mechanisms beyond OIDC. |
51 | 60 |
|
52 | 61 | ## Proposal
|
53 | 62 |
|
|
0 commit comments