As I wrote in my last post, CyberArk Conjur is an enterprise secrets manager.
In this post I'll do an architecture overview with some of the system requirements.
Conjur is currently available in 2 different versions , Enterprise and open source (known as OSS); the "cloud" version will be available soon, offered as a SAAS solution.
My post is about the enterprise version, that is similar but not the same as OSS.
Conjur is distributed as a docker image, so deployment and configuration are fast and safe to be done.
This are the main services included in the appliance image:
- nginx - allows the access to the administrative GUI and the access to the API set to interact with the secrets
- postgres database - 2 databases, one for configurations and secrets, one for the audit logs
- conjur appliance - the product
- syslog-ng - it's used to collect audit and access logs
The enterprise smallest common configuration of Conjur is a 3 node cluster with auto-failover, as in the following diagram:
Inside the cluster, a node will act as the "leader node"; it takes charge of the read/write operations of the system and it is accessed by the applications using the API to interact with the secrets.
The secondary nodes are named "standbys" and could be sync or async nodes, depending on the postgres replication setup. These nodes are inactive and do not provide the API service.
In case the leader node fails, after a time set into the configuration, the standbys will elect a new leader using etcd and the Rafts consensus algorithm.
In case the auto-failover were not configured, a manual promotion is needed.
It's also possible to set a primary site configured with the auto-failover policy and a secondary site with async standbys, without the auto-failover, ready to be promoted manually.
The last piece of the architecture is the "follower", a read only replica of the Leader.
Followers, which allow secrets reads at scale, are horizontally-scaling components that are typically configured behind a load balancer to handle all types of read requests, including authentication, permission checks, and secret fetches.
Usually Followers are installed on a Kubernetes cluster to serve applications with a low latency response time.
The architecture diagram with followers could be expanded as below:
The resources suggested for conjur nodes for a production environments are:
- 4 core
- 8 GB ram
- 50 GB hd
- 2 core
- 4 GB ram
- 20 GB hd
- docker 1.13 or later
- Mirantis Container runtime (MRC) 19.x, 20.10 su RHEL 8.x
- Kubernetes e Openshift (only for the follwer)
- podman 3.3 e 3.4
- 4 core
- 8 GB ram
- OS Windows 2012 R2 or later
Post a Comment