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

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 https://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.