By submitting this form, you agree to our 

Answer twenty questions about your artifact and supply chain practices. Get a custom report card showing your maturity score against key regulatory and compliance frameworks.

Artifact Security Maturity Assessment

Using long-lived credentials in CI/CD and embedding static API keys in pipeline secrets are security risks. The CI platform authenticates a build job’s identity and context, and using short-lived tokens that expire on their own reduces exposure from a credential leak.

Previous discussions of OIDC covered using it to 

, and to authenticate workloads using your 

For any developer, the common denominator with using these tools is your individual workstation, which likely contains long-lived credentials.

At least one of these files on your local workstation likely contains long-lived API keys:

Each tool has its own login command and config file, which contains a copy of the API key in plain text. It’s the owner’s job to manually rotate these keys.

 npm worm targeted files that contained tokens on developer machines, like 

, and used them to access maintainer accounts and workflows.

You can sign into the Cloudsmith CLI with SAML via your company's identity provider. This creates a short-lived token that expires and rotates frequently. Credential helpers enable package managers like Docker and pnpm to borrow this authentication context from the Cloudsmith CLI, avoiding long-lived API keys being stored on disk.

The result is a short-lived access token, issued from your SAML sign-in. The CLI stores the token in your system keyring, and it expires on its own. The CLI renews it with a refresh token, so you are not sent back to the browser each time it expires. If you run 

 again while your session can still be renewed, the CLI simply renews it.

You now have a short-lived, SAML-backed session. The next step is to share that session with your package managers.

Step 2: Set up Cloudsmith credential helpers

Most package managers already know how to ask an external program for a credential. Docker has 

. Each one is a small, standard hook for a single question: 

"Who can give me a credential for this host?"

The Cloudsmith CLI now answers that question for all of them.

A credential helper does not log you in. It hands your active session to your package manager(s).

When a package manager needs a credential, it calls the helper. The helper asks the CLI for the current access token, and the CLI renews that token if it is close to expiry. Nothing is written into the package manager’s config file.

, not the project file, so the helper config never ends up in source control. If you already have an 

 for the same registry, the installer leaves it alone.

The provider answers only for Cloudsmith registries, doesn’t require 

. For crates.io and anything else, the credential helper steps aside and lets Cargo try the next provider.

Terraform does not tell a credential helper which repository it wants, so the installer writes your Workspace and repository into 

 for you. Terraform allows only one credential helper. If you already have one, the installer tells you and does not overwrite it.

 gives pip and uv a keyring backend that gets its credential from the Cloudsmith CLI:

 in that URL is not a secret. It is the literal username that Cloudsmith expects for token authentication. Your 

 names the repository, but it contains no credential at all.

 prints the current credential as JSON, ready for a wrapper script:

We are working on helpers for more package managers. The goal is to make the API key 

Open an issue on the Cloudsmith CLI GitHub repository

 and let us know which tool you use. Your requests help us decide which helper to build next.

Then use your tools exactly as you do today. One SSO sign-in. One short-lived session. Zero keys in your dotfiles.

OIDC took long-lived credentials out of your pipelines. Credential helpers take them off your laptop. Together, they move every part of your workflow toward short-lived, identity-based access.

Ian Duffy

Site Reliability Engineer

OIDC removed long-lived credentials from your pipelines. What about your laptop?

Long-lived API keys are a liability. They sit in secret managers, leak into logs, and eventually someone has to remember to rotate them. If you run workloads on Google Cloud, you can skip that whole problem: every VM, container, and function already carries a service account identity, and you can use it to authenticate to Cloudsmith directly.

 work together to handle authentication. Your workload swaps its service account identity for a short-lived Cloudsmith token at runtime. Nothing long-lived gets written to an environment variable or a key file on disk.

Google's metadata server can issue signed JSON Web Tokens (JWTs), and Cloudsmith verifies them against Google's public keys. The flow:

Your workload asks the Google metadata server for an ID token, naming Cloudsmith as the intended audience

Google returns a signed JWT carrying your service account's identity (its email and your chosen aud)

You pass this token to Cloudsmith's OIDC endpoint

Cloudsmith fetches Google's public verification keys and validates the signature

If the claims you pinned all match, Cloudsmith hands back a short-lived token for API calls

Setting this up has two parts. Your workload needs a way to get a Google token, and Cloudsmith needs to know when to trust that Google token.

On a server you want the token to carry a meaningful audience and a dedicated identity. Service account identity tokens give you both: a custom aud and an explicit email.

The simplest source is the metadata server, available on GCE, Cloud Run, GKE, App Engine, and Cloud Build:

 claims you'll pin against in Cloudsmith.

You can also impersonate the service account from another identity, such as your own user. However, the calling identity needs 

 and the payload looks roughly like this:

Before wiring up a workload, you can prove the whole flow with your own Google login:

 doesn’t give you any isolation because it is hard-wired to the gcloud SDK's shared OAuth client ID, which is the same value every gcloud user carries. For a local proof of concept, pin the 

 (hosted domain) claim, e.g., your Google Workspace domain, which ties the token back to your organization.

Now tell Cloudsmith to trust tokens from your service account. You'll need the Manager or Owner role, at least one Cloudsmith service account, and the robot identity that holds your repository entitlements must already exist. Go to Settings > Authentication > OpenID Connect and create a provider:

 is a planet-wide issuer used by every Google account, so the issuer alone proves nothing. The isolation comes from the 

 claim. Only something that can act as that exact service account can mint a token carrying its address, and that is gated by IAM. The 

 value just binds the token to Cloudsmith so it can't be replayed elsewhere.

Swap the Google 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:

gcp-pipeline

The returned token is a normal Cloudsmith API key, valid for 2 hours. Pass it on any Cloudsmith API request, as the verify call above shows.

This works anywhere you have a Google Cloud service account identity. Both tokens are short-lived, so there's nothing long-lived to store, and you're reusing an identity you already manage.

Compute Engine instances use their attached service account to request a token from the metadata server, then exchange it for Cloudsmith access whenever they need it.

Cloud Run and GKE work the same way through their workload identities, fetching a fresh token for each job or when the current one nears expiry.

Cloud Functions and App Engine can request a token on demand within the handler.

Cloud Build pipelines with a service account attached can do the token exchange to gain Cloudsmith access.

You're reusing an identity you already manage, and the token it gets back expires in two hours. Nothing long-lived sits in an environment variable, and there's no rotation schedule for anyone to own.

 and point an existing Google Cloud workload at it. For the details, see 

Authenticate to Cloudsmith with your Google Cloud identity

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

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:

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

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

OIDC removed long-lived credentials from your pipelines. What about your laptop?

Authenticate to Cloudsmith with your Google Cloud identity

Authenticate to Cloudsmith with your AWS identity

Goodbye imagePullSecrets, Hello Kubernetes Credential Providers

Secure Docker Image Pulls from Cloudsmith to Kubernetes using OIDC