Secrets manager

What it is

A secrets manager is a service that stores credentials (passwords, API keys, database connection strings, certificates) and serves them to applications and machines at runtime. It centralizes three things that are otherwise hard to do well: who's allowed to read each value, the audit trail of who read what when, and rotation of the value without redeploying consumers.

The category exists because credentials at scale stop being a code problem and become an operations problem. A team with one developer keeps secrets in a .env. A team with twenty developers, three CI pipelines, two production environments, and a fleet of microservices needs distribution, rotation, audit, and revocation in one place. The secrets manager is the system designed for that.

What it does

Five capabilities define the category:

• Encrypted storage. Values are encrypted at rest, typically with envelope encryption: a per-secret data key encrypts the value, and the data key is itself wrapped by a master key the storage system doesn't have direct access to.
• Authenticated delivery. Applications and machines authenticate to the secrets manager and receive the values they're allowed to see. Authentication is per-actor (each service has its own identity), not shared across the fleet.
• Access control. Each secret has an explicit list of identities allowed to read it. A leaked credential for one service can't read secrets meant for another.
• Audit logging. Every read, every grant, every rotation is recorded with who, when, and from where. Tamper-evident in the better implementations.
• Rotation. Old values can be replaced without redeploying consumers. Better systems also rotate the underlying credentials in the source system (the actual database password gets changed, not just the value the secrets manager hands out).

The minimum viable secrets manager covers the first three. A production-grade one covers all five and adds dynamic secrets (credentials minted on demand with short lifetimes), broadcast invalidation (a revoked credential stops working everywhere at once), and integration with the identity systems that already exist in your environment.

Architectural shapes

A secrets manager can be deployed in one of three shapes, each with different operational and trust implications:

• Cloud-provider native. Run by your cloud provider as a managed service, tightly integrated with that cloud's IAM and key-management primitives. Cheap inside that cloud, harder to use across multiple clouds or for off-cloud workloads, and the operational trust is whatever you already trust the cloud provider with.
• Self-hosted. You run the system on your own infrastructure. Maximum control over where keys live and how they're stored, but also maximum operational burden: keeping the system healthy is its own job on the team, and the security floor moves with how carefully the team operates it.
• SaaS-native. Run by a third-party as a hosted service, designed to drop into existing application code without infrastructure overhead. The trade-off is operational trust: you outsource the running of the system in exchange for not having to run it.

Most teams pick one and stick with it. The shape that fits is a function of where the workloads run, what compliance constraints apply, and how much operational headcount the team can dedicate to running infrastructure that isn't its product. Running multiple secrets managers in parallel is provider sprawl in itself, and creates the same kind of consistency problem the secrets manager was supposed to solve.

What SikkerKey is

SikkerKey is a SaaS-native secrets manager. The pieces:

• Encrypted storage. Every secret is encrypted under a key generated just for that secret. That key is wrapped under your project's master key. Every project master key is wrapped under an in-memory key that's never written to disk.
• Machine authentication with Ed25519 signed requests. Each machine carries its own private key generated locally during bootstrap; SikkerKey only sees the public key.
• Per-secret grants. A machine has to be added to a project and then explicitly granted each secret it can read. No grants means no reads, even with a valid signature.
• Audit logging that records every secret read, grant change, machine event, and authentication failure with timestamp, IP, and actor.
• Scheduled rotation that works on any secret, not just database credentials. For secrets backing PostgreSQL, MySQL, MongoDB, Redis, or MSSQL, a local sync agent additionally pushes the new value to the live database.
• Canary secrets that freeze a project the moment they're read, so an attacker who finds and uses one is contained before they can read anything else.

SikkerKey targets teams that need a real secrets manager without the cost of operating one themselves: machine identity, audit trail, encryption, and rotation, all delivered as a managed service.