By submitting this form, you agree to our 

If you're running workloads in AWS, you're already managing IAM credentials. Wouldn't it be great if those same credentials could authenticate your services with Cloudsmith without creating, storing, or rotating yet another API key?

. Your AWS workloads can now exchange their IAM identity for short-lived Cloudsmith tokens on the fly. No long-lived secrets sitting in environment variables. No API keys to rotate. Just cryptographically signed, time-limited credentials.

, which can now issue signed JSON Web Tokens (JWTs) that external services like Cloudsmith can verify and trust. Here's the flow:

Your AWS workload calls STS and asks for an OIDC token, specifying Cloudsmith as the intended audience

STS returns a cryptographically signed JWT containing your AWS identity information

You pass this token to Cloudsmith's OIDC endpoint

Cloudsmith fetches AWS's public verification keys and validates the token's signature

If everything checks out, Cloudsmith hands back a short-lived JWT you can use for API calls

You're authenticated, no API key required

There are three pieces to configure: AWS permissions, AWS external identity federation, and Cloudsmith OIDC settings. Let's walk through each.

Your AWS role or user needs permission to call the 

 API. Add this policy to any IAM principal that needs to authenticate with Cloudsmith:

Enable Outbound Identity Federation in AWS

Before your account can issue these external identity tokens, you need to flip the switch. Head to the 

, and enable outbound identity federation.

Once enabled, AWS generates a unique issuer URL for your account. This URL hosts the OIDC discovery endpoints that external services use to verify your tokens. It looks something like 

. Keep this URL handy since you'll need it for the Cloudsmith configuration.

 which allowed Cloudsmith to fetch the required metadata to verify received tokens.

Now tell Cloudsmith to trust tokens from your AWS account. Navigate to your Cloudsmith organization settings at 

Settings > Authentication > OpenID Connect

With everything configured, here's how to actually authenticate from your AWS workloads.

 must match what you configured in Cloudsmith's required claims. We used 

Now swap that AWS token for Cloudsmith credentials:

 with your Cloudsmith service account slug, and 

 with your Cloudsmith organization identifier.

If everything's configured correctly, you'll see something like:

aws-pipeline

This pattern works anywhere you have an AWS IAM identity. The short-lived nature of both tokens keeps things secure, and you're leveraging identity you're already managing.

 can use their instance profile to request OIDC tokens. Add the token exchange to your startup scripts or application initialization.

 work the same way through task roles. Grab a token during container startup or lazily when you first need Cloudsmith access.

 can request tokens during cold start or on-demand within your function code. The overhead is minimal because both API calls are quick.

CodeBuild, CodePipeline, and other AWS services

 with an IAM role attached can participate. Build pipelines become much cleaner without injected API key secrets.

AWS outbound identity federation combined with Cloudsmith's OIDC support is a clean solution for a common problem. You're extending trust from identity you already manage, exchanging it for short-lived credentials exactly when you need them, and eliminating the operational overhead of API key management.

No more secrets in environment variables. No more key rotation schedules. No more "who has access to that API key?" conversations.

AWS outbound identity federation documentation

Ian Duffy

Site Reliability Engineer

Authenticate to Cloudsmith with your AWS identity

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 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

Authenticate to Cloudsmith with your AWS identity

Goodbye imagePullSecrets, Hello Kubernetes Credential Providers

Secure Docker Image Pulls from Cloudsmith to Kubernetes using OIDC