-
Notifications
You must be signed in to change notification settings - Fork 188
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
Introduce changes from master to sig-auth-acceptance branch #300
base: sig-auth-acceptance
Are you sure you want to change the base?
Changes from 1 commit
b438fe7
ad75c81
c598642
7382c08
7aaa847
142ff30
a817834
c7e1aff
0b4a724
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -20,6 +20,7 @@ import ( | |
"context" | ||
"net/http" | ||
|
||
"k8s.io/apiserver/pkg/apis/apiserver" | ||
"k8s.io/apiserver/pkg/authentication/authenticator" | ||
"k8s.io/apiserver/pkg/authentication/request/bearertoken" | ||
"k8s.io/apiserver/pkg/server/dynamiccertificates" | ||
|
@@ -36,20 +37,30 @@ var ( | |
) | ||
|
||
// NewOIDCAuthenticator returns OIDC authenticator | ||
func NewOIDCAuthenticator(config *OIDCConfig) (*OIDCAuthenticator, error) { | ||
func NewOIDCAuthenticator(ctx context.Context, config *OIDCConfig) (*OIDCAuthenticator, error) { | ||
dyCA, err := dynamiccertificates.NewDynamicCAContentFromFile("oidc-ca", config.CAFile) | ||
if err != nil { | ||
return nil, err | ||
} | ||
|
||
tokenAuthenticator, err := oidc.New(oidc.Options{ | ||
IssuerURL: config.IssuerURL, | ||
ClientID: config.ClientID, | ||
tokenAuthenticator, err := oidc.New(ctx, oidc.Options{ | ||
JWTAuthenticator: apiserver.JWTAuthenticator{ | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. can we remove the old options and just wire the new config, since we have the chance? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not quite what I had in mind. Keeping the legacy struct for legacy options is fine, and I think preferable. Perhaps this is not for this PR (I'd rather we removed |
||
Issuer: apiserver.Issuer{ | ||
URL: config.IssuerURL, | ||
Audiences: []string{config.ClientID}, | ||
}, | ||
ClaimMappings: apiserver.ClaimMappings{ | ||
Username: apiserver.PrefixedClaimOrExpression{ | ||
Prefix: &config.UsernamePrefix, | ||
Claim: config.UsernameClaim, | ||
}, | ||
Groups: apiserver.PrefixedClaimOrExpression{ | ||
Prefix: &config.GroupsPrefix, | ||
Claim: config.GroupsClaim, | ||
}, | ||
}, | ||
}, | ||
CAContentProvider: dyCA, | ||
UsernameClaim: config.UsernameClaim, | ||
UsernamePrefix: config.UsernamePrefix, | ||
GroupsClaim: config.GroupsClaim, | ||
GroupsPrefix: config.GroupsPrefix, | ||
SupportedSigningAlgs: config.SupportedSigningAlgs, | ||
}) | ||
if err != nil { | ||
|
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 happens when you supply the request header nil here? It won't get autodetected from the cluster, right?
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.
TODO add explanation of what nil does.
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 enables you to cleanse custom headers that you use for your proxy to contain additional information. It is necessary to drop those.
We write custom headers in case of request headers and we read custom headers based on the rewrite logic: link.
The rewrite logic for Query parameters relies on upstream to interpret them, which is usually a hostile behavior that you want to avoid, but in our case, we want Prometheus to be able to interpret it. Therefore I am hesitant to introduce it for custom headers as well. We could add a boolean flag that defaults to true, which enables / disables cleansing of header values? WDYT @stlaz?
Ref: k8s.io/apiserver/pkg/endpoints/filters/authentication.go
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.
We should avoid forwarding the default headers at least, which is what
WithAuthentication()
does already.Generally I think we should drop any headers we're processing, more so if we're using them for authentication. I don't think we wired any authn via request headers, correct?
Outside of that we should also make sure that none of the headers we produce can be just passed upstream from the original request.