Kubernetes v1.35: Streamlining Service Account Token Handling for CSI Drivers
Kubernetes v1.35 introduces a beta feature that changes the way CSI drivers receive service account tokens. This is crucial for ensuring that sensitive information is handled securely and efficiently. The TokenRequests feature allows CSI drivers to request tokens for workload identity, which is vital for maintaining security in your Kubernetes environment.
The mechanism is straightforward. By default, service account tokens are placed in the VolumeContext with the key csi.storage.k8s.io/serviceAccount.tokens. However, with the new serviceAccountTokenInSecrets field in the CSIDriver spec, you can opt to have these tokens delivered via the Secrets field instead. When this field is set to true, the driver will first check the Secrets field for tokens before falling back to the VolumeContext. This change not only enhances security but also aligns better with Kubernetes' overall approach to managing sensitive data.
In production, this means you should evaluate your current CSI driver configurations. Opting into this new behavior can help you manage service account tokens more securely. However, be cautious: the documentation warns against using example configurations directly in your clusters. Always tailor configurations to your specific needs and security requirements.
Key takeaways
- →Use the `serviceAccountTokenInSecrets` field to enhance security by opting for token delivery via Secrets.
- →Understand that tokens are placed in VolumeContext by default unless you opt-in to the new behavior.
- →Check the Secrets field first for tokens when implementing the new mechanism in your CSI driver.
Why it matters
This change reduces the risk of exposing sensitive tokens and aligns with best practices for managing secrets in Kubernetes, ultimately leading to a more secure production environment.
Code examples
1const serviceAccountTokenKey = "csi.storage.k8s.io/serviceAccount.tokens"
2func getServiceAccountTokens(req *csi.NodePublishVolumeRequest) (string, error) {
3 // Check secrets field first (new behavior when driver opts in)
4 if tokens, ok := req.Secrets[serviceAccountTokenKey]; ok {
5 return tokens, nil
6 }
7 // Fall back to volume context (existing behavior)
8 if tokens, ok := req.VolumeContext[serviceAccountTokenKey]; ok {
9 return tokens, nil
10 }
11 return "", fmt.Errorf("service account tokens not found")
12}When NOT to use this
The official docs don't call out specific anti-patterns here. Use your judgment based on your scale and requirements.
Want the complete reference?
Read official docsUnified observability — logs, uptime monitoring, and on-call in one place. Used by 50,000+ engineering teams to ship faster and sleep better.
Try Better Stack free →Runtime Supply Chain Verification with NRI: Securing Your Kubernetes Deployments
In a world where supply chain attacks are rampant, ensuring the integrity of your container images is crucial. The Node Resource Interface (NRI) allows you to enforce supply chain verification at runtime, leveraging plugins to validate image attestations before they even start. Dive into how this mechanism works and what you need to watch out for in production.
Unlocking Data Security: Confidential Containers in Kubernetes
Confidential Containers are revolutionizing data protection in cloud-native environments by leveraging Trusted Execution Environments (TEEs). This technology ensures that sensitive workloads can run securely on third-party infrastructure without exposing data to operators.
Making Kyverno Think It's in Production: A Practical Guide
Ever wondered how to test your Kubernetes policies without deploying them? Learn how to leverage Kyverno's CLI to simulate a production environment, ensuring your policies are battle-tested before they hit the cluster. This article dives into the mechanics of using resolveResourcesMockData for reliable policy evaluation.
Get the daily digest
One email. 5 articles. Every morning.
No spam. Unsubscribe anytime.