AWS EKS 1.21中Projected Service Account Token默认过期时间异常问题求助

Let's break down what's happening here and how to resolve this quirky issue:

The Core Problem #

You're hitting a version-specific behavior in EKS 1.21's OIDC integration: when using the default expirationSeconds: 3607 (Kubernetes' built-in default for projected tokens, designed to avoid clock sync issues by adding 7 seconds to a 1-hour window), AWS's OIDC issuer overrides this value with its own 1-year default expiry. When you explicitly set any other value (like 3600), the issuer respects your configured expiration time—hence the inconsistent behavior you're observing.

Why This Happens #

Kubernetes uses 3607 as the default to prevent token refresh from aligning exactly with hourly intervals (reducing load spikes on the control plane). However, in EKS 1.21's OIDC implementation, the issuer treats this specific default value as a signal to use its own long-lived token setting instead of honoring Kubernetes' intended default. This quirk has been fixed in newer EKS releases (1.22+), but for 1.21, we need a targeted workaround.

Solutions to Correct the Expiry Time #

1. Explicitly Define expirationSeconds
   Skip relying on the implicit 3607 default and set your desired expiry time directly in the projected volume config. For a standard 1-hour expiry:

   volumes:
   - name: kube-api-access-b4xt9
     projected:
       defaultMode: 420
       sources:
       - serviceAccountToken:
           expirationSeconds: 3600  # Explicitly set 1-hour expiry instead of using default 3607
           path: token
       # ... keep your existing configMap and downwardAPI sources
   

   After updating your Deployment and rolling out new pods, the projected token will have an expiry matching your configured value, and Kubernetes' hourly refresh mechanism will work as intended.

2. Validate Kube-APIServer Configuration
   Double-check that your --service-account-max-token-expiration="24h0m0s" parameter is active on the kube-apiserver:

   • List the kube-apiserver pods in the kube-system namespace:

     kubectl get pods -n kube-system | grep kube-apiserver
     

   • Inspect the pod's command arguments to confirm the parameter exists:

     kubectl exec -n kube-system <kube-apiserver-pod-name> -- ps aux | grep service-account-max-token-expiration
     

   If the parameter is missing, update your EKS control plane configuration (via AWS Console or eksctl) to include it and restart the apiserver.

3. Upgrade EKS (If Environment Allows)
   This default-value override behavior was addressed in EKS versions 1.22 and later. If your infrastructure can support an upgrade, moving to a newer EKS release will resolve the issue without needing to explicitly set expirationSeconds for every deployment.

Verification Step #

After applying the fix, exec into a pod to confirm the token expiry is correct:

kubectl exec -it <your-pod-name> -n sbx -- cat /var/run/secrets/kubernetes.io/serviceaccount/token | jq '.exp, .iat'

You should see the exp timestamp exactly 3600 seconds (or your configured value) after the iat timestamp, instead of the 1-year gap you were seeing before.

内容的提问来源于stack exchange，提问作者ncsibra