Support expirationTimestamp with ExecCredential credentials

[joelthompson]

trafficstars

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: https://github.com/fabric8io/kubernetes-client/blob/655f4de83da450dd20dc0a889dce7b42f794cc47/kubernetes-client-api/src/main/java/io/fabric8/kubernetes/client/Config.java#L701-L705

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: https://github.com/fabric8io/kubernetes-client/blob/655f4de83da450dd20dc0a889dce7b42f794cc47/kubernetes-client-api/src/main/java/io/fabric8/kubernetes/client/Config.java#L814-L818

[stale[bot]]

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]

Relates to #2112 and #2271

[shawkins]

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