SikkerKey vs AWS Secrets Manager

Manage your secrets vault across EC2, GKE, AKS, on-prem hosts, and developer laptops with one cryptographic identity per machine. The auth doesn't depend on which cloud the workload runs on.

Start for Free

Summary

AWS Secrets Manager is part of AWS. Authentication runs through IAM and STS. Encryption keys live in KMS. Rotation runs through Lambda. CloudTrail records every API call. Workloads outside AWS reach the vault through IAM Roles Anywhere, which is an X.509 PKI federation project layered over IAM, and the bill scales with each secret stored and each API call made.

SikkerKey is built around a different primitive. Every request is signed by the machine making it, using an Ed25519 private key that lives on the host. The signature commits to the exact method, path, body, and timestamp, so it doesn't double as a credential anyone can replay. The same bootstrap registers a machine on EC2, GKE, AKS, a Hetzner box, an on-prem rack, or a developer laptop.

Around that primitive, SikkerKey ships features AWS Secrets Manager doesn't have natively: structured secrets with per-field grants, canary secrets that lock a project on first read, an AI agent identity class that's structurally read-blind on stored values, contractor machines with IP / geo / time guardrails, one-view share links, and HMAC-signed webhooks for every audit action.

A workload on EC2 and a workload on a Hetzner box authenticate to the same SikkerKey vault, with the same bootstrap and the same signed-request protocol.

The result: cross-cloud and hybrid teams maintain one secrets layer instead of running AWS Secrets Manager alongside something else for the non-AWS workloads.

	SikkerKey	AWS Secrets Manager	Why it matters
Machine authentication
Secret request	Ed25519 signed request. The signature is computed on the machine from a private key that never leaves it, and SikkerKey verifies it against the public key on file.	IAM bearer token issued by AWS STS. Every `GetSecretValue` call is authenticated with the token until it expires.	The signature is bound to one specific request and stops being valid the moment the request is sent. The next call needs a new signature, computed on the machine from the same private key, which stays on the host across the machine's lifetime.
Workloads outside the home cloud	The same bootstrap script. A developer laptop, an on-prem box, a Hetzner machine, and an EC2 instance run identical commands.	IAM Roles Anywhere. Trust anchor, X.509 PKI, certificate issuance to each external workload, and a session-exchange call to convert the certificate into temporary IAM credentials.	SikkerKey's auth doesn't route through a cloud identity broker. The bootstrap script that runs on EC2 is the same one that runs on a developer laptop or an on-prem box.
CI fleet enrollment	One enrollment token registers up to N ephemeral machines, each with a hostname regex match, source CIDR check, and an automatic expiry. Auto-expired machines are soft-disabled and hard-deleted 30 days later.	No native equivalent. CI runners outside AWS register through IAM Roles Anywhere; runners on AWS attach an instance, task, or execution role per platform.	An enrollment token issued from the dashboard provisions identities for new CI runners as they come online and revokes them when their machines disappear. Setting up a new runner means dropping a curl command into the runner's startup script; the per-runner IAM configuration that AWS workloads need on AWS doesn't have an analogue here.
Identity primitives
AI agent identity	AI agents are a separate identity class with their own table, scope set, and Ed25519 signed-request authentication. The agent surface is structurally plaintext-blind: write actions accept plaintext input but never return stored values, and the read paths physically don't accept an agent identity as a caller.	Not a separate identity class. AI services authenticate with an IAM role; if that role has `secretsmanager:GetSecretValue`, the agent can read.	Give an AI agent broad management permissions on your vault without any risk of it reading your secrets. The agent identity is structurally plaintext-blind, so even an agent granted every management scope cannot fetch a stored value.
Temporary machines	Single-use bootstrap tokens that mint time-bounded machines with optional per-machine IP allowlist, ISO-3166 country allowlist, and IANA time-of-day window. Bounded between 1 hour and 12 months at issuance; extensions are audited inline with full revert history.	No native primitive. Time and IP are expressible via IAM condition keys; per-machine country allowlists and time-of-day windows aren't.	The bootstrap token bakes in the time window, source IP range, country allowlist, and lifetime at the moment of issuance. Those constraints attach to the machine identity itself, so they apply at every fetch without anyone having to remember to enforce them later.
Secret model
Structured secrets	A secret can hold multiple named fields as one logical unit. A database credential is one secret with `host`, `port`, `username`, `password` fields, encrypted and versioned together. SDKs read fields directly.	Not a native primitive. Secrets are strings; the console's “key/value pairs” type is stored as JSON and returned as a string for the application to parse.	The whole credential rotates and audits as a single object. SDKs expose each field directly, so application code reads `secret.password` rather than parsing a JSON document returned by `GetSecretValue`.
Temporary share links	Server-generated diceware passphrase, hashed with Argon2id. One view total; the secret is destroyed on the first wrong passphrase. Expiry between 60 seconds and 24 hours, audit-tracked from creation to view.	No native equivalent.	Hand a credential to a contractor or a teammate without putting it in chat. The link self-destroys after one view or one wrong passphrase, and every share is logged with creator, viewer IP, and timestamp.
Access controls
Per-secret access policies	Named policies you bind to specific secrets. Each policy can require a time window, an IP allowlist, a read-rate cap, a co-signing machine, TTL-based destruction, or rotate-after-N reads, in any combination. One policy binds to many secrets.	IAM resource policies on each secret support time and IP via `aws:CurrentTime` and `aws:SourceIp` condition keys. Read-rate caps, co-signing, and read-count TTLs aren't expressible.	Lock down a high-value secret with constraints SikkerKey enforces at every fetch: time windows, IP allowlists, read-rate caps, co-signing, TTL destruction, or rotation triggers. The enforcement runs server-side, so the application receives either the secret value or a denial.
Canary secrets	A decoy secret you plant in a project alongside the real ones. Looks identical to any other secret to whatever reads it.	Not a native primitive.	A compromised machine in your vault triggers a complete project lockdown the first time it reads a canary, in the same database transaction as the fetch, before more of your secrets can be returned. An optional second layer extends the lockdown to every other project the same machine has access to.
Rotation
Database credential rotation	The agent runs on the host you choose: a Kubernetes pod, an EC2 instance, a Hetzner machine, an on-prem box. SikkerKey generates the new value, the agent applies it via the database's admin protocol, verifies it works, then confirms back so SikkerKey promotes it as the new live version. Supports PostgreSQL, MySQL, Redis, MongoDB.	A Lambda function in your AWS account holds the database admin credentials and applies the rotation. The Lambda runs in AWS even when the database is on another cloud or on-prem.	Run the rotation agent on the host where your application already lives. The agent applies the new credential and tests a connection against the database before reporting back; SikkerKey only promotes the new value after that test passes.
Observability
Alerts and webhooks	Email and webhooks for any of 60+ audit actions, opt-in per action. Webhook deliveries are HMAC-SHA256 signed, retried with exponential backoff, SSRF-protected by DNS pinning, and auto-disabled after 10 consecutive failures.	CloudTrail events route to EventBridge rules, which can target Lambda functions or SNS topics. Secrets Manager itself doesn't emit native webhooks; the signing, retry, and SSRF protection are the customer's responsibility.	Wire any audit action to email or to an HMAC-signed webhook, opt-in per event. The delivery layer retries with exponential backoff, refuses to call internal or private-range addresses, and auto-disables an endpoint that fails 10 deliveries in a row.
Operational
CLI workflow	A single Go binary. `sikkerkey run --secret <id> -- <command>` injects the secret as an environment variable and runs the command. Optional `--watch` polls every 15 seconds and restarts the child process when a secret rotates.	`aws secretsmanager get-secret-value` returns the secret as JSON. Parsing it, injecting it into a process, and restarting on rotation are the caller's responsibility.	Drop a SikkerKey-aware command into a Procfile or a Dockerfile entrypoint and the secret arrives in the child's environment without writing it to disk. Rotation triggers a clean process restart with the new value.
Pricing model	Flat monthly subscription with a free tier. Paid plans cover the secrets, machines, projects, rotations, audit retention, and webhook deliveries up to plan limits.	$0.40 per secret per month plus $0.05 per 10,000 API calls. Replicated secrets are billed per region.	Storage and fetch volume don't change the SikkerKey bill. Plan price covers secrets, machines, and read traffic up to the plan's stated limits, with no per-secret or per-call line items added at the end of the month.