-
Notifications
You must be signed in to change notification settings - Fork 423
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
Add expiration to token creation #160
Conversation
/hold Going to change the value of expiration parameter to Presign() back to 60, since changing it to 900 (15 minutes) breaks backwards compatibility of tokens, and it doesn't have any effect :D I think its reasonable to increase the range of accepted values for the x-amz-expires header, in case we want to push STS to support it in the future. |
2d0671d
to
61e7e6d
Compare
I set the value of the Presign() parameter back to 60, but left the accepted values on the server side from 0-15 minutes. Based on what I've heard, people would use a longer token expiration than 15 minutes, so if STS is willing to support x-amz-expires at some point in the future, then we should decide what the longest expiration we are willing to allow. That can be done in a future change. |
execInput := &clientauthv1alpha1.ExecCredential{ | ||
TypeMeta: metav1.TypeMeta{ | ||
APIVersion: "client.authentication.k8s.io/v1alpha1", | ||
Kind: "ExecCredential", | ||
}, | ||
Status: &clientauthv1alpha1.ExecCredentialStatus{ | ||
Token: token, | ||
ExpirationTimestamp: &expirationTimestamp, |
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.
Will this expiration continually be pushed back with each call to FormatJSON, as it's calculated based on now + refreshTokenAfter?
Or is it the case that the authentication layer will understand, based on the initial ExecCredentialStatus, that it a refresh should occur after the provided ExpirationTimestamp?
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 is the FormatJSON is executed each time a token is generated, and the response is cached in client-go. This will solve the issue where client-go is running continuously, like in the sample program provided in the issue, or in kubelet, etc. For kubectl, we need client caching in a file, for which there is currently another PR open. I did refactor a little based on your comment (no functionality change) where its now generating the expiration next to the place where the token is generated. The expiration of the token is based on the x-amz-date
header, so I could try deriving the expiration from that instead, which is more correct, though in practice I doubt there would be a noticeable difference from the two timestamps.
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.
Looks good to me, but I don't have full context on the code. Thanks for the help Nick!
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.
Looks good. Only a few small comments.
pkg/token/token.go
Outdated
@@ -125,15 +140,15 @@ type getCallerIdentityWrapper struct { | |||
// Generator provides new tokens for the heptio authenticator. | |||
type Generator interface { | |||
// Get a token using credentials in the default credentials chain. | |||
Get(string) (string, error) | |||
Get(string) (*Token, error) |
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 would prefer returning an empty struct to nil since we don't use it as a pointer (modify contents etc.)
/hold cancel |
STS presigned urls expire after 15 minutes, and its unconfigurable, so we refresh tokens after 14 minutes to prevent getting occasional unauthorized responses.
- Rename expiration variables to reflect their actual use - Create Token struct so that we can generate the expiration time immediately after we presign the token, and return the Token struct from the generate token functions.
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mattlandis, nckturner 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 |
hey I know this went in but I'm getting |
Verified that this is working with |
STS presigned urls expire after 15 minutes, and are not configurable,
so we refresh tokens after 14 minutes to prevent getting occasional
unauthorized responses.
Fixes #133