Skip to content
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

Merged
merged 2 commits into from
Oct 18, 2018

Conversation

nckturner
Copy link
Contributor

@nckturner nckturner commented Oct 13, 2018

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

@k8s-ci-robot k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label Oct 13, 2018
@k8s-ci-robot k8s-ci-robot added approved Indicates a PR has been approved by an approver from all required OWNERS files. size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Oct 13, 2018
@nckturner
Copy link
Contributor Author

/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.

@k8s-ci-robot k8s-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Oct 13, 2018
@nckturner nckturner force-pushed the expiration branch 2 times, most recently from 2d0671d to 61e7e6d Compare October 15, 2018 16:54
@nckturner
Copy link
Contributor Author

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,
Copy link

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?

Copy link
Contributor Author

@nckturner nckturner Oct 18, 2018

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.

Copy link

@wesleyk wesleyk left a 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!

Copy link
Contributor

@mattlandis mattlandis left a 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 Show resolved Hide resolved
@@ -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)
Copy link
Contributor

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.)

@nckturner
Copy link
Contributor Author

/hold cancel

@k8s-ci-robot k8s-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Oct 18, 2018
@k8s-ci-robot k8s-ci-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Oct 18, 2018
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.
@mattlandis
Copy link
Contributor

/lgtm
/approve

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Oct 18, 2018
@k8s-ci-robot
Copy link
Contributor

[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:
  • OWNERS [mattlandis,nckturner]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot merged commit 4ee748e into kubernetes-sigs:master Oct 18, 2018
@nakulpathak3
Copy link

hey I know this went in but I'm getting 403 Forbidden "could not get token: AccessDenied: Access denied" error at random times still. I'm using the Kubernetes Python Client which implemented the usage of aws-iam-authenticator here - https://github.com/kubernetes-client/python-base/blob/master/config/exec_provider.py#L77. This is happening after creating a role and using the -r flag not with normal user accounts.

@mlafeldt
Copy link

Verified that this is working with kubectl proxy. Good job!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. lgtm "Looks good to me", indicates that a PR is ready to be merged. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants