Ever caught your CSI driver spilling Kubernetes service account tokens into logs — like a drunk uncle at a wedding?
Kubernetes v1.35 changes that. Subtly. Powerfully. It’s a refinement for CSI drivers using TokenRequests, shoving those sensitive tokens into the secrets field where they belong, not the leaky volume_context. And here’s the beauty: no explosions for existing setups.
Think of it like upgrading from paper envelopes to armored vaults for your secrets. Previously, tokens landed in volume_context — functional, sure, but a magnet for logging mishaps. Protologgers didn’t sanitize it, leading to CVEs that made admins sweat.
Why Were CSI Tokens Logging in the First Place?
CSI specs have a secrets field screaming “sensitive data here!” But history — stubborn history — stuck tokens in volume_context under the key csi.storage.k8s.io/serviceAccount.tokens. Drivers grabbed them there. Fine, until logs betrayed them.
While this has worked, it’s not the ideal place for sensitive information, and we’ve seen instances where tokens were accidentally logged in CSI drivers.
That’s straight from the Kubernetes release notes. Spot on. Remember CVE-2023-2878 in Secrets Store CSI? Or CVE-2024-3744 in Azure File? Tokens in plain sight. Each driver hacking its own sanitizer? Chaos.
But Kubernetes v1.35? It whispers, “Opt in if you dare.”
A single flag in your CSIDriver spec: serviceAccountTokenInSecrets: true. Defaults to false, so your ancient volumes hum along. Flip it, and tokens migrate to secrets. Clean. Compliant. No more log roulette.
How Kubernetes v1.35’s Opt-In Actually Works
Picture this: You’re authoring a CSI driver. First, beef up your NodePublishVolumeRequest handler with fallback logic. Check secrets first, then volume_context. Backward compatible from day zero.
const serviceAccountTokenKey = "csi.storage.k8s.io/serviceAccount.tokens"
func getServiceAccountTokens(req *csi.NodePublishVolumeRequest) (string, error) {
// New way first
if tokens, ok := req.Secrets[serviceAccountTokenKey]; ok {
return tokens, nil
}
// Old faithful
if tokens, ok := req.VolumeContext[serviceAccountTokenKey]; ok {
return tokens, nil
}
return "", fmt.Errorf("service account tokens not found")
}
Ship that now. Even on pre-1.35 clusters. Then, post-upgrade, toggle the flag. Volumes republish smoothly — Kubernetes handles the handoff.
The feature gate? CSIServiceAccountTokenSecrets. Beta, enabled by default. Why beta straight away? Defaults preserve behavior. No alpha jitters.
And drivers? They keep humming unless you say otherwise. Smart.
This isn’t just a patch. It’s Kubernetes flexing its maturity — like how it tamed static service account tokens into bound ones back in 1.21. Remember that shift? Clusters didn’t crumble; they hardened. Same vibe here. My bold call: By v1.37, 80% of token-using drivers will opt-in, turbocharging workload identity for storage. Enterprise storage wars just got a security edge.
Does Kubernetes v1.35 Break My CSI Drivers?
Nope. Zero breakage. Opt-in means opt-in. Your v1.34 cluster? Identical. Fallback code? Your shield.
But wait — rollout dance matters. Prep driver with fallback (do it yesterday). Deploy. Cluster upgrades to 1.35 (feature gate auto-on). Test. Then flip the flag on CSIDriver. New volumes? Secrets-only bliss. Old ones? Graceful during republish.
CSI maintainers, this is your green light. Backport that fallback. Cut releases. Watch logs go quiet.
Skeptical? Fair. Kubernetes PR spins plenty. But this? Concrete. CVE-proven problem, spec-aligned fix. No hype — just evolution.
Imagine scaling storage in a multi-tenant cluster. Tokens leaking? Nightmare fuel for compliance. Now? Vaulted away. Workload identity flows smoother, CSI atop cloud providers (EBS, GCE PD, Azure) gets fortress-grade.
It’s a platform nudge toward safer defaults. Like electricity standardizing on grounded outlets — invisible until it saves your hide.
And the wonder? Kubernetes at v1.35 feels alive, iterating without ego. Thousands of drivers, millions of pods — all safer tomorrow.
Short version: Update. Opt-in. Sleep better.
Why Should CSI Driver Devs Care About Kubernetes v1.35?
Because inconsistency kills. Every driver sanitizing differently? Recipe for more CVEs. This unifies. Specs honored. Logs sanitized by protosanitizer out-of-box.
Plus, future-proofs you. TokenRequests for audience-bound JWTs? Now properly plumbed. No more VolumeAttributes hacks.
One caveat: Test republishes. Edge cases lurk. But Kubernetes docs guide you.
This shift echoes Unix philosophy — do one thing, securely. CSI secrets field was waiting. v1.35 unlocks it.
🧬 Related Insights
Frequently Asked Questions
What does Kubernetes v1.35 change for CSI service account tokens?
It adds an opt-in to pass tokens via the secrets field instead of volume_context, fixing log leaks without breaking existing drivers.
Does Kubernetes v1.35 require CSI driver updates?
Not immediately — add fallback logic first for safety, then opt-in later.
Is Kubernetes v1.35’s CSI token feature stable?
Beta, enabled by default, backward-compatible design makes it production-ready now.
