What Are Secrets in DevOps?
A secret is any credential — an API key, password, token, or private key — that grants access to a system and must be kept confidential.
Definition
In DevOps, a secret is any credential that grants access to a system and would cause harm if it leaked: API keys, database passwords, OAuth tokens, TLS private keys, SSH keys, signing certificates, and the connection strings that bundle several of these together. The defining trait is not the format but the consequence — a secret is a value an attacker can use directly, so it has to stay confidential from the moment it is created to the moment it is retired.
Secrets are often confused with two adjacent things. Configuration is the set of values that change how an app behaves — a feature flag, a log level, a region name. Environment variables are a transport mechanism: a way to pass values into a process at startup. A secret can travel as an environment variable, and a config value can too, but neither is a secret by virtue of how it is delivered. The line that matters is sensitivity: would you paste this into a public Slack channel? If not, it is a secret and needs to be handled like one.
Why it matters
Secrets are the single highest-leverage target in a software supply chain. A leaked database password is not one bug — it is read access to every customer record at once. This is why credential leakage shows up year after year as a leading cause of breaches, and why scanning services routinely find live keys committed to public repositories within minutes of a push.
The risk compounds in a DevOps setting because secrets multiply across surfaces. The same Stripe key might live in a developer's .envfile, a CI runner's environment, a Kubernetes manifest, a Terraform state file, and a teammate's shell history. Each copy is a place it can leak and a place you have to remember when you rotate. Treating secrets as a managed resource — versioned, access-controlled, and revocable — is what keeps that sprawl from becoming an incident.
Examples
Common secrets a DevOps team handles every day:
- Database credentials — the username and password (or DSN) for Postgres, MySQL, Redis, or a managed equivalent.
- Third-party API keys — Stripe, Twilio, SendGrid, OpenAI, and the rest of the SaaS stack.
- Cloud access keys — AWS access key pairs, GCP service-account JSON, Azure client secrets.
- Signing and encryption material — JWT signing keys, TLS private keys, GPG keys, code-signing certificates.
- Tokens for machine-to-machine auth — OAuth client secrets, webhook signing secrets, CI deploy tokens.
A telling non-example: LOG_LEVEL=debug or AWS_REGION=us-east-1. These ride in the same .env file and the same environment block, but leaking them costs you nothing. Keeping config and secrets in the same place is convenient; treating them as equally sensitive is what slows teams down. The job is to tell them apart and protect only what actually needs it.
Related terms
- Environment Variables vs SecretsWhy a delivery mechanism and a sensitive credential are not the same thing — and how to store each one safely.
- Secret RotationReplacing credentials on a schedule to cap their exposure — the patterns, the cutover problem, and how automation helps.
- SAML for Secrets ManagementHow single sign-on governs who can reach your secrets — and why identity is a separate guarantee from encryption.
How Capy helps
Capy treats secrets as a first-class, version-controlled resource without the operational weight of a Vault cluster or a cloud KMS. Each value is encrypted on the developer's machine before it leaves, so the service stores ciphertext and never holds the material to decrypt it. That means a breach of the vendor comes out as “the attacker has bytes,” not “the attacker has your secrets.”
The day-to-day flow stays close to what developers already know. Values are injected at runtime with a one-line wrapper, capy run -- your-command, so secrets never have to be written to a long-lived .env on disk. A committable .keep manifest lets a reviewer see in a PR diff which secrets changed without exposing the values, and capy kick removes a teammate cryptographically rather than asking the whole team to rotate. For a deeper comparison of where encryption should happen, see environment variables vs secrets.
Frequently asked questions
What is the difference between a secret and a config value?+
A secret is a value that grants access and causes harm if leaked — an API key, password, or private key. A config value changes how an app behaves but is not sensitive on its own, like a log level or region name. The two often live in the same file, but only secrets need encryption, access control, and rotation.
Are environment variables secrets?+
Not inherently. An environment variable is a transport mechanism for passing a value into a process. It becomes a secret only when the value it carries is sensitive. A region name passed as an environment variable is config; a database password passed the same way is a secret.
Where do secrets typically leak in a DevOps pipeline?+
The most common places are committed .env files and source code, CI/CD logs and environment blocks, container images and Kubernetes manifests, Terraform state files, and developer shell history. Each copy of a secret is a separate place it can leak, which is why centralizing and minimizing copies matters.
How should teams store secrets safely?+
Keep secrets out of source control, encrypt them at rest and in transit, give each person and service the least access they need, rotate on a schedule and after any suspected exposure, and inject values at runtime rather than leaving them in long-lived files. A dedicated secrets manager automates most of this.
Install Capy in 30 seconds
brew install capysc/tap/capynpm i -g @capy/cli