Kubernetes v1.33: Image Pull Auth with Service Account Tokens

Kubernetes continues its march toward ephemeral, identity-based security. In v1.33 the platform closes a key gap in workload authentication by integrating Service Account Tokens into the kubelet credential provider framework. This change eliminates static imagePullSecrets and brings per-pod, OIDC-compliant authentication to container registry access.

Background: From Static Secrets to Workload Identity

Historically, Kubernetes workloads that pulled images from private registries relied on long-lived imagePullSecrets stored in the API server. These credentials were:

• Static JSON or .dockerconfigjson blobs with no built-in rotation.
• Scoped either to a service account or explicitly mounted in each pod spec.
• Exposed to cluster compromise if mismanaged or leaked.

With the advent of OIDC-compliant ServiceAccountTokenProjection in v1.21 and the TokenRequest API, Kubernetes began issuing short-lived JWT tokens for in-cluster authentication. Now, v1.33 extends that work to image pulls, aligning registry access with modern identity and access management best practices.

The Problem with Image Pull Secrets

1. API-backed imagePullSecrets

   • Long TTL by default (often months or years).
   • Manual rotation is complex and error-prone.
   • Compromise grants cluster-wide registry access.

2. Node-level kubelet credential providers

   • Fetch credentials via exec plugins (e.g., AWS ECR, GCR, ACR).
   • All pods on the node share the same token or IAM role.
   • No per-pod isolation; violates least-privilege principles.

Neither model meets the CNCF’s Zero Trust mantra of least privilege and token ephemerality. This leaves clusters vulnerable to lateral movement in the event of a breach.

Solution: Service Account Token Integration for Kubelet Credential Providers

Alpha in v1.33, the ServiceAccountTokenForKubeletCredentialProviders feature gate enables kubelet to inject a pod-specific JWT into the CredentialProviderRequest. Credential providers—configured via the kubelet credentialProviders block—can opt in to receive these tokens and exchange them for short-lived, registry-scoped credentials.

• Pod-specific identity: Each JWT is minted for a particular pod’s service account, with audience claims tailored to the registry plugin.
• Automatic rotation: Tokens default to a 15-minute TTL with a 5-minute renewal buffer, configurable via the KEP.
• OIDC semantics: Conforms to JWT C RFC 7519 and leverages Kubernetes TokenRequest API under the hood.

How It Works

1. Token Projection and Request

When credentialProviders is enabled, kubelet issues a TokenRequest for the pod’s service account, specifying:

• audience: The unique identifier of the credential plugin (e.g., sts.amazonaws.com for AWS ECR).
• expirationSeconds: Desired token TTL (default 900s).

The resulting JWT is included in the CredentialProviderRequest payload, which is delivered to the exec plugin over stdin.

2. Plugin Exchange and Registry Pull

• The exec plugin validates the JWT (verifying iss, aud, exp claims) and exchanges it at the registry’s STS endpoint.
• Registry (e.g., AWS STS, GCP IAM Credentials API, Azure Managed Identities) issues ephemeral credentials scoped to the pod’s permissions.
• Kubelet uses these short-lived credentials to pull images, caching them per‐pod until expiry.

Key Benefits

• Security: Eliminates static secrets; reduces blast radius in compromise scenarios.
• Granular Access Control: Enforces per-pod IAM/ RBAC policies at registry level.
• Operational Simplicity: No manual secret rotation—kubelet handles token renewal transparently.
• Compliance: Meets organizational mandates against persistent in-cluster credentials.

Performance and Scalability Considerations

Early benchmarks from SIG-Node show sub-10ms overhead per TokenRequest for clusters up to 5000 nodes. Caching layers within exec plugins can further amortize network latency. Upcoming v1.34 plans include a centralized token cache on the node, reducing redundant requests when multiple pods share the same service account and registry plugin configuration.

Integration with Cloud Provider IAM

Major cloud distributions are already testing this alpha feature:

• Amazon EKS: AWS has published a preview of its ECR credential provider (v0.6.0+) with explicit support for ServiceAccountTokenForKubeletCredentialProviders.
• Google GKE: GCP Artifact Registry plugin is in private alpha, leveraging the Workload Identity federation to mint STS tokens.
• Azure AKS: Upcoming ACR support via Managed Identities is tracked under KEP-4053.

Roadmap and Next Steps

The feature is slated for beta in Kubernetes v1.34, with the community focusing on:

• Implementing configurable token cache TTLs in kubelet to balance freshness and performance.
• Enhancing Ensure Secret Pulled Images (KEP-2535) compatibility to validate pod image access post-pull.
• Extending exec plugin SDKs with helper libraries to parse and validate projected tokens.

Try It Out

1. Install Kubernetes v1.33+ and enable ServiceAccountTokenForKubeletCredentialProviders on kubelet.
2. Deploy or update a credential provider plugin (e.g., ecr-credential-provider v0.6.0+).
3. Configure credentialProviders in the kubelet config YAML, including tokenAttributes for your registry.
4. Create a test namespace with a service account bound to minimum IAM roles.
5. Deploy a pod using that service account and verify image pulls in the kubelet logs.

How to Get Involved

We welcome contributions and feedback from the community. Join the SIG-Auth and SIG-Node channels:

• #sig-auth-authenticators-dev: Discuss the TokenRequest API and KEP-4412.
• #sig-node: Share performance metrics, plugin implementations, and operator experiences.

Participate in our bi-weekly SIG meetings or file issues and pull requests on the Kubernetes GitHub repositories.

Source: Kubernetes Blog