OpenBao → CyberArk Conjur
OpenBao ↔ CyberArk Conjur: integration to migration path.
Your secrets plane is load-bearing — break it and every workload's startup fails at once. So OpenBao deploys alongside Conjur Enterprise first, with its identity graph mirrored from yours, and your applications move one at a time against a parallel cluster. No flag day, no forced re-credentialing, and every phase rolls back in minutes.
The honest constraint: the CyberArk PAM bridge — PSM session brokerage and the Vault Synchronizer — has no OSS equivalent. This plan moves application secrets and keeps PAM exactly where it is. We say so on day one.
The idea
Mirror the identity graph. Move app secrets only.
The topology that makes this zero-outage: OpenBao stands up beside Conjur Enterprise and points auth/jwt at the same OIDC issuer Conjur already uses, so the same AD groups bind on both sides. Conjur stays authoritative for every in-flight workload and keeps the Vault Synchronizer link to CyberArk EPV alive, while External Secrets Operator becomes the swap point — an ExternalSecret reads Conjur first, then flips to OpenBao per app. The PAM-mastered branch is never in scope, so privileged human session brokerage through PSM keeps running untouched.
The phases
Six steps. Each one reversible.
Baseline & inventory
We label every Conjur variable as PAM-sourced or Conjur-native, every host by authenticator, every consuming app by client library, and we read the last 90 days of audit syslog for dead variables. This is read-only, and confirming Conjur OSS versus Enterprise is what decides whether full retirement is even possible.
Stand up OpenBao, mirror the identity graph
OpenBao stands up HA on Raft with cloud-KMS auto-unseal and its mounts created. We point auth/jwt at the same OIDC issuer Conjur uses, then run a cron that mirrors Conjur's role graph into OpenBao identity groups so the same AD groups bind on both sides. No production app reads OpenBao yet.
Point net-new apps at OpenBao
Every new onboarding uses OpenBao via External Secrets Operator, with workload identity through auth/jwt or auth/aws. Apps needing database credentials use the dynamic engine from day one. No existing app is touched.
Migrate Conjur-native variables
App by app, in blast-radius waves, the app carries both Conjur and OpenBao config, then flips its default read to OpenBao with Conjur as fallback. Variables backed by rotators are re-platformed onto dynamic engines instead of mirrored. PAM-sourced variables are never in scope.
Cut Conjur identity inputs for apps
Once an app host shows zero auth events for 14 days, we delete it and its grants from Conjur policy. Authenticators stay live only for PAM orchestration — the Vault Synchronizer and PSM service accounts. AD groups feeding both apps and PAM-vaulted humans stay mapped.
Final state — partial retirement (PAM stays)
OpenBao is now authoritative for all application secrets. Conjur Enterprise is retained for PAM-sourced variables only: the Vault Synchronizer feed continues and PSM keeps brokering privileged human sessions. The two systems run independently with separate auditor evidence.
Feature parity
Where OpenBao matches Conjur Enterprise, where it leads, and where it can't.
| Capability | OpenBao | Conjur Enterprise | Parity |
|---|---|---|---|
| Static secret storage | OpenBao KV v2 (secret/data/<path>) | Conjur !variable policy resource | At parity |
| Dynamic database credentials | OpenBao database/creds/<role> (leased per-request) | Conjur DB Password Rotator (rewrites static variable) | OSS only |
| Cloud STS issuance | OpenBao aws/sts/<role> outbound STS | Conjur authn-iam (inbound auth only, no STS engine) | OSS only |
| Lease-based revocation | OpenBao bao lease revoke (atomic DROP USER) | Conjur rotator rewrite (old cred valid until rotation) | OSS only |
| Encryption-as-a-Service | OpenBao Transit (encrypt / sign / hmac) | None | OSS only |
| PKI / SSH CA | OpenBao pki/issue plus ssh/sign | Stores cert plus key as variables; no issuance | OSS only |
| Auth methods | OpenBao auth/jwt, auth/kubernetes, auth/aws | Conjur authn-jwt, authn-k8s, authn-iam, authn-ldap | At parity |
| Continuous LDAP/AD sync | OpenBao auth/ldap bind-on-login (not continuous) | Conjur EE continuous LDAP/AD group sync | SaaS only |
| Policy engine | OpenBao HCL path plus capability | Conjur YAML !policy / !permit resource graph | Partial |
| Namespaces / multi-tenant | None — path-prefix convention | Conjur policy-branch isolation; Vault Namespaces are Ent-only | SaaS only |
| PAM session brokerage | None | CyberArk PSM (Privileged Session Manager) | SaaS only |
| PAM credential bridge | None | CyberArk Vault Synchronizer (EPV to vault/ branch) | SaaS only |
| Audit log | OpenBao HMAC-chained JSON sink | Conjur RFC 5424 JSON syslog | At parity |
| API / CLI | bao CLI plus hvac / vault-rb / Go SDK | conjur CLI plus conjur-api / summon | At parity |
| Vendor SOC / indemnity | Operator-owned (self-hosted) | CyberArk vendor SOC plus indemnification | SaaS only |
| FIPS 140-2/3 | Community-in-progress | CyberArk FIPS-validated modules | Partial |
What we're honest about
The caveats most vendors leave out.
The CyberArk PAM bridge never retires
Conjur Enterprise federates with the wider CyberArk platform — the Vault Synchronizer pushes EPV-mastered credentials into Conjur variables, and PSM brokers privileged human sessions with recording. OpenBao does none of that. So this plan terminates at a deliberate partial state: OpenBao owns application secrets, Conjur Enterprise keeps the PAM-sourced branch and PSM brokerage forever. Retiring CyberArk PAM is a separate program that starts with a PSM-replacement eval, not a secrets-vault migration.
Continuous LDAP/AD sync is an Enterprise feature
Conjur Enterprise continuously syncs AD groups into roles. OpenBao's auth/ldap is bind-on-login — group membership is captured at login and not refreshed until the next one, which opens a stale-group window auditors flag. The honest fix is auth/oidc against an IdP that already does the sync, or a documented mirror cron with a stated drift window. We never pretend either equals continuous sync.
Lease beats rotation, but it's a re-platform
OpenBao's dynamic database credentials are leased per-request and revoked atomically, which closes the rotation window of vulnerability Conjur rotators leave open. But moving a rotated, long-lived named DB user to per-request minted users means your connection pool, monitoring, and app-layer RBAC must accept usernames that change every checkout. We pilot one app and DB pair before fanning out.
Policy re-author is hand work, not a script
Conjur YAML policy is a declarative resource graph; OpenBao policy is path-glob plus capability HCL. A translator can get you started, but it cannot reliably tell Conjur's read (see-exists) from execute (read value) without context — so every output is pair-reviewed with the team that owns the variables. There is no vendor SOC boundary or indemnification once a workload moves to self-hosted OpenBao.
Why this beats a flag day
Reversible at every step, soaked before anything is cancelled.
Every per-app cutover rolls back in under 15 minutes while the dual-read path is still live — re-flip the SecretStore to Conjur, restore the policy entry, redeploy. And no variable is declared migrated until it has soaked at least 30 days on OpenBao with read-error rates at or below the Conjur baseline; dynamic-engine moves bake until in-flight leases age out naturally rather than mass-revoking. Only after that soak — and auditor sign-off on the split-responsibility model — does Conjur's application-secret scope close.
See whether your Conjur scope migrates cleanly.
A 30-minute call with a senior secrets engineer. We separate your Conjur-native variables from the PAM-sourced branch, size the rotator re-platforming, and confirm whether your CyberArk footprint is Conjur OSS (full retirement possible) or Enterprise with PAM (partial by design) — before you commit to anything.
Map my migration →