Add blog post for PSAT for Kubelet Image Credential Providers

Signed-off-by: Anish Ramasekar <[email protected]>

Author: aramase

content/en/blog/_posts/2025-04-15-wi-for-image-pulls.md

@@ -0,0 +1,162 @@
+---
+layout: blog
+title: "From Secrets to Service Accounts: Kubernetes Image Pulls Evolved"
+date: 2025-04-15
+slug: wi-for-image-pulls
+author: >
+  [Anish Ramasekar](https://github.com/aramase) (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](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2535-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](/docs/tasks/administer-cluster/kubelet-credential-provider/#service-account-token-for-image-pulls)
+page in the Kubernetes documentation.
+
+You can also follow along on the
+[KEP-4412](https://kep.k8s.io/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](https://kubernetes.slack.com/archives/C04UMAUC4UA)
+channel on Kubernetes Slack
+(for an invitation, visit [https://slack.k8s.io/](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](https://kubernetes.slack.com/archives/C0EN96KUY)
+channel on Kubernetes Slack.
+
+You are also welcome to join the bi-weekly
+[SIG Auth meetings](https://github.com/kubernetes/community/blob/master/sig-auth/README.md#meetings),
+held every other Wednesday.