Progetti Kubernetes

Un progetto Kubernetes è un insieme di immagini Docker appartenenti a un namespace su un cluster Kubernetes, considerato nel suo complesso come un unico asset che aggrega le vulnerabilità delle immagini che lo compongono. Ogni immagine è considerata come una tecnologia del progetto, il che consente di conoscere le immagini vulnerabili senza doverne esaminare il contenuto.

Creazione di un progetto Kubernetes

I progetti Kubernetes sono un tipo di connessione agentless. I dati da inserire dipendono dal modo in cui ci si connette al cluster. È sempre possibile connettersi a un cluster passando direttamente dall’API di Kubernetes, ma per facilitare la gestione delle credenziali, Cyberwatch può recuperare automaticamente le configurazioni Kubernetes da Azure o AWS.

Cluster Kubernetes

Per accedere direttamente a un cluster Kubernetes, è necessario innanzitutto creare per esso un set di credenziali salvate di tipo Kubernetes. Le credenziali create devono disporre delle autorizzazioni RBAC seguenti:

- apiGroups: [""]
  resources: ["namespaces/status", "pods/status"]
  verbs: ["list", "get"]
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["list"]

Consultare la documentazione Kubernetes Using RBAC Authorization per ulteriori informazioni.

Il cluster sarà quindi selezionabile durante la creazione del progetto Kubernetes.

Il campo Indirizzo del progetto deve contenere il nome del namespace da cui elencare le immagini, ad esempio «mio namespace». Nel caso in cui altri cluster definiscano lo stesso namespace, è possibile anteporvi un nome arbitrario di cluster separato da una barra, ad esempio «mio cluster/mio namespace». Il nome del cluster così aggiunto non ha alcun impatto sul risultato della scansione.

Azure Kubernetes Service

Per configurare un cluster AKS, è necessaria una chiave API Azure. La procedura di aggiunta delle credenziali salvate Azure è la stessa delle discovery Azure.

Per identificare un cluster AKS, sono necessarie 3 informazioni:

1. l’ID della sottoscrizione a cui è collegato
2. il nome del relativo gruppo di risorse, se necessario
3. il nome del cluster

Nella pagina di creazione della connessione agentless, selezionando il tipo progetto Kubernetes e il set di credenziali Azure vengono visualizzati i campi specifici di Azure.

Il nome del cluster non dispone di un campo proprio e deve essere scritto nell’indirizzo, seguito da una barra e poi dal nome del namespace del progetto, ad esempio «mio cluster/mio namespace».

Amazon Elastic Kubernetes Service

Per configurare un cluster EKS, è necessaria una chiave API AWS. I passaggi di configurazione sono gli stessi delle discovery Amazon EC2.

Alla creazione della connessione agentless di tipo progetto Kubernetes, il campo Indirizzo deve avere il formato «mio cluster/mio namespace», dove «mio cluster» indica il nome del cluster su AWS e «mio namespace» indica il nome del namespace sul cluster Kubernetes.

Oltre all’indirizzo, è necessario inserire nel campo Regione anche la zona geografica del cluster. Il campo Ruolo consente facoltativamente di inserire un ARN su cui eseguire l’operazione AssumeRole, se necessario.

Rancher

Per configurare un cluster Kubernetes gestito da Rancher, è necessaria una chiave API sotto forma di token Bearer. I prerequisiti sono gli stessi delle discovery Rancher.

Il campo Indirizzo deve avere il formato «mio cluster/mio namespace», dove «mio cluster» indica l’ID del cluster gestito da Rancher (non utilizzare il nome del cluster) e «mio namespace» indica il nome del namespace sul cluster Kubernetes.

Scansione delle immagini

Per ottenere le informazioni sulle vulnerabilità, le immagini dei progetti Kubernetes devono essere scansionate come immagini Docker registrate in modo indipendente.

I progetti Kubernetes riportano le proprie immagini per digest, che funge da chiave per ritrovare le immagini scansionate. Queste ultime devono contenere un metadato IMAGE_DIGEST, dichiarato nel formato META:IMAGE_DIGEST|sha256:… in una delle loro analisi. Poiché lo SHA-256 è l’unico criterio, l’immagine trovata può essere sia un asset air gap sia un’immagine Docker, può provenire da un registry mirror o persino avere un nome diverso. Per una maggiore affidabilità, è preferibile registrare le immagini per digest anziché per tag.

Per tenere conto delle nuove immagini Docker, il progetto Kubernetes deve essere analizzato nuovamente.

Registrazione manuale

Le immagini mancanti di un progetto Kubernetes possono essere aggiunte manualmente per digest dal menu Gestione degli asset > Immagini Docker della barra laterale, specificando nel campo Tag una versione nel formato sha256:50d858e0985ecc7f60418aaf0cc5ab587f42c2570a884095a9e8ccacd0f6545c, ad esempio.

Per facilitare la registrazione manuale, è inoltre possibile aprire la scheda Tecnologie della pagina di dettagli del progetto Kubernetes e cliccare sull’icona di aggiunta a destra di ogni immagine Docker mancante.

Registrazione automatica

L’approccio più semplice per scansionare tutte le immagini Docker di un progetto Kubernetes consiste nel registrarle automaticamente tramite una discovery Docker, e più precisamente una discovery Kubernetes, AKS o EKS il cui perimetro è impostato su Immagini in esecuzione.

Nel caso in cui le immagini provengano da un registry Harbor, è possibile configurare dall’amministrazione, tra gli strumenti esterni, uno scanner Harbor. Questo approccio ha il vantaggio di far scansionare immediatamente le nuove immagini Docker.

Discovery dei progetti

Le discovery Docker per Kubernetes, AKS ed EKS propongono come Perimetro l’opzione Namespace. Questa opzione consente di elencare i namespace presenti sui pod anziché elencarne le immagini.

I progetti così individuati possono essere aggiunti manualmente come asset dall’elenco degli asset individuati utilizzando l’azione in blocco Scansiona con connessioni agentless, quindi selezionando come tipo Progetto Kubernetes.

La registrazione dei nuovi progetti Kubernetes può essere automatizzata dal modulo di modifica della discovery attivando la registrazione automatica come connessioni agentless di tipo Progetto Kubernetes.