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 docs35% off certifications and e-learning with code SEPT26BTS35, or 40% off bundles and instructor-led training with SEPT26BTS40. New this month: the MCPA (Model Context Protocol Associate) certification.
Kubernetes Access via Public Clients: Mastering OIDC with PKCE
Unlock secure Kubernetes access by leveraging public clients and PKCE. This approach mitigates the risk of intercepted authorization codes, ensuring robust authentication. Dive in to learn how to configure your identity provider effectively.
Mastering Vulnerability Reports in Open Source: A Kubernetes Perspective
Handling vulnerability reports is crucial for maintaining the integrity of your open source projects. Establish a clear reporting path in your SECURITY.md file to streamline the process. This article dives into the mechanics of vulnerability management and the importance of embargo periods.
KubeletInUserNamespace: Elevating Security in Kubernetes v1.37
Kubernetes v1.37 takes a significant step in security by promoting the KubeletInUserNamespace feature gate to beta. This feature allows node components to run as non-root users, reducing the risk of potential damage. Discover how this works and what you need to know for production.
Get the daily digest
One email. 5 articles. Every morning.
No spam. Unsubscribe anytime.