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

Support expirationTimestamp with ExecCredential credentials #3998

Closed
joelthompson opened this issue Mar 23, 2022 · 3 comments
Closed

Support expirationTimestamp with ExecCredential credentials #3998

joelthompson opened this issue Mar 23, 2022 · 3 comments

Comments

@joelthompson
Copy link

Is your enhancement related to a problem? Please describe

When using IAM authentication with AWS EKS, AWS generates a kubeconfig that includes exec credentials that are generated by calling aws eks get-token. The token returned includes an expirationTimestamp, and the credentials themselves expire after 15 minutes:

aws eks get-token --cluster-name my-cluster
{"kind": "ExecCredential", "apiVersion": "client.authentication.k8s.io/v1alpha1", "spec": {}, "status": {"expirationTimestamp": "2022-03-23T20:45:33Z", "token": "k8s-aws-v1.<token_value>"}}

However, the current code execs the command once and only once, and discards the expirationTimestamp:

ExecConfig exec = currentAuthInfo.getExec();
if (exec != null) {
ExecCredential ec = getExecCredentialFromExecConfig(exec, configFile);
if (ec != null && ec.status != null && ec.status.token != null) {
config.setOauthToken(ec.status.token);

The result is that if you load a config once and use a client for more than 15 minutes (e.g., waiting for a long-running Job to finish), it will start to fail to authenticate after the credentials expired.

Describe the solution you'd like

The Client should store the command used to generate the credentials and the credential expiration time; when the credentials are close to expiring, they should attempt to be automatically renewed.

Describe alternatives you've considered

To work around this, I have to have some ugly-ish code which tracks how long a given client has been in existence and throw it away and create a new one when the expiration time approaches.

Additional context

The most similar issue I've seen is #2112 but that seems to be more specific to the GKE use case, rather than using ExecCredentials. There's also a TODO in the code to store the expirationTimestamp:

@JsonIgnoreProperties(ignoreUnknown = true)
private static final class ExecCredentialStatus {
public String token;
// TODO clientCertificateData, clientKeyData, expirationTimestamp
}

@stale
Copy link

stale bot commented Jun 22, 2022

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!

@manusa
Copy link
Member

manusa commented Jun 23, 2022

Relates to #2112 and #2271

@manusa manusa added this to the 6.x milestone Jun 23, 2022
@shawkins
Copy link
Contributor

Proactive or failure refreshing of the credential regardless of the source has been added to both refresh interceptors. This will hopefully be formalized a bit more with the work being done under #4951

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants