Previously, we showed you how to securely pull Docker images from Cloudsmith to Kubernetes using OIDC with a CronJob-based approach. We concluded the post discussing credential provider plugins from Kubernetes 1.20 and an enhancement in Kubernetes 1.33 that offers a new approach for external registries like Cloudsmith.

We have now built a credential provider that takes advantage of this new capability. This article explores what this means for the future of pulling images from Cloudsmith on Kubernetes.

What Is a Credential Provider Plugin?

A credential provider plugin is essentially a script or binary that the kubelet can use to get a token for fetching images from a private repository. This saves you from having to define image pull secrets on all of your pods.

When credential providers first came out in Kubernetes 1.20, if you ran everything on AWS and stored images in ECR, you could exchange your AWS instance profile identity for an ECR token that the kubelet could use to seamlessly pull images. This was great if you ran everything on AWS, but if you used an external registry like Cloudsmith, it was harder because you couldn't exchange an AWS identity for a Cloudsmith one.

The Game Changer: Service Account Tokens in Kubernetes 1.33

Kubernetes 1.33 introduced an alpha feature that changes how you can identify when pulling images. The new feature exposes the pod's service account token to the credential provider plugin. The pod service account token is a JWT that follows the OpenID Connect standard, meaning you can create a trust relationship between Cloudsmith and Kubernetes.

This allows Kubernetes service account tokens to be exchanged for short-lived OIDC-issued Cloudsmith service tokens, enabling Kubernetes to seamlessly pull images from Cloudsmith without any image pull secrets. To do this, you need to implement a Cloudsmith credential provider plugin. We've gone ahead and done exactly that.

How the Cloudsmith Credential Provider Works

We have a Kubernetes credential provider config that gets passed to kubelet, telling it that for any image matching docker.cloudsmith.io, it should call out to our cloudsmith-kubernetes-credential-provider binary. This is configured using the yaml below:

apiVersion: kubelet.config.k8s.io/v1
kind: CredentialProviderConfig
providers:
  - name: cloudsmith-kubernetes-credential-provider
    matchImages:
      - "docker.cloudsmith.io"
    defaultCacheDuration: "1h"
    apiVersion: credentialprovider.kubelet.k8s.io/v1
    env:
      - name: CLOUDSMITH_SERVICE_SLUG
        value: default-v9ty
      - name: CLOUDSMITH_ORG_SLUG
        value: iduffy-demo
    tokenAttributes:
      serviceAccountTokenAudience: "cloudsmith"
      requireServiceAccount: true
      optionalServiceAccountAnnotationKeys:
        - "cloudsmith.io/service-slug"
        - "cloudsmith.io/org-slug"

The configuration passes environment variables to our binary so it knows which Cloudsmith organisation slug and service slug to use for the token exchange. We specify the audience as "cloudsmith" so only Cloudsmith can consume this token, and we require that the credential provider requires a service account.

Lastly, we define some optional annotations that our credential provider is aware of. These annotations will enable you to override the organisation slug and service slug on a per Kubernetes service account basis.

Setting Up the Trust Relationship

On the Cloudsmith side, we create an OpenID Connect provider that points at your Kubernetes cluster. This allows Cloudsmith to fetch the well-known OpenID configuration and the JWKs for validation.

In the claims section, you can restrict access so that only service accounts within specific namespaces can use this token exchange. If you try to bring up a pod in a namespace that isn't allowed, it won't be able to pull images from Cloudsmith.

A Credential Provider in Action

When you try to create a pod in a restricted namespace using an image from Cloudsmith, the pod will not start, and you will see 401 authentication errors. This is because the system is operating within a namespace that Cloudsmith refuses to accept tokens from.

However, when you switch to an allowed namespace and run the same command, the system successfully exchanges a Kubernetes token for a Cloudsmith token and pulls down the image. The pod starts successfully.

This demonstrates how Kubernetes can seamlessly pull images from Cloudsmith without needing any image pull secrets defined, while maintaining restrictions so that only pods in specific namespaces can pull from specific service accounts within Cloudsmith.

The Benefits of a Credential Provider

This approach offers significant advantages over traditional image pull secrets:

• Enhanced Security: Ephemeral tokens reduce attack surface and credential exposure risk
• Workload Identity: Each pod authenticates using its own service account identity
• Operational Efficiency: Eliminates manual credential rotation and secret management overhead
• Granular Access Control: Namespace and service account-level restrictions provide fine-grained security
• Automatic Lifecycle Management: Token refresh and caching are handled transparently by the system

Try It Yourself

The Cloudsmith Kubernetes credential provider plugin is available at github.com/cloudsmith-io/cloudsmith-kubernetes-credential-provider. The repository includes a complete Minikube walkthrough for local testing.

What's Next for Cloudsmith

This alpha release enables the elimination of image pull secrets entirely. As Kubernetes continues evolving its authentication capabilities, Cloudsmith remains at the forefront of implementing these advanced security features for our users.

To try out Cloudsmith, book a demo.