Confirmation About BoundServiceAccountToken

[infinitydon]

What help do you need？

Hi,

I want to confirm if spiderpool takes care of token generation as per the new guideline from k8s 1.21 as per below:

Kubernetes version 1.21 graduated BoundServiceAccountTokenVolume feature [1] to beta and enabled it by default. This feature improves security of service account tokens by requiring a one hour expiry time, over the previous default of no expiration. This means that applications that do not refetch service account tokens periodically will receive an HTTP 401 unauthorized error response on requests to Kubernetes API server with expired tokens. You can learn more about the BoundServiceAccountToken feature in EKS Kubernetes 1.21 release notes [2].
To enable a smooth migration of applications to the newer time-bound service account tokens, EKS v1.21+ extends the lifetime of service account tokens to 90 days. Applications on EKS v1.21+ clusters that make API server requests with tokens that are older than 90 days will receive an HTTP 401 unauthorized error response.

How can you resolve the issue?

To make the transition to time bound service account tokens easier, Kubernetes has updated the below official versions of client SDKs to automatically refetch tokens before the one hour expiration:

Go v0.15.7 and later
Python v12.0.0 and later
Java v9.0.0 and later
Javascript v0.10.3 and later
Ruby master branch
Haskell v0.3.0.0
We recommend that you update your application and its dependencies to use one of the above client SDK versions if you are on an older version.

[ty-dc]

The adapted version we tested is Kubernetes version 1.22 and above. As you said, there may be omissions for 1.21.

[infinitydon]

@ty-dc - Let me clarify what I am asking about, what I want to confirm is if spiderpool is implementing the best practices for managing service account token expirations introduced in Kubernetes 1.21 and above? Specifically, how are you handling the hourly token renewal requirement?

You can also check k8snetworkplumbingwg/whereabouts#459 as an example of how it is affecting whereabouts

[ty-dc]

The spiderpool certificate is stored in the spiderpool-controller-server-certs secret of the installed account, automatically generated by helm, and is valid for 200 years. spiderpool does not have best practices for managing service account token expiration, If you need this, you can use the cert manager method in the chart to manage it.