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

reload service account token after expiry #967

Merged
merged 1 commit into from
Jun 5, 2020

Conversation

zshihang
Copy link
Contributor

@zshihang zshihang commented Jun 2, 2020

fixes #652. by default, this will set an expiration period of 1 minutes on service account token. as we are graduating the Beta feature Projected Service Account Volume to GA, we expect clients to reload token before it expires.

@k8s-ci-robot k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label Jun 2, 2020
@k8s-ci-robot
Copy link
Contributor

Welcome @zshihang!

It looks like this is your first PR to kubernetes-client/java 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-client/java has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

@k8s-ci-robot k8s-ci-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Jun 2, 2020
@zshihang
Copy link
Contributor Author

zshihang commented Jun 2, 2020

/assign @brendandburns

we can use the same approach here to fix #290.

Copy link
Member

@yue9944882 yue9944882 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thank you for starting this

import okhttp3.Request;
import okhttp3.Response;

public class TokenFileAuthentication implements Authentication, Interceptor {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i presume using Interceptor to hijack the header is a bit overkilling.. the previous approach by AccessTokenAuthentication is setting tokens by ((ApiKeyAuth) auth).setApiKey(apiKey); in the provide call, wdyt if we do the token-reloading similarly?

Copy link
Contributor Author

@zshihang zshihang Jun 2, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the current openapi doesn't have reloading logic in ApiKeyAuth which will only be set once in the initialization of in-cluster client. i couldn't figure out a way to achieve what you described without making changes to openapi.

we need something similar to this change OpenAPITools/openapi-generator#6036 (it might take much longer time to merge) to implement reloading.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the current openapi doesn't have reloading logic in ApiKeyAuth which will only be set once in the initialization of in-cluster client.

convinced, can you leave a TODO comment to reference OpenAPITools/openapi-generator#6036 so that we can converge in the future?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, done


@Override
public void provide(ApiClient client) {
OkHttpClient withInterceptor = client.getHttpClient().newBuilder().addInterceptor(this).build();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the # of interceptors seems to be growing unboundly upon every provide call, isn't it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, the assumption is made that the provide function is called only once for each in-cluster client. i am not sure when a user will call this twice on the same client instance.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the assumption is made that the provide function is called only once for each in-cluster client.

yea, that's true

builder.setCertificateAuthority(Files.readAllBytes(Paths.get(SERVICEACCOUNT_CA_PATH)));
builder.setAuthentication(new AccessTokenAuthentication(token));
builder.setAuthentication(new TokenFileAuthentication(SERVICEACCOUNT_TOKEN_PATH));
Copy link
Member

@yue9944882 yue9944882 Jun 2, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we need to keep backward compatibility and users are expected to opt-in to the change. wdyt add a constructor w/ parameter reloadInterval and factor the original cluster() to adopt an infinite (or zero) interval?

NOTE: even tho minute-ish reloading SA is always recommended and users are even supposed to be not aware of the change, i suppose it will take a release or two for users to get onboard to the SA rotation..

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cluster() with reloading should be the default so that users dont have to do anything to migrate and add a oldCluster as the fail safe.

update the InClusterClusterExample to something like:

// new style
ApiClient client = ClientBuilder.cluster().build();

// old style
ApiClient client = ClientBuilder.oldCluster().build();

WDYT?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cluster() with reloading should be the default so that users dont have to do anything to migrate and add a oldCluster as the fail safe.

yea we should also reflect how to opt-in SA reloading in the example. note that there's two aspects of change the pull is involving:

  1. introducing capability for periodical SA reloading
  2. moving default behavior the in-cluster client to 1-min reloading (preserving the old-style method or not)

the first is good while i'm leaning on doing the second in another release. i will defer to @brendandburns for thoughts

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's just do the whole thing. We haven't cut a 9.0.0 release yet so I think it's ok to make this change in the 9.0.0 release.

Copy link
Member

@yue9944882 yue9944882 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jun 3, 2020
@zshihang
Copy link
Contributor Author

zshihang commented Jun 3, 2020

thanks for the review. need /approval label to merge.

@yue9944882
Copy link
Member

/approve

@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: yue9944882, zshihang

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jun 5, 2020
@k8s-ci-robot k8s-ci-robot merged commit 913ecb9 into kubernetes-client:master Jun 5, 2020
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.

client should periodically reload InClusterConfig token
4 participants