CyberArk Conjur 12.9 e podman - come ripristinare la logs rotation in caso di problemi

CyberArk Conjur è rilasciato sotto forma di appliance containerizzata, in modo da poter permettere rapidi setup senza errori.

I container runtime supportati sono i seguenti:

• docker 20.10 or later
• mirantis container runtime 20.10
• podman 3.x,4.x

Lavorando su diversi ambienti Conjur nei nostri lab o da clienti ci siamo resi conto che la logs rotation (conjur, nginx, cluster, etc) non veniva eseguita in ambienti installati su podman mentre funzionava correttamente su Docker.

Dopo alcune indagini con i ragazzi del CyberArk support team, abbiamo trovato la soluzione:

i conjur container devono essere creati aggiungendo la capability AUDIT_WRITE :

podman run \ ... --cap-add AUDIT_WRITE \ ... registry.tld/conjur-appliance:12.9.0

per risolvere poi un successivo problema di rumore nei log di nginx va cambiato il seguente permesso nei container di Conjur:

chmod 701 /opt/cyberark/dap/log/nginx

Il CyberArk support team è stato collaborativo come sempre nel lavorare con noi per trovare la soluzione.

Entrambi i problemi sono stati tracciati nella documentazione di CyberArk e dovrebbero essere risolti a breve nella doc e nelle immagini rilasciate. 

In caso riscontriate lo stesso problema nei vostri ambienti vi suggerisco comunque di contattare il team di supporto per avere conferma che la soluzione sia applicabile anche ai vostri ambienti..

SIGHUP Secure Containers: come scegliete le base image per i vostri workload?

Premessa: in questo articolo parlo di un prodotto/servizio offerto dall'azienda per cui lavoro, SIGHUP, voglio specificare che non mi è stato richiesto di parlarne qui sul mio blog, ma quelle che seguono sono le mie opinioni riguardo a questo servizio.

Secure Containers è un servizio commerciale, offerto da SIGHUP che fornisce container base image sicure, hardenizzate e aggiornate. 

Lavorare in ambienti containerizzati rispetto al passato ha molti vantaggi, come standardizzazioni, automazioni e velocità di rilascio.

Talvolta però ci si dimentica che lavorando con container, spesso ci si affida ad container image fatte da trovate da varie fonti che potrebbero avere uno o più dei seguenti problemi:

• bug
• CVEs
• non essere aggiornate
• contenere sw malevolo

E' chiaro che avere base image costantemente aggiornate, che contengano il minor numero di CVEs possibili è importante perchè eventuali problemi, una volta deployato il software, vengono replicati nel container che poi troviamo a girare negli ambienti di produzione.

Tenere aggiornate e sicure le base image quindi è un attività non trascurabile, che deve diventare un task  seguito in modo adeguato da qualcuno in azienda togliendolo da altri compiti.

Secure Containers si pone come servizio gestito da parte di SIGHUP e viene erogato con alcune caratteristiche interessanti fra cui :

• un catalogo di immagini completo
• scansioni di sicurezza regolari
• report settimanali sullo stato del catalogo (update, immagini deprecate)
• immagini da fonti verificate prometheus friendly
• supporto in caso di problemi

Se vi interessa un quadro più completo sulle base image e sul perchè è importate metterle in sicurezza potete consultare questo mio articolo dove ne parlo più in profondità. 

Se siete interessati al servizio offerto da SIGHUP, andando al sito dedicato potete trovare ulteriori informazioni,FAQ o essere contattati per aprire il periodo di prova gratuita con cui verificare e testare direttamente il prodotto. 

Snyk, come accontentare Developers e Security officers

Per lavorare nella cybersecurity serve conoscenza della materia, attenzione ai dettagli ed un buon portfolio di tools ai quali affidarsi.

Uno dei tools con cui ho avuto il piacere di lavorare negli ultimi mesi è Snyk.

Chiamarlo tool è riduttivo perchè Snyk è una security plattform che comprende una serie di tools atti a rendere sicuro tutto il codice che potete produrre:

• code (SAST)
• open source (SCA)
• container
• infrastructure as a code
• cloud

Negli ultimi anni le righe di codice sono cresciute esponenzialmente, le librerie open ed i container a disposizione dei developers hanno aumentato la quantità di codice prodotto semplificando il lavoro, ma a che prezzo?

In che modo  si può essere sicuri che oltre ad aver prodotto codice sicuro, non si vada ad incappare in vulnerabilità prodotte da queste risorse? I reparti che si occupano di sicurezza come possono controllare e validare grandi moli di lavoro senza diventare colli di bottiglia che rallentano la "produzione"?

Snyk risponde a queste esigenze, andandosi ad inserire ad esempio in IDE, repository git o pipeline CI/CD e riuscendo a fornire risposte rapide ed efficaci.

Ad esempio Snyk è in grado di aprire pull request dopo scansioni su repository git in modo automatico, andando ad evidenziare le vulnerabilità e proponendo una soluzione.

Per venire incontro alle esigenze degli uffici sicurezza, queste funzionalità sono configurabili centralmente tramite policy che allineano il comportamento dei tools alle specifiche esigenze e è possibile avere report e dashboard per capire rapidamente lo stato della sicurezza dei vari progetti.

Snyk inoltre ha generato il proprio db delle vulnerabilità, che oltre a catalogare i CVE con le varie severity, fornisce quando possibile, esempi e suggerimenti per i developers.

Provarlo è semplice perchè è stato previsto un piano limitato gratuito!

Vi lascio inoltre il link all'articolo pubblicato dal mio collega Luca Bandini che racconta la nostra esperienza con Snyk, utilizzato anche per controllare il codice di Fury, la distrubuzione Kubernetes svilluppata da SIGHUP.

CyberArk Conjur follower, system error e reboot in fase di configurazione: come risolvere (verificare connettivita postgres in modo corretto)

Lavorando con CyberArk Conjur, mi sono trovato in una condizione anomala del comportamento dei follower, che ha necessitato di un pò di debug per venirne a capo.

I follower su Kubernetes erano in grado di contattare le API del nodo leader di Conjur in modo corretto, quindi si inizializzava la configurazione del follower, ma poi questa non finiva andando in un generico System Error e il pod del follower iniziava a riavviarsi.

Dopo alcune analisi abbiamo capito che il problema era lato network load balancer che esponeva la porta Postgres in modo non corretto.

In prima fase di troubleshooting avevamo verificato la connettività dal follower al leader tramite il comando nc. ma questo non è ovviamente sufficente perchè verifica la connettività TCP fra follower e loadbalancer.

Per vedere se in effetti la connettività Postgres può funzionare, è necessario utilizzare questo comando openssl:

echo "" | openssl s_client -starttls postgres -connect <lb_DNS>:5432 -showcerts

In caso di successo, fornisce il certificato del server. 

Ringrazio il supporto CyberArk per avercelo girato (noi avevamo fatto la verifica in altro modo meno elegante con stesso risultato). 

Per altre opzioni e spiegazioni aggiuntive sul comando  openssl s_client, vi rimando a questo blogpost che trovo ben fatto e completo.

CyberArk Vault Synchronizer - CASVM035E Vault name is missing , come risolvere

Una delle componenti di Cybeark Conjur è il Synchronizer che serve a ricevere i secrets dal Vault.

Nei giorni scorsi mi sono imbattuto in un CyberArk Vault Synchronizer 11.7 in stato di "abbandono" che necessitava comunque di un aggiornamento alla 12.7.

Dopo aver effettuato l'aggiornamento seguendo la documentazione, il servizio non partiva, con il seguente errore nei log

[5] [main] FATAL VaultConjurSynchronizer.Service.SynchronizerService - VCSS006F Failed to start CyberArk Vault-Conjur Synchronizer Service: CASVM035E Vault name is missing.

Da una ricerca nella documentazione si trovava l'errore della componente CASOS però riferita al Vault server e come internal error suggerisce di contattare il supporto.

Nel caso del Synchronizer, ho risolto valorizzando, all'interno del file

C:\Program Files\CyberArk\Synchronizer\VaultConjurSynchronizer.exe.config

il valore di INTEGRATION_VAULT_NAME. con il nome del vault present all'interno del vault.ini .

una volta valorizzato il servizio è partito correttamente.

CyberArk Impact 2022 world tour, io ci sarò e tu?

Come probabilmente già sapete CyberArk ha un grande evento annuale chiamato Impact, che quest'anno è stato organizzato a Boston.

Durante le scorse settimane CyberArk ha annunciato una importante iniziativa, chiamata Impact world tour che porterà la conferenza, in diverse città, in tutto il mondo!

Se siete interessanti, in questa pagina potete trovare:

• elenco delle città e delle date
• agenda
• registration form

Io sarò presente alla data di Milano 11 Ottobre 2022.

Sono contento dell'opportunità di poter incontrare le persone di CyberArk di persona e di poter assistere ad interessanti sessioni dal vivo: a presto ! 

CyberArk Conjur , authenticators e integrazioni

Nei precedenti blogpost vi ho parlato di cosa è un secrets manager (e del motivo per cui  dovreste averne la necessità) ed ho fatto una overview dell'architettura di Conjur e dei suoi system requirements.

Un secrets manager non può fare il suo lavoro se non può parlare con chi ha bisogno di chiedergli i segreti ed è qui che arriva la "magia" di Conjur, gli "authenticator" a cui Conjur demanda le sue funzionalità di autenticazione. 

Questa che vi metto qui sotto  la lista "grezza" degli authenticators disponibili:

authn	Defines the Conjur default authenticator. Authentication for both users and hosts is based on an ID and API key.
authn-oidc	Leverages the identity layer provided by OIDC to allow applications to authenticate with Conjur and retrieve secrets needed for connecting to services such as a database.
authn-iam	Enables an AWS resource to use its AWS IAM role to authenticate with Conjur.
authn-azure	Enables an Azure resource to authenticate with Conjur
authn-jwt	Enables an application to authenticate to Conjur using a JWT from a JWT Provider.
authn-gcp	Enables a Google Cloud Platform resource to authenticate with Conjur
authn-k8s	Authenticates hosts that are Kubernetes resources, such as a Kubernetes namespace, deployment, stateful set, and others. Authentication is certificate-based using a mutual TLS connection.
authn-ldap	Authenticates users based on an LDAP directory.

come si può intuire Conjur è integrabile nativamente con molte delle tecnologie moderne che potete utilizzare a vostro piacimento , per gestirne i secrets in modo sicuro!

Di default dopo l'installazione di Conjur, l'unico authenticator attivo è authn che è in grado di fornire accesso a Conjur ed ai suoi secrets tramite username o API key (generate random fra i 51 e 56 caratteri). 

Se però ad esempio dovete però fornire accesso ad applicazioni che risiedono su un cluster Kubernetes attivando authn-k8s potete farlo in modo sicuro tramite una connessione sicura stabilita in mTLS , utilizzando Spiffie secondo lo schema sottostante (qui per approfondire) :

analogamente a quanto fatto per Kubernetes se poi doveste aver la necessità di integrare un identità di qualunque tipo ( ad esempio Google Apigee ) potete ricorrere all'authenticator authn-jwt che lavora come descritto qui secondo lo schema sottostante: 

Come potete capire dalla lista sopra degli authenticator , le possibilità che ha Conjur di servire la vostra applicazione o meglio identità verificata in modo sicuro coprono praticamente la totalità dei casi possibili.

Quindi se  dovete quindi fornire secrets in una o più dei seguenti esempi 

• Kubernetes (locali o cloud) 
• API gateway
• Jenkins
• Ansible
• Puppet
• Terraform
• Cloud services

in modo sicuro e nativo non potete che considerare Conjur rivolgendovi a CyberArk o al vostro partner CyberArk di riferimento.