-
Notifications
You must be signed in to change notification settings - Fork 574
Direct OIDC configuration #1614
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
Conversation
Hello @stlaz! Some important instructions when contributing to openshift/api: |
53f216a
to
475a752
Compare
166804e
to
d44bc77
Compare
cdd7c02
to
f17549a
Compare
f17549a
to
67c5422
Compare
KubeConfigKey = "kubeConfig" | ||
) | ||
|
||
type OIDCProvider struct { |
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.
Consider for future, no need right now.
Is this the right scope for configuring a clientID and reference to a clientSecret for the console
Pros:
- keeps configuration close together from a user perspective
- will allow different clientIDs for different oidc providers for console
Cons?
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.
Each client for each application should be different, or should be provided with means to request tokens with different audiences (e.g. the resource
parameter). That means that should we choose to configure client parameters via this API, we need to make it configurable for a number of clients. That can get messy, but is still doable.
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.
Yesterday, Seth argued the opposite: specifically name every clientID/secret pair. We should get on the same page.
67c5422
to
4f09bdb
Compare
2bb98ac
to
1969932
Compare
1969932
to
90a73ec
Compare
0dac365
to
d0f11a6
Compare
// +kubebuilder:validation:Enum={"", "NoPrefix", "Prefix"} | ||
PrefixPolicy UsernamePrefixPolicy `json:"prefixPolicy"` | ||
|
||
Prefix *UsernamePrefix `json:"prefix"` |
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.
There is still no CEL here.
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.
Test should be able to prove CEL is missing.
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.
Not sure which CEL validation is missing. I defined some rules on the object level.
I added tests that prove that the current CEL works as expected.
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.
Oh, I see my review mistake. Realized it in the shower this morning. Agreed.
/lgtm |
/approve |
/refresh |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: deads2k, stlaz 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 is an API to openshift/enhancements#1493