OpenBao → AWS Secrets Manager
OpenBao ↔ AWS Secrets Manager: integration to migration path.
Your secrets plane is load-bearing — break it and every workload's startup fails at once. So OpenBao deploys alongside AWS Secrets Manager first, authenticating workloads through their existing IAM roles, and your secrets move one at a time behind a dual-read path. No flag day, no forced re-credentialing, and every phase rolls back in minutes.
The honest framing: SM is so fused into IAM, KMS, CloudTrail and RDS rotation that retiring it for AWS-native services rarely pays back. So this is a scope partition — OpenBao takes cross-cloud and dynamic creds, SM keeps what it does best.
The idea
Authenticate on IAM you already have. Partition by scope.
The topology that makes this zero-outage: OpenBao runs HA on Raft, one cluster per region, and its AWS auth method lets a workload log in with the IRSA or instance role it already carries — no new secret to bootstrap. External Secrets Operator with two providers in priority order renders an identical Kubernetes Secret whether the value comes from SM or OpenBao, so pod manifests never change as the source flips. SM stays the store of record for everything AWS-native — RDS rotation, Lambda env, ECS task secrets — while OpenBao takes cross-cloud secrets, dynamic DB creds and short-TTL STS, per-secret, gated on lease TTLs rather than a single switch.
The phases
Seven steps. Each one reversible.
Baseline & inventory
We list every Secrets Manager secret with its KMS key, rotation Lambda, version count, principals and region, then classify each one: AWS-native (stays in SM), cross-cloud app secret (migrates), static IAM key (anti-pattern), or DB credential (dynamic-engine candidate). Read-only, cross-referenced against 90 days of CloudTrail.
Stand up OpenBao with the AWS auth method
OpenBao runs HA on Raft, one cluster per region, with cloud-KMS auto-unseal via AWS KMS. The AWS auth method lets workloads log in with their existing IRSA or instance role — no secret-zero. KV and AWS secrets engines are mounted and the audit device ships to your SIEM. No production secret lives in OpenBao yet.
Migrate cross-cloud KV with dual-read
Snowflake, Stripe, Datadog and other cross-cloud secrets are replicated into OpenBao KV v2, and apps move to read OpenBao first with SM as fallback. External Secrets Operator with two providers in priority order is the cleanest path for Kubernetes — the rendered Secret shape is identical, so pod manifests don't change.
Dynamic DB creds; STS for static keys
DB consumers switch from a static SM password to per-request leased users from the database engine. Static IAM access keys parked in SM are replaced by short-TTL assumed-role STS from the AWS secrets engine. We bake at least one full max-lease TTL per app to confirm no connection-pool starvation.
Decommission migrated SM scope
Once a migrated secret shows zero CloudTrail GetSecretValue events for 14 days, we delete it with a 30-day recovery window. What remains in SM matches the AWS-native classification from Phase 0 exactly — RDS rotation targets, Lambda env, ECS task secrets, RDS Proxy.
Optional — migrate RDS rotation
Full-retirement path only. Per RDS cluster we enable IAM database authentication, point OpenBao's database engine at a dedicated rotation user, and move apps to leased creds before disabling the AWS rotation Lambda. This is a re-architecture, not a config flip — reject it unless multi-cloud retirement is the explicit goal.
Final SM retirement
Full-retirement path only. SM entries are deleted with the 30-day recovery window and every IAM policy referencing secretsmanager is removed. Operationally significant — you now own RDS rotation reliability, cross-region replication, and the KMS audit trail end to end.
Feature parity
Where OpenBao matches AWS Secrets Manager, where it leads, and where it can't.
| Capability | OpenBao | AWS Secrets Manager | Parity |
|---|---|---|---|
| Static secret storage | OpenBao KV v2 (versioned, soft-delete) | SM secret plus version stages (AWSCURRENT / AWSPENDING / AWSPREVIOUS) | At parity |
| Dynamic database credentials | OpenBao database/creds/<role> (per-request leased user) | SM RDS/Aurora rotation Lambda (rotates one persistent cred) | OSS only |
| Cloud STS issuance | OpenBao AWS secrets engine (aws/sts/<role>, assumed-role under 12h) | SM stores static IAM keys; no STS issuance | OSS only |
| Managed rotation | OpenBao dynamic engines (rebuild yourself) | SM AWS-managed rotation Lambdas (RDS / Redshift / DocumentDB) | SaaS only |
| Encryption / seal / KMS | OpenBao cloud-KMS auto-unseal (storage-level) | SM per-secret KMS-CMK envelope plus CloudTrail KMS audit | Partial |
| Encryption-as-a-Service | OpenBao Transit (encrypt / sign / hmac / datakey) | None (KMS Encrypt under 4KB, no HMAC) | OSS only |
| Cross-region replication | App-side or custom KV mirror (one cluster per region) | SM ReplicateSecretToRegions (managed async) | SaaS only |
| Auth methods | OpenBao auth/aws (signed STS), auth/oidc, auth/kubernetes | IAM identity/resource policies on secretsmanager:GetSecretValue | Partial |
| Policy engine | OpenBao HCL ACL on token | IAM JSON policy on ARN | Partial |
| Audit log | OpenBao HMAC-chained JSON (file / socket / syslog) | CloudTrail data events to S3 to SIEM | Partial |
| Network reach | OpenBao ELB in private subnet | SM PrivateLink VPC endpoint | Partial |
| API / CLI | bao CLI plus hvac / Go SDK | aws secretsmanager CLI plus AWS SDK | At parity |
| FIPS 140-3 | Operator-asserted FIPS build | Inherited from KMS FIPS endpoints | Partial |
| Cost model | Compute plus storage plus ops labour | Per-secret plus per-API-call | Partial |
What we're honest about
The caveats most vendors leave out.
AWS-managed rotation Lambdas have no OSS equal
SM's rotation Lambdas for RDS, Aurora, Redshift and DocumentDB are hardened across thousands of accounts. OpenBao does not replace them — you rebuild rotation as a dynamic engine, which is a real workstream, not a config flip. That is why the recommended end state keeps SM for AWS-native services: this is a scope partition, not a retirement. OpenBao owns cross-cloud and app secrets; SM keeps RDS rotation, Lambda env and ECS secrets.
ReplicateSecretToRegions and PrivateLink are SM-only
SM gives you managed async cross-region replication and a PrivateLink VPC endpoint for free. OpenBao has no replication equivalent — multi-region apps read region-local clusters you sync yourself with a CI controller — and its network equivalent is an ELB in private subnets, which is functionally similar but a different evidence shape for auditors. We document the network architecture explicitly so it maps to your prior PrivateLink posture.
You trade per-secret KMS audit for storage-level audit
Every SM GetSecretValue lands in CloudTrail with the KMS key ARN — a per-secret audit trail for free, plus FIPS 140-3 inherited from KMS endpoints. OpenBao's HMAC-chained audit is storage-level and tamper-evident, not per-secret, and its FIPS posture is operator-asserted rather than vendor-claimed. If FIPS is a hard requirement, SM stays for those workloads. Either way the SOC 2 and PCI narrative is rewritten — you now operate the control.
Two control planes mean policy drift you manage
Running OpenBao beside SM means two policy systems — IAM JSON and OpenBao HCL — for overlapping principals, and drift between what IAM allows and what HCL allows is the dominant operational risk. We mitigate by naming OpenBao roles to mirror IAM ARN suffixes and running a periodic reconciliation diff, shipped as Terraform so both surfaces change together. There is no AWS shared-responsibility backstop on the OpenBao side once a secret moves.
Why this beats a flag day
Reversible at every step, soaked before anything is deleted.
Every per-secret cutover rolls back in under 15 minutes while the dual-read path is still live — revert the app to read SM, which still holds the value, and you are back before anyone notices. And no secret is deleted until it has soaked at least 30 days on OpenBao with read-success at or above baseline; leased credentials age out within their max-lease TTL rather than being mass-revoked. Even then SM deletes carry a 30-day recovery window before anything becomes permanent.
See whether your Secrets Manager scope migrates cleanly.
A 30-minute call with a senior secrets engineer. We classify your SM secrets into AWS-native versus cross-cloud, size the dynamic-engine and STS work, and tell you honestly whether your shop lands at a scope partition (the usual win) or a full retirement — before you commit to anything.
Map my migration →