EKSAuthentication: no token refresh — single ApiClient becomes unusable after ~15 minutes

[hwayoungjun]

Library Version: 24.0.0
Java Version: 21

Description

EKSAuthentication.provide(ApiClient) bakes the bearer token via
client.setApiKey() at ApiClient build time. The token is a SigV4-signed
STS GetCallerIdentity URL whose X-Amz-Expires is capped at 900 seconds
by aws-iam-authenticator, so any single ApiClient instance becomes
unusable ~15 minutes after construction.

In a deployment where a single ApiClient is intended to live for the
process lifetime, we currently use a custom Authentication implementation
— SigV4 presign + an OkHttp Interceptor that injects a fresh
Authorization header per request, backed by a token cache that refreshes
shortly before expiry.

The library already has RefreshAuthentication, which implements the
OkHttp Interceptor pattern for periodic token refresh. The same approach
would apply naturally to EKSAuthentication.

Question

Is the current static-bearer behavior intentional (e.g., assuming
short-lived kubectl-style usage)? Or should EKSAuthentication adopt the
interceptor pattern internally?

If the latter, I'd be happy to send a PR.

[brendandburns]

I don't think the current implementation with only one token is on purpose, we'd gladly accept a PR to add refresh, thanks