authentication: direct external OIDC provider #1632
Conversation
openshift-ci
bot
added
the
do-not-merge/work-in-progress
|
/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.
+ 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.
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.
you don't always need a secret to perform client operations against an OIDC server
There was a problem hiding this comment.
I'll loosen the wording to take care of this and the previous comment.
liouk
force-pushed
the
direct-external-oidc-provider
branch
6 times, most recently
from
4c0e494
to
d130e8c
Compare
liouk
force-pushed
the
direct-external-oidc-provider
branch
from
d130e8c
to
e871efd
Compare
|
|
||
| ### Non-Goals | ||
|
|
||
| n/a |
There was a problem hiding this comment.
+ 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.
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 |
| - 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.
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.
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.
what about losing all your OAuth and User API data?
liouk
force-pushed
the
direct-external-oidc-provider
branch
from
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 |
openshift-ci
bot
added
the
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 |
openshift-ci
bot
added
lifecycle/rotten
|
/remove-lifecycle rotten |
openshift-ci
bot
removed
the
lifecycle/rotten
liouk
force-pushed
the
direct-external-oidc-provider
branch
from
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. |
liouk
changed the title
openshift-ci
bot
removed
the
do-not-merge/work-in-progress
|
|
||
| ## 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.
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.
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.
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 |
openshift-ci
bot
added
the
approved
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.