Kubernetes v1.35: Safer CSI Service Account Tokens

Kubernetes v1.35 just solved a problem that's been nagging CSI driver maintainers for years.

Service account tokens have been passed through volume_context. It worked. But it's the wrong place for secrets. Tokens ended up in logs. CVE-2023-2878, CVE-2024-3744—real incidents, real damage.

Now there's an opt-in mechanism. Tokens can live in the secrets field where they belong. Backward compatible. No breaking changes. Each CSI driver chooses when to move.

Here's what you need to know:

The Problem: Volume context isn't designed for sensitive data. The protosanitizer tool doesn't treat it as sensitive. Logs leak tokens. Every driver had to bolt on its own sanitization. Inconsistent. Messy.

The Solution: CSI drivers can now opt into receiving tokens via the secrets field in NodePublishVolumeRequest. It's already part of the CSI spec. It's designed for this. The feature gate is on by default. Defaults to false, so nothing breaks.

For Driver Authors: Add fallback logic now. Check both locations. Ship it before upgrading your cluster. Then, after your driver pods roll out, update the CSIDriver manifest to set serviceAccountTokenInSecrets: true. Timing matters. Don't flip the switch before pods are ready.

Why This Matters: No more accidental token logging. Uses the right field. protosanitizer handles it correctly without driver-specific workarounds. You control the migration pace.

This is one of those features that doesn't sound flashy but fixes real operational headaches. If you run CSI drivers, start preparing now.