CyberArk Conjur - panoramica su system requirements e architettura

Continua la serie su CyberArk Conjur, nel post precedente ho spiegato a cosa serve un secrets manager enterprise, in questo post parlerò di architettura e system requirements. 

Conjur è disponibile in versione Enterprise, opensource (chiamata OSS) ed a breve lo sarà anche in versione cloud in soluzione SAAS.

I miei post fanno riferimento alla versione enterprise, che è comunque molto simile alla OSS.

Architettura

Conjur è distribuito come appliance in forma di docker image, quindi il suo setup dell'infrastruttura risulta semplice e veloce.

Questi sono i componenti principali dell'appliance: 

• nginx   - garantisce l'accesso web per GUI amministrativa e API per fruizione secrets
• postgres database - contiene tutti i dati di conjur, secrets e policies. Inoltre c'è un secondo db per. i log funzionali e di audit
• conjur appliance - il prodotto 
• syslog-ng - viene utilizzato per collezionare log e audit di funzionamento

La configurazione minima tipica in ambito enterprise è di 3 nodi, configurati in cluster con auto-failover:

Il funzionamento del cluster come si può intuire dalla figura, è active-passive e si basa su un nodo principale , "leader", che eroga i servizi mantiene i db in read write e fornisce accesso tramite API rest ai secrets. 

Oltre al leader vengono tipicamente installati 2 o più nodi inattivi, chiamati "standby", che possono essere sync o async . 

I dati sono replicati fra i vari nodi sfruttando la postgres replication.

In caso di fail del nodo principale , viene eseguita la promozione di un nodo Standby utilizzando etcd e Raft consensus algorithm ed il load balancer garantirà l'accesso al nuovo nodo leader.

In caso il cluster non sia configurato con una policy di auto-failover, va eseguita una promozione manuale di un altro nodo. 

E' possibile avere ad esempio una configurazione con un site primario in auto-failover ed un nodo di disaster recovery con standbys async da promuovere manualmente in caso di necessità.

Oltre ai nodi che costituiscono il cluster, esiste la possibilità di installare dei nodi passivi chiamati follower, che possiedono una replica dei db in read-only e garantiscono accesso ai secrets alle applicazioni. 

Un caso tipico di utilizzo di un follower è su un cluster Kubernetes, dove viene installato garantire la minor latenza possibile nella risposta alle applicazioni locali.

L'architettura finale quindi aggiungendo follower e applicazioni al disegno sopra diventa qualcosa di simile al seguente: 

System requirements

La configurazione suggerita per i nodi di produzione è la seguente: 

• 4 core
• 8 GB ram
• 50 GB hd

Per un ambiente di dev/test

• 2 core
• 4 GB ram
• 20 GB hd

per quanto riguarda il container runtime sono supportati  i seguenti

• docker 1.13 or later
• Mirantis Container runtime (MRC) 19.x, 20.10 su RHEL 8.x
• Kubernetes e Openshift ( solo per i follower ) 
• podman 3.3 e 3.4 

mentre OS host deve essere uno di quelli supportati dai container runtime (tipicamente RHEL e derivate o Ubuntu server LTS) .

Nel caso in cui disponiate di un server CyberArk Vault e vogliate sincronizzare i secrets verso Conjur per espanderne l'adozione , è necessario installare un server per il componente Vault Synchronizer  

• 4 core
• 8 GB ram
• OS Windows 2012 R2 o superiore