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 connect Cloudsmith to your CI/CD, Dependabot, and Kubernetes, to build zero trust pipelines with GitHub Actions, and to authenticate workloads using your AWS or Google Cloud identities.
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:
~/.docker/config.json~/.npmrc~/.cargo/credentials.toml~/.terraformrcpip.conf, .netrc, or an index URL in your shell profileEach 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.
The Shai-Hulud npm worm targeted files that contained tokens on developer machines, like .npmrc, 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.
Install the Cloudsmith CLI, then sign in with SAML:
cloudsmith auth -w my-workspaceThe 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 cloudsmith auth again while your session can still be renewed, the CLI simply renews it.
Confirm who you are:
cloudsmith whoamiYou now have a short-lived, SAML-backed session. The next step is to share that session with your package managers.
Most package managers already know how to ask an external program for a credential. Docker has credential helpers. pnpm has tokenHelper. Cargo has credential providers. Terraform has credentials_helper. Python has keyring. 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.
Here is how to set up each one.
cloudsmith credential-helper install docker
docker pull docker.cloudsmith.io/my-workspace/my-repo/my-image:latestThe installer registers docker-credential-cloudsmith in ~/.docker/config.json. You will never need to run docker login against Cloudsmith again.
cloudsmith credential-helper install pnpm
pnpm installThe installer adds a tokenHelper entry to your user-level ~/.npmrc, not the project file, so the helper config never ends up in source control. If you already have an _authToken for the same registry, the installer leaves it alone.
cloudsmith credential-helper install cargo
cargo fetchThe provider answers only for Cloudsmith registries, doesn’t require cargo login, and writes nothing to credentials.toml. For crates.io and anything else, the credential helper steps aside and lets Cargo try the next provider.
cloudsmith credential-helper install terraform -w my-workspace --repo my-repo
terraform initTerraform does not tell a credential helper which repository it wants, so the installer writes your Workspace and repository into ~/.terraformrc for you. Terraform allows only one credential helper. If you already have one, the installer tells you and does not overwrite it.
cloudsmith-keyring gives pip and uv a keyring backend that gets its credential from the Cloudsmith CLI:
uv tool install keyring --with cloudsmith-keyring[tool.uv]
keyring-provider = "subprocess"[[tool.uv.index]]
name = "cloudsmith"
url = "https://token@dl.cloudsmith.io/basic/my-workspace/my-repo/python/simple/"The token in that URL is not a secret. It is the literal username that Cloudsmith expects for token authentication. Your pyproject.toml names the repository, but it contains no credential at all.
For tools with no helper mechanism, the generic helper prints the current credential as JSON, ready for a wrapper script:
cloudsmith credential-helper generic | jq -r .passwordWe are working on helpers for more package managers. The goal is to make the API key the exception, not the default.
Tell us which one you want next! 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.
cloudsmith auth -w my-workspace
cloudsmith credential-helper install docker
cloudsmith credential-helper install pnpm
cloudsmith credential-helper install cargo
cloudsmith credential-helper install terraform -w my-workspace --repo my-repoThen 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.
Ready to try it? Update to the latest Cloudsmith CLI and run cloudsmith auth.
