Secrets Manager Architecture and Deployment
Domain 2 - Secrets Manager Architecture and Deployment
This domain tests the components and deployment choices of CyberArk Secrets Manager (Conjur), including self-hosted and SaaS options, leader and follower roles, database, load balancing, and client connectivity.
Core rules and concepts
- Self-hosted Secrets Manager, often called the Dynamic Access Provider (DAP), runs on Kubernetes via Helm. Secrets Manager SaaS is CyberArk-managed. Both expose the Conjur API and the same policy model.
- The leader is authoritative for policy and writes. Followers are read replicas that serve authentication and secret retrieval close to workloads. Standbys provide high availability for the leader. PostgreSQL stores data, and audit events must be forwarded to a SIEM.
- Clients should authenticate and retrieve secrets from a follower or a load-balanced endpoint. Policy loads go to the leader. Replication is one-way from leader to followers, so a follower cannot accept authoritative policy changes.
- High availability means leader plus standby, multiple followers per region, load balancer health checks, backup and restore, and a tested disaster recovery plan.
- Network planning covers HTTPS API traffic, database ports, syslog or SIEM egress, certificate trust, and time synchronization. Authenticators are enabled per service ID, and host factory supports dynamic host enrollment.
Worked example
A bank needs reads in two regions and policy writes in one. Design: leader and standby in the primary region; one follower in each region; a global load balancer routes secret reads to the local follower and policy loads to the leader. If the leader fails, promote the standby and let followers resync. Workloads keep local latency, while audit events are forwarded centrally. The reasoning is that reads scale horizontally, writes need a single authority, and failover must preserve policy consistency.
Traps that cost marks
- Sending policy loads to followers and expecting them to persist.
- Assuming followers can accept writes or act as independent authorities.
- Deploying a single leader with no standby and calling it highly available.
- Forgetting that clients need a network path to a follower, not just to the leader.
- Treating SaaS as zero responsibility; identity configuration, policy, and audit consumption remain customer duties.
- Overlooking audit egress and time synchronization, which break correlation during investigations.