Kubernetes 1.35 locks down rogue exec plugins

Kubernetes 1.35: Taking Control of Credential Plugin Execution 🔐

Here's a scenario that probably keeps your security team awake: your kubeconfig can run arbitrary shell scripts with your full user privileges, and you might not even know it's happening. Every time you download or auto-generate a kubeconfig file, the exec.command field can invoke executables to fetch credentials on your behalf. Powerful feature, absolutely. But dangerous if you don't know what's running.

Now imagine a supply-chain attack hits the pipeline generating your kubeconfig, or worse, someone compromises the system that creates it. An attacker could trick your kubeconfig into executing malicious code with your privileges. No prompts. No warnings. Just code running on your machine.

Kubernetes 1.35 finally addresses this. SIG-Auth and SIG-CLI added credential plugin policies and allowlists as a beta feature, giving you real control over what gets executed on your system.

How It Works

The new security controls live in your kuberc configuration file. Two new fields do the heavy lifting: credentialPluginPolicy and credentialPluginAllowlist. Add them, and kubectl stops running plugins without permission.

Three policy modes exist. First, AllowAll (or omitting the fields entirely) maintains the old behavior—all plugins run. Second, DenyAll blocks everything. This is useful for discovering what plugins your kubeconfig actually needs. Run kubectl with DenyAll, watch the errors, and you'll know exactly what's trying to execute.

Third, Allowlist mode. Specify which plugins are permitted by name or full path. Want to allow cloudco-login but nothing else? Add it to the allowlist. Want to be even stricter? Use the full path instead of just the basename. This prevents the system from accidentally running a similarly-named binary from a different directory.

Why This Matters for DevOps and Security Teams

Credential plugins are essential for modern authentication. They let you use external identity providers—cloud IAM systems, OIDC, corporate directories—without hardcoding secrets into kubeconfig files. But that power comes with risk. An attacker with access to the generation pipeline could inject malicious plugins, and you'd never see them coming.

This feature closes that gap. You're no longer trusting the entire supply chain blindly. Instead, you explicitly whitelist what's allowed to run. It's defense in depth. Even if someone compromises the kubeconfig generation process, they can't execute code on your developer machines or CI/CD runners without it being in your allowlist.

The implementation is clean. No feature gates required. No code changes needed. Just update your kuberc file and kubectl enforces the policy. For teams using the client-go library directly, there's also an ExecProvider.PluginPolicy struct you can configure programmatically.

Looking Ahead

The feature is still in beta, and the Kubernetes team is actively gathering feedback. Future enhancements could include SHA256 checksum verification (only run binaries with specific hashes) or cryptographic signature validation (only allow binaries signed by trusted keys). These additions would tighten security even further.

If you're managing Kubernetes clusters at scale, this is worth implementing now. Start with DenyAll in your kuberc, see what breaks, then carefully add allowlist entries for the plugins you actually need. Your security posture will improve immediately.