Are your CI/CD pipelines at risk?  They might be if you use long-lived, static credentials and tokens. Long-lived, static credentials and tokens are one of the most common causes of data breaches in cloud environments. 

CI/CD tools need access to cloud services to publish artifacts, deploy software, and access resources on their cloud provider.  So, they need credentials.  It's tempting to hard-code them.

But that's a bad idea.  A recent breach in CircleCI left lots of organizations scrambling to rotate and disable API keys they were using to run their builds. 

What's the solution?  OpenID Connect!  OIDC tokens are a more secure way to handle authentication than long-lived credentials, and they remove the need to store your credentials in your CI/CD platform.

Cloudsmith now supports OIDC natively.  You can use OIDC tokens to authenticate against our API, CLI and our users can even authenticate using OIDC with format-specific endpoints like Ruby, NuGet, Terraform, or Docker.

Let's talk about: 

• A classic but flawed workflow using long-lived tokens.
• OIDC in CI/CD and its benefits.
• Workflow with Cloudsmith, GitHub Actions using OICD.

Flawed Workflow using Long-lived Tokens

CI/CD platforms like CircleCI and Github actions usually require access to resources on external services, like your artifacts hosted on Cloudsmith’s artifact repository. 

Hard-coded credentials stored on your CI/CD tool are often used to authenticate into these external services to allow for a fully automated build. Unfortunately, these hard-coded credentials could allow an attacker to authenticate into your system. 

A classic but flawed workflow with GitHub Actions and Cloudsmith could flow like the following: 

• In Cloudsmith you create a user or service account
• In Cloudsmith you get your API token for your user or service account.
• Add a secret to your GitHub repository named CLOUDSMITH_API_KEY, with the value of your API key.
• In GitHub Actions write some code to build a package and use the Cloudsmith Github Action to publish the package to Cloudsmith. 
• Trigger a build in GitHub Actions.
• As part of the build, Github Actions publishes to Cloudsmith using the long-lived token in Github secrets to authenticate into Cloudsmith.

The issue with the workflow above is that if this API token is stolen or leaked there is a risk of unauthorized access. 

The workflow above can be made more secure by rotating your keys but this is an extra overhead on development, because you have to do it manually, and it might not actually get done. For this reason, Cloudsmith has introduced authentication policies to enforce API-Key rotation without having to manually rotate their keys.

Until recently, storing hard-coded credentials in your CI/CD for external cloud services was necessary if you wanted a fully automated build but there is a better way.

OpenID Connect (OIDC) in CI/CD

OpenID Connect (OIDC) is a better approach to authentication between CI/CD tools than using hard-coded credentials or long-lived API tokens.

OICD extends the OAuth 2.0 protocol for secure single sign-on (SSO) to authenticate API access control. OIDC uses JSON Web Tokens (JWTs) to allow third-party applications to verify identities and obtain basic user profile information.

Using OIDC tokens your CI/CD platform can securely authenticate into Cloudsmith without long-lived credentials being stored in your CI/CD.

Benefits of using OIDC

By updating your workflows to use OIDC tokens, you can adopt the following good security practices:

• No need to store your long-lived secrets in your CI/CD.
• You have more granular control over how workflows can use credentials.
• No need to rotate your API tokens. With OIDC, your provider issues a short-lived access token that automatically expires.

Why use OIDC over SAML

Security Assertion Markup Language (SAML) is another authentication protocol for SSO that enables secure authentication between different services.  

SAML, unlike OIDC, works only on XML and is more difficult to use in use cases involving services authenticating over APIs.

OIDC is not intrinsically more secure than SAML but is easier to implement especially when working with APIs.

Workflow with Cloudsmith, GitHub Actions using OICD

Our updated workflow using Github Actions and Cloudsmith with OIDC looks like the following:

• In Cloudsmith, create a service account. 
• In Cloudsmith, set up a GitHub OIDC as a provider for your Organization. Cloudsmith recommends adding claims here to restrict the context of any requests from the provider.
• Update your Github Actions from above to use OIDC. 
  • Add a new job to generate an OIDC JWT token in GitHub Actions. The JWT token generated by the OIDC endpoint can be used as an API key.
  • Save the JWT token to an environment variable called CLOUDSMITH_API_KEY and do not include the API key in the .yaml push action, the API key will be taken from the environment variable instead.
• Trigger a build in GitHub Actions and OIDC will be used to authenticate into Cloudsmith.

This token works with all Cloudsmith API endpoints to manage resources, Command-Line Interface as well as format-specific endpoints, e.g. the Ruby endpoint to get all available Ruby packages.

Go forth and OIDC

Cloudsmith’s support for OIDC authentication brings a new level of security and convenience to software engineering workflows.  

Hard-coded credentials leave you vulnerable in an attack, and manual key rotation can get missed.  Give OIDC a try in your Cloudsmith org by consulting our OIDC documentation.  

If you don’t have a Cloudsmith org, or you want your own development sandbox separate from your company’s production org, create your own Cloudsmith account (it’s free!).  And our Customer Support is right here to help if you get stuck!

Liked this article? Don\'t be selfish (:-), share with others:   Tweet