Secrets that are scoped, short-lived and rotated
One store for credentials across pipelines, clusters and applications, with least-privilege scoping, automatic rotation and an audit trail that records every read.
What is Secrets?
DevOpsArk secrets is the module that stores, scopes, distributes, rotates and audits credentials used by pipelines, Kubernetes workloads and applications, replacing secrets held in CI variables, manifests and configuration files.
What Secrets is for
The conditions this module removes. If none of these are familiar, you probably do not need it yet.
- Credentials live in CI variables, Kubernetes Secret objects and a shared password manager, and nobody knows which copy is current.
- A Kubernetes Secret is base64, which is encoding, not encryption, and it sits in etcd.
- Rotation is manual, so credentials from 2021 are still valid.
- There is no record of which workload read which secret and when.
- Offboarding an engineer means guessing which credentials they saw.
Secrets are held in one encrypted store and accessed through short-lived, scoped tokens rather than distributed as long-lived copies. A pipeline run, a workload or an engineer receives a token that grants access to exactly the secrets that identity needs, for as long as it needs them. For supported systems (databases, cloud providers, message brokers) DevOpsArk can issue dynamic credentials that are created on request and revoked automatically when the lease ends, so nothing long-lived exists to leak. Rotation runs on a schedule or on demand, coordinated with the consumers so the new value is in place before the old one is revoked. Every read is recorded with identity, secret, purpose and time, which turns both audits and incident response from reconstruction into a query.
What Secrets does
The 7 capabilities that make up Secrets.
Central encrypted store
One place for credentials, encrypted at rest with a key you control, replacing CI variables and Secret objects.
Short-lived access tokens
Access is granted per identity, per scope and per duration; nothing durable is handed to a pipeline run.
Dynamic credentials
Database, cloud and broker credentials created on request and revoked when the lease expires, so there is nothing to rotate.
Coordinated rotation
Scheduled or on-demand rotation that places the new value before revoking the old one, so consumers do not break.
Full read audit
Identity, secret, purpose and timestamp recorded for every access, queryable during an incident.
Kubernetes integration
Secrets projected into workloads at runtime rather than stored as long-lived Secret objects in etcd.
Leak response
When secret scanning finds a credential in a repository, the store identifies it, reports its consumers and rotates it.
How Secrets fits together
Outcomes
- There is one current copy of every credential.
- Long-lived credentials largely disappear, and what remains is rotated on a schedule.
- Offboarding and incident response start from an access log rather than an estimate.
- A leaked credential can be rotated with its consumers already known.
- Kubernetes workloads stop depending on long-lived Secret objects.
Using Secrets, step by step
The path from connecting a source to getting value, in the order it happens.
- 1Centralise
Import credentials from CI variables, manifests and existing stores.
- 2Scope
Define which identity may read which secret, and for how long.
- 3Distribute at runtime
Consumers fetch secrets with short-lived tokens instead of holding copies.
- 4Rotate
Scheduled rotation places the new value before revoking the old.
- 5Audit
Every read is recorded and queryable.
Where teams apply Secrets
Remove secrets from CI configuration
Pipelines fetch what they need at runtime with a scoped token that expires with the run.
Rotate everything after an incident
Identify affected credentials, see who read them, and rotate with consumers coordinated.
Use database credentials that expire
Receive dynamic credentials per instance and lease instead of a shared static password.
Evidence credential controls
Show scoping, rotation cadence and access history from one audit trail.
What Secrets works with
Named integrations link to their own page. The rest are supported runtimes and formats.
Secrets: frequently asked questions
The 7 questions teams ask most often before adopting Secrets.
Secrets management is the practice of storing, scoping, distributing, rotating and auditing credentials such as passwords, API keys, tokens and certificates, so they are not copied into code, configuration files or CI settings.
A Kubernetes Secret is base64-encoded, not encrypted, and is stored in etcd. With encryption at rest and tight RBAC it can be adequate, but it remains a long-lived credential inside the cluster with no rotation and no read audit. Projecting short-lived secrets at runtime avoids those limitations.
Credentials created on request for a specific consumer and lease period, then revoked automatically when the lease ends. Because they do not persist, there is nothing long-lived to leak and nothing to rotate.
Rotation is coordinated with consumers: the new value is placed and the consumers are updated before the old value is revoked, with an overlap window. Rotation status is tracked per consumer, so a straggler is visible rather than discovered as an outage.
It can, or it can broker access to an existing Vault, AWS Secrets Manager or Azure Key Vault. Many teams keep their store and use DevOpsArk for scoping, rotation coordination and the unified access audit.
Secret scanning reports it, the store identifies which credential it corresponds to and which consumers use it, and rotation can be triggered immediately. The access audit shows whether it was used from an unexpected source in the meantime.
Only identities explicitly scoped to it, and every read is recorded. Values are not displayed in the interface by default, and viewing one is itself an audited action.
See Secrets against your own environment
A 30-minute walkthrough with a platform engineer, not a sales deck. Bring a cluster and a problem.