Refresh service account tokens

[DonnyOlijslager]

AWS has graduated the BoundServiceAccountTokenVolume to the feature status in Kubernetes 1.21.

If I understand the feature correctly that means that in the future the service account tokens will be expired after an hour. This means that the token will have to be refreshed from disk within that time. At the moment the library does not reload the token.

AWS has updated it's clients to refresh the tokens before the expiry time. Since this library does not use the java client the token has to be refreshed manually.

Documentation: kubernetes/enhancements#542

Thanks,
Donny

[rhusar]

Thanks @DonnyOlijslager for bringing this up. I believe your interpretation is correct. The protocol will have to refresh the service token once it's expired after parsing out the JWT token file.

The proposal was https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md
The change was implemented in the client by kubernetes-client/java#1810

[kendyjm]

Hi @rhusar !
what eta do we have on this issue ?
brds,
kendy

[gazal-k]

We have a JVM application that uses jGroups TCP_NIO2 and KUBE_PING for discovery. I was alarmed by this issue, but we haven't yet encountered any application issues related to this.

What is the impact of KUBE_PING not refreshing service account tokens?

[gazal-k]

I think I found the answer to my question.

https://docs.aws.amazon.com/eks/latest/userguide/service-accounts.html

To enable a smooth migration of clients to the newer time-bound service account tokens, Kubernetes version 1.21 and later adds an extended expiry period to the service account token over the default one hour. For Amazon EKS clusters, the extended expiry period is 90 days.

Can't find any docs on when this will change, but sounds like we should update the client soon.

[belaban]

Can we close this issue @gazal-k ?

[gazal-k]

The issue has not been fixed yet @belaban, it just hasn't become a high priority yet.

I think jgroups-kubernetes could use https://github.com/kubernetes-client/java or it would need a change similar to kubernetes-client/java#1810

[rhusar]

@belaban Right, this still needs fixing due to reasons @gazal-k posted above. Assigned to myself in the meantime, haven't gotten to it yet.

[belaban]

OK

[gazal-k]

Any thoughts on what the direction would be for the change? Like, should this be refactored to use https://github.com/kubernetes-client/java or just amend the custom code for interacting with k8s control plane?

Switching to using https://github.com/kubernetes-client/java probably means adopting further changes (even breaking ones) to k8s APIs could become easier.
But the very minimal APIs jgroups-kubernetes uses probably doesn't warrant having a dependency on https://github.com/kubernetes-client/java