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:
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
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.
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.
Code examples below are illustrative and simplified, with no error handling and configuration.
var dotenv =require('dotenv');dotenv.config({ path:'<path>/.env' });constsecret=process.env.SECRET_VAR;// alternative: load map instead of setting env varsconstsecrets= {}dotenv.config({ path:'<path>/.env', processEnv: secrets });constsecret=secrets.SECRET_VAR;
// See io.github.cdimascio:dotenv-java in Maven CentralDotenv dotenv =Dotenv.configure().directory("<path>").filename("env").load();String secret =dotenv.get("SECRET_VAR");//
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:
steps: - name:Hello world actionshell:bashenv:# pass the secret as environment variableAPI_KEY:${{ secrets.API_KEY }}run:| # Not recommended! ps will show the clear-text secret my-command --key="$API_KEY" ... # my-command must read environment variable API_KEY
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 secrets are recognized.
GitLab provides CI/CD Variables 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:
job_using_vault:id_tokens:VAULT_ID_TOKEN:aud:https://vault.example.com# use your ownsecrets:SECRET:# translates to secret `ops/data/production/db`, field `password`vault:production/db/password@opsfile:falsetoken:$VAULT_ID_TOKEN
This stores the value of the secret fetched from the vault into the SECRET variable.
AWS Secrets Manager 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:
The Azure Key Vault is the secrets management service in Azure. The following shows how to retrieve a secret using the official libraries for some popular languages.
Secret Manager 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 Quickstart page.
The @google-cloud/secret-manager is the official JavaScript library for Secret Manager. The following example shows how to fetch a secret.
HashiCorp Vault 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".
The following example uses the Vault API official Go library.
import ("os" vault "github.com/hashicorp/vault/api")config := vault.DefaultConfig()config.Address = os.Getenv("VAULT_URL")client, err := vault.NewClient(config)if err !=nil {...}client.SetToken( os.Getenv("VAULT_TOKEN") )// default mount point secret. Secret data with string keyed by "value"resp, err := client.Logical().Read("secret/SECRET")if err !=nil {...}if resp ==nil {...}secret, ok := resp.Data["value"].(string)
The following example uses VaultSharp, .NET library for Vault.
usingSystem;usingVaultSharp;usingVaultSharp.V1.AuthMethods.Token;usingVaultSharp.V1.Commons;// recommendation: get url and token from environmentstring vaultUrl =Environment.GetEnvironmentVariable("VAULT_URL");string token =Environment.GetEnvironmentVariable("VAULT_TOKEN");var settings =newVaultClientSettings(vaultUrl,newTokenAuthMethodInfo(token));var client =newVaultClient(settings);Secret<SecretData> res = await client.V1.Secrets.KeyValue.V2.ReadSecretAsync(path: "SECRET", mountPoint: "secret").Result;
string secret =res.Data.Data["value"];
CyberArk Conjur
CyberArk Conjur 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.