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 →Extend Your CKA Certification: The Power of CKS
Want to keep your Kubernetes Administrator certification current? Passing the Certified Kubernetes Security Specialist (CKS) exam now extends your CKA certification. This new feature simplifies credential maintenance for cloud-native professionals.
Building a Multi-Agent Security Platform on Kubernetes: Why Cloud Native is Key
Cloud-native architecture is essential for deploying agentic AI effectively. Discover how using the A2A protocol and mTLS can enhance inter-agent communication and security in your Kubernetes environment.
Locking Down Dependencies in CI/CD: A Must for Open Source Projects
In the world of open source, securing your CI/CD pipeline is non-negotiable. Pinning GitHub Actions by SHA digest is a critical step to prevent compromised code from sneaking into your workflows. Let's dive into how to implement this effectively.
Get the daily digest
One email. 5 articles. Every morning.
No spam. Unsubscribe anytime.