[WIP]: Add missing authentication config fields to OpenShift API #1763
Conversation
openshift-ci
bot
added
the
do-not-merge/work-in-progress
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
ShazaAldawamneh
force-pushed
the
enhance-auth-config-api
branch
from
ab1b580 to
c330ea1
Compare
|
@ShazaAldawamneh: The following test failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
|
|
||
| 1. **Changes to `cluster-authentication-operator` Code:** | ||
|
|
||
| The generateAuthConfig method of the ExternalOIDCController is used to map OIDC provider configurations in the authentication.config.openshift.io custom resource to the structured authentication configuration format that the Kubernetes API server understands. This method will be updated to include logic to map the new fields introduced in the authentication.config.openshift.io CRD to their existing counterparts in the Kubernetes structured authentication configuration types. |
| #### Security Risks | ||
| Adding new authentication-related API fields could allow cluster administrators to misconfigure their authentication layer leading to security vulnerabilities. The new API fields themselves don't introduce any security risk. | ||
| - **Mitigation:** | ||
| - Ensure we have robust admission and runtime validations to ensure that misconfigurations are prevented as much as possible prior to rolling out the authentication layer changes. |
There was a problem hiding this comment.
| - Ensure we have robust admission and runtime validations to ensure that misconfigurations are prevented as much as possible prior to rolling out the authentication layer changes. | |
| - Ensure we have robust admission and runtime validations to ensure that misconfigurations are prevented as much as possible prior to rolling out the authentication layer changes. | |
There was a problem hiding this comment.
(add a newline between this and the next section)
| ### Dev Preview -> Tech Preview | ||
|
|
||
| - Ability to utilize the enhancement end to end | ||
| - End user documentation, relative API stability | ||
| - Sufficient test coverage | ||
| - Gather feedback from users rather than just developers | ||
| - Enumerate service level indicators (SLIs), expose SLIs as metrics | ||
| - Write symptoms-based alerts for the component(s) |
There was a problem hiding this comment.
We are going straight to TP with these changes right? Do we need this section?
|
|
||
| - No new feature gate will be introduced. | ||
| - The ExternalOIDC feature will not be promoted to GA without these new API fields based on product management input. | ||
| - This approach is subject to change depending on discussions regarding HyperShift and Standalone OpenShift's unified feature maturity. For now, we will proceed with expectations for standalone OpenShift. |
There was a problem hiding this comment.
After further discussions with HyperShift folks it seems unlikely that we will be able to achieve this from a technical perspective. Should be safe to remove this bullet point.
|
|
||
| ## Mitigation Strategy | ||
|
|
||
| We plan to add a combination of admission time and runtime checks to prevent invalid configurations from being applied. These checks will ensure that only properly formatted and functional configurations are accepted before they are rolled out to the kube-apiserver. |
There was a problem hiding this comment.
It would make sense to include that there if the external OIDC authentication layer is broken, using a kubeconfig should still function correctly as a break-glass scenario.
No description provided.