-
Notifications
You must be signed in to change notification settings - Fork 459
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
authentication: direct external OIDC provider #1632
base: master
Are you sure you want to change the base?
Conversation
/retest |
1 similar comment
/retest |
Currently, any component that needs to obtain tokens or authenticate users does so against the built-in OAuth server. In order to integrate and use an external OIDC Identity Provider directly, any client component must replace its configuration to call the external OIDC provider instead of the built-in server. The components that act as OAuth server clients are: | ||
- OpenShift Console calls the OAuth server for user login to the console, and to obtain and display API access tokens | ||
- `oc` calls the OAuth server for user login to the API, and to obtain API access tokens | ||
- kube-apiserver calls the OAuth server via an authentication webhook for token management |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+ anything else we don't know of because this is OAuth2 and we provide means of dynamic OAuth2 client registration
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you still did not incorporate the above comment
|
||
The configuration details required to connect to an external OIDC provider are: | ||
- the provider URL | ||
- the ID and secret of the corresponding OIDC client at the provider's side |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you don't always need a secret to perform client operations against an OIDC server
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll loosen the wording to take care of this and the previous comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
still to be updated
4c0e494
to
d130e8c
Compare
d130e8c
to
e871efd
Compare
|
||
### Non-Goals | ||
|
||
n/a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+ keep the integrated OpenShift authentication stack working
Currently, any component that needs to obtain tokens or authenticate users does so against the built-in OAuth server. In order to integrate and use an external OIDC Identity Provider directly, any client component must replace its configuration to call the external OIDC provider instead of the built-in server. The components that act as OAuth server clients are: | ||
- OpenShift Console calls the OAuth server for user login to the console, and to obtain and display API access tokens | ||
- `oc` calls the OAuth server for user login to the API, and to obtain API access tokens | ||
- kube-apiserver calls the OAuth server via an authentication webhook for token management |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you still did not incorporate the above comment
|
||
The configuration details required to connect to an external OIDC provider are: | ||
- the provider URL | ||
- the ID and secret of the corresponding OIDC client at the provider's side |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
still to be updated
- the `AuthMetadata` observer sets the `OauthMetadataFile` field of the CR with the path for a ConfigMap referenced by the authentication config | ||
|
||
The operator must watch the Authentication CR for changes, and when it detects an external OIDC provider configuration, it must make the following changes, in order to update its configuration to use the external provider: | ||
- the `WebhookTokenAuthenticator` observer must replace the secret used as a webhook token authenticator for the API server with the one of the new provider, and synchronize it to the `openshift-kube-apiserver` namespace |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't make sense. What would you even use the secret for?
|
||
When the built-in OAuth server is used for authentication (the default and original cluster state), the cluster-authentication-operator manages all controllers and resources related to it; notably, it manages the deployments of the oauth-server and oauth-apiserver, and manages resources such as the respective namespaces, service accounts, role bindings, services, OAuth clients, etc. Moreover, it monitors the status of its operands, making sure that the routes/services are healthy and reachable, and updates its operator status accordingly. | ||
|
||
In case an external OIDC provider is configured for authentication, then these controllers and resources are not useful or irrelevant. Therefore, the operator must watch the Authentication CR, and when it detects a valid external OIDC provider configuration, it must stop its controllers and remove its resources. The operator will not be monitoring the oauth-server and oauth-apiserver any longer, however it must monitor the external OIDC provider for reachability and health, and advertise the result in its status; it must either adapt the functionality of its monitoring controllers or use a new controller for that. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you probably don't want the controllers to be actually stopped but rather turn them into a state where they remove the state they otherwise push to the cluster.
|
||
### Risks and Mitigations | ||
|
||
Configuring an external OIDC identity provider for authentication by definition means that any security updates or patches must be managed independently from the cluster itself, i.e. cluster updates will not resolve security issues relevant to the provider itself; the provider will have to be updated separately. Additionally, new functionality or features on the provider's side might need integration work in OpenShift (depending on their nature). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what about losing all your OAuth and User API data?
e871efd
to
914f4c0
Compare
Inactive enhancement proposals go stale after 28d of inactivity. See https://github.com/openshift/enhancements#life-cycle for details. Mark the proposal as fresh by commenting If this proposal is safe to close now please do so with /lifecycle stale |
Stale enhancement proposals rot after 7d of inactivity. See https://github.com/openshift/enhancements#life-cycle for details. Mark the proposal as fresh by commenting If this proposal is safe to close now please do so with /lifecycle rotten |
/remove-lifecycle rotten |
914f4c0
to
98f31c3
Compare
@liouk: all tests passed! 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. |
|
||
## Graduation Criteria | ||
|
||
The goal for this enhancement is to go directly to GA, because the feature is already available and in GA in HCP. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it will continue through techpreview, but I'm hopeful we do it quickly.
Overall, for this feature there must be e2e tests that cover the following: | ||
- configuring an external OIDC provider on a cluster that uses the built-in OAuth stack (good/bad configurations should be tested) | ||
- on a cluster that uses an external OIDC provider, test reverting configuration back to the built-in OAuth stack (good/bad configurations should be tested) | ||
- on a cluster that uses an external OIDC provider, test monitoring and cluster-authentication-operator status when the provider becomes unavailable |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
need to be sure that the user mapping capabilities work as well.
|
||
### Implementation Details/Notes/Constraints | ||
|
||
#### cluster-kube-apiserver-operator |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should these trigger kube-apiserver revisions or simply trigger an all-at-once instant rollout using live file reloads for the kube-apiserver?
looks like a good overall direction. I'll approve, but leave the lgtm with the team /approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: deads2k The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
This PR adds an enhancement for the implementation of using a direct external OIDC provider instead of the built-in oauth stack in OCP.
See also https://issues.redhat.com/browse/OCPSTRAT-306.