CyberArk Conjur : a quick overview about architecture and system requirements

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.

Architecture

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:

The cluster architecture is an active-passive cluster and the high availability is guaranteed by a load balancer put in front of the cluster, that switches the node accessed by the applications in case of failure.

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:

System requirements

The resources suggested for conjur nodes  for a production environments are: 

• 4 core
• 8 GB ram
• 50 GB hd

For a test environment:

• 2 core
• 4 GB ram
• 20 GB hd

This are the supported container runtime 

• 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 

the host server should run an os supported by the container runtime (the most popular are RHEL  server, RHEL based or Ubuntu server LTS) .

In case the customer environment contains also a Cyberark Vault server that needs to be synched with Conjur, the following are the requirements for a CyberArk Vault Synchronizer server:   

• 4 core
• 8 GB ram
• OS Windows 2012 R2 or later