By submitting this form, you agree to our 

Using Kubernetes credential providers with Cloudsmith

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.

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 

, 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

 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 

, 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 

cloudsmith-kubernetes-credential-provider

 binary. This is configured using the yaml below:

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.

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.

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.

This approach offers significant advantages over traditional image pull secrets:

: Ephemeral tokens reduce attack surface and credential exposure risk

: Each pod authenticates using its own service account identity

: Eliminates manual credential rotation and secret management overhead

: Namespace and service account-level restrictions provide fine-grained security

: Token refresh and caching are handled transparently by the system

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.

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.

Ian Duffy

Site Reliability Engineer

Ian Taylor

Tech Content Director

Goodbye imagePullSecrets, Hello Kubernetes Credential Providers

Pulling Docker images from private registries for containerised applications presents a security challenge. It requires authentication management, network access, and trust across distributed systems. Credentials must be securely handled and rotated, and image pulls can break due to network restrictions or expired tokens. All of this makes deployment and security harder.

To address this, you can use OpenID Connect (OIDC) when pulling Docker images from Cloudsmith into Kubernetes. OIDC adds a layer to OAuth 2.0 that identifies who is making the request. Cloudsmith can then verify that the requests come from a trusted source and can grant short-lived access tokens. So you no longer have to rely on long-lived credentials, enhancing security and simplifying credential management.

Kubernetes clusters often need to pull Docker images from private registries like Cloudsmith. Traditionally, this meant storing long-lived credentials in the cluster, which has some security risks:

Credentials could be compromised if the cluster is breached.

Regular rotation of credentials becomes a manual, error-prone process.

It's hard to apply the principle of least privilege effectively.

Before we dive into the solution, let's review what an Image Pull Secret is in Kubernetes.

An Image Pull Secret is a way to pass credentials to the kubelet to authenticate with a private container registry. Typically, the secret contains:

While Image Pull Secrets solves the immediate authentication problem, using them with long-lived credentials still exposes us to the security risks mentioned earlier. The credentials don’t automatically expire, leaving them vulnerable to misuse if leaked or unrotated.

OpenID Connect (OIDC) allows us to use short-lived tokens instead of long-lived credentials, reducing risk exposure. Here's how it works in the context of Kubernetes and Cloudsmith:

Kubernetes has its own identity in the form of a service account. The service account has an associated JWT (JSON Web Token). During runtime, the following steps are taken:

Kubernetes issues the signed OIDC token (a JWT).

Cloudsmith receives and verifies the JWT and exchanges it for a short-lived Cloudsmith token.

Kubernetes uses the short-lived Cloudsmith token to create or update an Image Pull Secret.

At runtime, the pod requests to pull an image.

Kubernetes pulls an image from Cloudsmith using the Image Pull Secret for authentication.

To automate the process, we use a Kubernetes CronJob. This job runs at regular intervals and performs the following tasks:

Retrieves the Kubernetes service account token.

Exchange service account token for a Cloudsmith token via OIDC.

Create or update an Image Pull Secret with the new Cloudsmith token.

Here's an example of what this CronJob might look like:

2. Gets the Kubernetes service account token.

4. Creates or updates an Image Pull Secret named cloudsmith-pull-secret.

Implementing this OIDC-based solution offers significant benefits:

: The CronJob ensures the token is regularly refreshed, maintaining a good security posture without manual intervention.

: There's no need to manually update credentials, reducing operational overhead.

: The token only has the permissions it needs for a limited time, aligning with security best practices.

Once the Image Pull Secret is created or updated by the CronJob, you can use it in your pod specifications like this:

This pod will use the cloudsmith-pull-secret to authenticate with Cloudsmith and pull the specified image.

Using OIDC to pull Docker images from Cloudsmith into Kubernetes eliminates the need for long-lived credentials. It reduces the risk of leaked credentials, removes the need for manual credential rotation, and aligns with current security best practices.

Authentication in Kubernetes is evolving with significant recent enhancements. Kubernetes v1.20 saw the introduction of 

. These allow the kubelet to dynamically request credentials for a container registry instead of storing static credentials on disk. This was enhanced in v1.33 to support automatic use of the service account token for image pulls. This enables short-lived authentication without needing to manage Image Pull Secrets and reduces complexity. Cloudsmith remains vigilant, and these updates help with our goal of increasing automation in supply chain security.

Cloudsmith Blog

Goodbye imagePullSecrets, Hello Kubernetes Credential Providers

Secure Docker Image Pulls from Cloudsmith to Kubernetes using OIDC