venerdì 30 settembre 2022

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.

mercoledì 21 settembre 2022

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 ! 

venerdì 5 agosto 2022

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:

authnDefines the Conjur default authenticator. Authentication for both users and hosts is based on an ID and API key. 
authn-oidcLeverages 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-iamEnables 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-k8sAuthenticates 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-ldapAuthenticates 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.

domenica 24 luglio 2022

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

martedì 19 luglio 2022

CyberArk Conjur , alcuni motivi per cui un enterprise secrets manager deve essere adottato

Quando ci si occupa di security , uno dei temi che non si possono ignorare è la gestione dei secrets , tema che può impattare a 360° il destino di un azienda.

Per secrets ad esempio possiamo considerare ad esempio:

  • username
  • database passwords
  • SSL certificates e keys
  • SSH Keys
  • credenziali cloud

potete capire quindi che la gestione di questi dati diventa fondamentale per salvaguardare sicurezza , funzionamento e reputazione.

Alcuni dei problemi di gestione più diffusi dei secrets includono :
  • hardcoded secrets nel codice
  • data-breach
  • password leak
  • secrets presenti in repository pubblici
un secrets non gestito in modo corretto grazie a fenomeni come lateral movement, può portare a danni importanti.
 

Per poter gestire al meglio i secrets è necessario rivolgersi ad un secrets manager ed una delle possibili soluzioni è CyberArk Conjur.

Conjur , grazie ad un set di API rest è programmabile ed accessible tramite URL.
La sicurezza garantita da policy, rende disponibile l'accesso ai secrets in modo rapido e semplice per i developers, senza renderli partecipi in modo diretto del valore dei secrets coinvolti nel loro codice.

La sicurezza aziendale può essere migliorata tramite la rotazione automatica dei secrets utilizzando i rotators, ed ovviamente si integra alla perfezione con gli altri componenti dell'ecosistema di Cyberark come il Pas Vault, rendendo la sicurezza garantita da Cyberark  anche al mondo Cloud Native.

Conjur è disponibile in 2 versioni, una enterprise ed una opensource che si differenziano in alcune funzionalità

Questo post vuole essere una introduzione al tema e nei prossimi post vi parlerò di requisiti, architettura (semplice e veloce grazie al rilascio sw come container images) e sulle modalità di accesso ai secrets.
 


mercoledì 25 maggio 2022

Un nuovo viaggio è iniziato.. aggiornamento professionale e cambio focus per il blog

Scrivo un alcune di righe per riportare anche qui un importante aggiornamento professionale che riguarda futuro di questo blog: come forse avrete visto su LinkedIn o Twitter , dal 16 Maggio 2022 ho dato una svolta alla mia carriera cambiando società e ruolo, ora lavoro come Senior DevOps Engineer presso Sighup .


Questo cambiamento di ruolo, obbiettivi , tecnologie e responsabilità avrà come riflesso il cambio dei contenuti di questo blog verso temi differenti a partire da CyberArk Conjur fino ad altri prodotti successivi di cui scriverò nel prossimo futuro.


I contenuti precedenti a questo post del blog rimarranno li dove sono ora , visto che saranno utili per parecchio tempo ed ho intenzione di onorare il mio ruolo di HCL Ambassador. 

Aggiungo che in  questo momento il mio ruolo di membro organizzatore dello usergroup Let'sConnect rimane immutato, spero quindi vivamente di essere in grado di incontrarvi nuovamente al prossimo evento.



Un grande abbraccio alla mia precedente community e audience e un grande benveuto ai futuri lettori ed alla futura community.



giovedì 28 aprile 2022

HCL Connections 7.0 , come risolvere errori db su Wikis , Files e Metrics durante migrazione side by side con dbt.jar

Durante questi giorni sono impegnato in una migrazione side by side da Connections 6.0 a 7.0.

La migrazione dei database preferisco farla con il tool dbt.jar che copia le tabelle dei dati da vecchio a nuovo per una serie di ragioni , fra cui :

  1. tipicamente la faccio nel primo giro di test mentre gli utenti lavorano , senza problemi
  2. mi aiuta a capire e fixare eventuali problemi sulle tabelle dei dati
In questa situazione ho trovato problemi su Wikis, Files e Metrics.

Wikis e Files
In questo caso i DB di Wikis e Files non venivano migrati in modo corretto , andavano in errore su una tabella con questo errore:

ERROR: Error occurred gathering data from the source database
com.ibm.db2.jcc.am.SqlSyntaxErrorException: DB2 SQL Error: SQLCODE=-551, SQLSTATE=42501, SQLERRMC=LCUSER;SELECT;FILES.EVENT_STORE, DRIVER=4.29.24

dopo alcune verifiche mi sono reso conto che le tabelle in questa condizione erano 3 per entrambi i db

EVENT_PROCESSING
EVENT_STORE
FILE_LOCATION

L'errore SQL è di mancato accesso ed in effetti LCUSER non poteva leggere le 3 tabelle , nè sul produzione attuale sorgente nè sul destinazione.

Dopo una verifica sugli script ho verificato che queste tabelle venivano aggiunte nel CR5 di Connections 6.0 e quindi non erano presenti negli appGrants.sql inclusi di default ( ed i dev si sono dimenticati di mettere le grant negli script di creazione ... ) .

Ho proceduto quindi ad inserirle a mano , sia su sorgente che su destinazione ( essendo poi presenti negli appGrants.sql della versione 7.0 )

GRANT DELETE,INSERT,SELECT,UPDATE ON "FILES"."EVENT_STORE" TO USER [email protected]
GRANT DELETE,INSERT,SELECT,UPDATE ON "FILES"."EVENT_PROCESSING" TO USER [email protected]
GRANT DELETE,INSERT,SELECT,UPDATE ON "FILES"."FILE_LOCATION" TO USER [email protected]



GRANT DELETE,INSERT,SELECT,UPDATE ON "WIKIS"."EVENT_STORE" TO USER [email protected]
GRANT DELETE,INSERT,SELECT,UPDATE ON "WIKIS"."EVENT_PROCESSING" TO USER [email protected]
GRANT DELETE,INSERT,SELECT,UPDATE ON "WIKIS"."FILE_LOCATION" TO USER [email protected]


Metrics
Il problema di metrics era differente, con questo errore:

com.ibm.db2.jcc.am.SqlTransactionRollbackException: Error for batch element #1: DB2 SQL Error: SQLCODE=-1476, SQLSTATE=40506, SQLERRMC=-964, DRIVER=4.29.24 ERRORCODE=-4225, SQLSTATE=null mber of the batch..755 CEST] error.executing.transfer Use getNextException() to retrieve the exceptions for specific batched elements. ERRORCODE=-4229, SQLSTATE=null com.ibm.db2.jcc.am.BatchUpdateException: [jcc][t4][102][10040][4.29.24] Batch failure. The batch was submitted, but at least one exception occurred on an individual member of the batch. Use getNextException() to retrieve the exceptions for specific batched elements. ERRORCODE=-4229, SQLSTATE=null

ERRORCODE=-4229 è un errore generico che necessita di debug, da un po' di indagini nel db2diag.log dell'instanza di destinazione , ho verificato questi errori durante la migrazione dei dati del db:


FUNCTION: DB2 UDB, data protection services, sqlpgResSpace, probe:1660 MESSAGE : ADM1822W The active transaction log is being held by dirty pages. Database performance may be impacted. MESSAGE : ZRC=0x870F0035=-2029060043=SQLO_NOTAVAIL "Cannot honor the conditional request" DIA8531C A memory access error has occurred. MESSAGE : ZRC=0x85100009=-2062548983=SQLP_NOSPACE "Log File has reached its saturation point" DIA8309C Log file was full.

questi errori relativi ai log del db che si riempivano mi hanno fatto pensare, dopo aver ricreato il db di destinazione alla seguente soluzione:

db2 update db cfg for METRICS using logfilsiz 16000 logprimary 26 logsecond 6

con questo settaggio , la copia dati è terminata in modo corretto.