Kubernetes v1.33: From Secrets to Service Accounts: Kubernetes Image Pulls Evolved

By Anish Ramasekar (Microsoft) |

Kubernetes has steadily evolved to reduce reliance on long-lived credentials stored in the API. A prime example of this shift is the transition of Kubernetes Service Account (KSA) tokens from long-lived, static tokens to ephemeral, automatically rotated tokens with OpenID Connect (OIDC)-compliant semantics. This advancement enables workloads to securely authenticate with external services without needing persistent secrets.

However, one major gap remains: image pull authentication. Today, Kubernetes clusters rely on image pull secrets stored in the API, which are long-lived and difficult to rotate, or on node-level kubelet credential providers, which allow any pod running on a node to access the same credentials. This presents security and operational challenges.

To address this, Kubernetes is introducing Service Account Token Integration for Kubelet Credential Providers, now available in alpha. This enhancement allows credential providers to use pod-specific service account tokens to obtain registry credentials, which kubelet can then use for image pulls — eliminating the need for long-lived image pull secrets.

The problem with image pull secrets

Currently, Kubernetes administrators have two primary options for handling private container image pulls:

  1. Image pull secrets stored in the Kubernetes API

    • These secrets are often long-lived because they are hard to rotate.
    • They must be explicitly attached to a service account or pod.
    • Compromise of a pull secret can lead to unauthorized image access.

  2. Kubelet credential providers

    • These providers fetch credentials dynamically at the node level.
    • Any pod running on the node can access the same credentials.
    • There’s no per-workload isolation, increasing security risks.

Neither approach aligns with the principles of least privilege or ephemeral authentication, leaving Kubernetes with a security gap.

The solution: Service Account token integration for Kubelet credential providers

This new enhancement enables kubelet credential providers to use workload identity when fetching image registry credentials. Instead of relying on long-lived secrets, credential providers can use service account tokens to request short-lived credentials tied to a specific pod’s identity.

This approach provides:

  • Workload-specific authentication: Image pull credentials are scoped to a particular workload.
  • Ephemeral credentials: Tokens are automatically rotated, eliminating the risks of long-lived secrets.
  • Seamless integration: Works with existing Kubernetes authentication mechanisms, aligning with cloud-native security best practices.

How it works

1. Service Account tokens for credential providers

Kubelet generates short-lived, automatically rotated tokens for service accounts if the credential provider it communicates with has opted into receiving a service account token for image pulls. These tokens conform to OIDC ID token semantics and are provided to the credential provider as part of the CredentialProviderRequest. The credential provider can then use this token to authenticate with an external service.

2. Image registry authentication flow

  • When a pod starts, the kubelet requests credentials from a credential provider.
  • If the credential provider has opted in, the kubelet generates a service account token for the pod.
  • The service account token is included in the CredentialProviderRequest, allowing the credential provider to authenticate and exchange it for temporary image pull credentials from a registry (e.g. AWS ECR, GCP Artifact Registry, Azure ACR).
  • The kubelet then uses these credentials to pull images on behalf of the pod.

Benefits of this approach

  • Security: Eliminates long-lived image pull secrets, reducing attack surfaces.
  • Granular Access Control: Credentials are tied to individual workloads rather than entire nodes or clusters.
  • Operational Simplicity: No need for administrators to manage and rotate image pull secrets manually.
  • Improved Compliance: Helps organizations meet security policies that prohibit persistent credentials in the cluster.

What's next?

For Kubernetes v1.34, we expect to ship this feature in beta while continuing to gather feedback from users.

In the coming releases, we will focus on:

  • Implementing caching mechanisms to improve performance for token generation.
  • Giving more flexibility to credential providers to decide how the registry credentials returned to the kubelet are cached.
  • Making the feature work with Ensure Secret Pulled Images to ensure pods that use an image are authorized to access that image when service account tokens are used for authentication.

You can learn more about this feature on the service account token for image pulls page in the Kubernetes documentation.

You can also follow along on the KEP-4412 to track progress across the coming Kubernetes releases.

Try it out

To try out this feature:

  1. Ensure you are running Kubernetes v1.33 or later.
  2. Enable the ServiceAccountTokenForKubeletCredentialProviders feature gate on the kubelet.
  3. Ensure credential provider support: Modify or update your credential provider to use service account tokens for authentication.
  4. Update the credential provider configuration to opt into receiving service account tokens for the credential provider by configuring the tokenAttributes field.
  5. Deploy a pod that uses the credential provider to pull images from a private registry.

We would love to hear your feedback on this feature. Please reach out to us on the #sig-auth-authenticators-dev channel on Kubernetes Slack (for an invitation, visit http://slack.k8s.io/).

How to get involved

If you are interested in getting involved in the development of this feature, sharing feedback, or participating in any other ongoing SIG Auth projects, please reach out on the #sig-auth channel on Kubernetes Slack.

You are also welcome to join the bi-weekly SIG Auth meetings, held every other Wednesday.