How to Prevent Hard-Coded Secrets

Instead of writing a secret directly into the source code, you should define an alternative mechanism for obtaining the secret at the places where it is used, such as using environment variables or local files not under version control, or relaying to an external secret vault (aka secret manager). These are the most common options:

chevron-rightEnvironment Variables or Configuration fileshashtag

chevron-rightUsing SCM Secretshashtag
chevron-rightUsing Cloud Secret Management Serviceshashtag
chevron-rightUsing a Third-Party Secret Vaulthashtag

Environment Variables or Configuration files

Taking secrets from environment variables or configuration files works for any programming language and operating system.

Environment variables are not hard-coded, but they should be given the value somewhere. Application code and scripts may read the environment variable, but environment variables must be set before the application or script runs.

With local files, you may need to enforce that the exclude patterns in .gitignore or .dockerignore configurations are properly excluding the secret-holding files

circle-info

With environment variables, it is more difficult to accidentally leak secrets, but be aware that the software may write environment variables for debugging to standard output/error, potentially disclosing the value in publicly available logs.

A popular way to setup environment variables is to load them from an .env file, but remember: that file should never be under version control.

circle-info

A template.env file containing only the variable names with empty/blank values, and comments explaining which is the secret and how it is used, is a good technique for documenting the secrets needed and for inventory of the secrets used.

If that innocuous template.env file is under version control and .env in .gitignore, users can copy template.env to .env, and then edit the git-ignored .env with the real secrets.

The following are examples for how to get a secret from .env file for each ecosystem. Replace the name of the environment variable SECRET_VAR and <path> to the .env file accordingly.

circle-info

Code examples below are illustrative and simplified, with no error handling and configuration.

See dotenvarrow-up-right for full details.

Using SCM Secrets

Collaboration platforms (aka Source Code Management Systems, SCM) and CI/CD tools often provide Secret Management, so CI/CD pipelines may get the secret securely.

GitHub

Secrets in GitHub are variables set in an organization, repository, or repository environment, available to use in GitHub Actions workflows.

For secrets stored at the organization-level, access policies control which repositories can use organization secrets. Organization-level secrets let secrets be shared between multiple repositories, which reduces the need for creating duplicate secrets. Updating an organization secret in one location also ensures that the change takes effect in all repository workflows that use that secret.

For secrets stored at the environment level, you can enable required reviewers to control access to the secrets. A workflow job cannot access environment secrets until approval is granted by required approvers.

Once a secret is registered, it can be referenced in a CI/CD workflow using a {{ secret.SECRET }} expression. But if possible, do not pass the secret value to the command to be executed. The command should read the environment variable instead. In the following example, a secret named API_KEY is passed to the workflow step in the environment variable API_KEY, but its value is then hard-coded in the command line, so it will be visible in the process table:

circle-info

Although GitHub Actions automatically redacts ("obfuscates") the contents of all GitHub secrets that are printed to workflow logs, this is not fail-proof. Only a limited set of secretsarrow-up-right are recognized.

Read creating secrets for a repositoryarrow-up-right, for organizationarrow-up-right, or for environmentarrow-up-right for details on how to register a secret for GitHub Actions at a given scope.

GitLab

GitLab provides CI/CD Variablesarrow-up-right as a convenient wau to store and reuse data in a CI/CD pipeline, but they can be exposed by accidental pipeline misconfiguration.

GitLab provides support for external secret management providers:

After configuring a vault serverarrow-up-right, you may use vault secrets in a GitLab CI job:

This stores the value of the secret fetched from the vault into the SECRET variable.

Read Using external secrets in CIarrow-up-right for full details.

Using Cloud Secret Management Services

AWS Secrets Manager

AWS Secrets Managerarrow-up-right is the secret vault service in Amazon Web Services platform. The following are examples of how to use the official libraries for getting a secret using different programming languages:

Azure Key Vault

The Azure Key Vaultarrow-up-right is the secrets management service in Azure. The following shows how to retrieve a secret using the official libraries for some popular languages.

The following shows how to use the @azure/keyvault-secretsarrow-up-right package.

Google Cloud Secret Manager

Secret Managerarrow-up-right is Google Cloud’s storage system for API keys, passwords, certificates, and other sensitive data.

In the following, <project_id> represents your Google Cloud Project ID, and SECRET is the name of the secret to fetch. It is assumed that the latest version of the secret is fetched. Examples can be found in the Quickstartarrow-up-right page.

The @google-cloud/secret-managerarrow-up-right is the official JavaScript library for Secret Manager. The following example shows how to fetch a secret.

Using a Third-Party Secret Vault

HashiCorp Vault

HashiCorp Vaultarrow-up-right is a centralized secrets management system that provides secure storage of sensitive information, such as password, API keys, access tokens or cryptographic keys, encrypted in transit and at rest. It permits dynamic generation for temporary, on-demand credentials, and advanced features like automated key rotation and leasing/renewal of secrets, plus some built-in support for secret revocation.

In what follows, we assume a mount point of "secret" and a vault path of "SECRET", and the secret is stored under key "value".

See node-vaultarrow-up-right, unofficial NPM package for Vault.

CyberArk Conjur

CyberArk Conjurarrow-up-right is an open-source security tool for managing secrets and credentials in modern IT environments.

The following show how to fetch a secret from CyberArk Conjur for popular programming languages. The environment variables CONJUR_APPLIANCE_URL, CONJUR_ACCOUNT, CONJUR_USERNAME and CONJUR_APIKEY contain the configuration needed to authenticate for fetching the secret.

Go to Client Librariesarrow-up-right or https://docs.cyberark.com/conjur-open-source/Latest/en/Content/Developer/lp_REST_API.htm?tocpath=Developer%7CREST%C2%A0APIsarrow-up-right for further detail.

The following code uses the official conjur-api-javaarrow-up-right library.

Last updated