Panoramica sulla crittografia

Virtual Private Cloud Infrastruttura classica Satellite

Proteggete le informazioni sensibili nel vostro cluster Red Hat® OpenShift® on IBM Cloud® per garantire l'integrità dei dati ed evitare che vengano esposti a utenti non autorizzati, impostando un provider di servizi di gestione delle chiavi (KMS).

Red Hat OpenShift on IBM Cloud offre la crittografia a diversi livelli nel tuo cluster. La crittografia di alcuni componenti è gestita da IBM, mentre per altri componenti è possibile inserire le credenziali del proprio provider KMS per gestire autonomamente la crittografia.

La tabella seguente descrive le opzioni di crittografia per Red Hat OpenShift on IBM Cloud grappoli.

Crittografia dei dati predefinita e opzionale
Componente	Crittografato per impostazione predefinita?	Portare il proprio supporto per le chiavi?	Tempo di abilitazione	Provider KMS supportati	Supporto per account incrociati?
Piano di controllo	Sì	No	Durante la creazione del cluster.	IBM gestito Key Protect	N/D
Dischi del nodo di lavoro	Sì	Sì	Durante la creazione del cluster o del pool di lavoro.	Key Protect	Sì
Segreti cluster	No	Sì	Dopo la creazione del cluster utilizzando `kms enable`.	Key Protect	Cross account supportato solo per cluster Classic e VPC.
Archiviazione persistente	Dipende dal provider di storage.	Dipende dal provider	Dopo la creazione del cluster, quando si imposta l'archiviazione.	Key Protect	Dipende dal provider di storage.

Piano di controllo

La crittografia del piano di controllo è gestita da IBM.

I componenti nel master Red Hat OpenShift si avviano su un'unità codificata LUKS utilizzando una chiave gestita da IBM.
Il componente etcd del master memorizza i file di configurazione delle risorse Kubernetes, come le distribuzioni e i segreti.
I dati in etcd sono archiviati sul disco locale del master Kubernetes e ne viene eseguito il backup su IBM Cloud Object Storage.
I dati vengono crittografati durante il transito su IBM Cloud Object Storage e quando inattivi.

Dischi nodo di lavoro

I dischi collegati vengono utilizzati per avviare il tuo nodo di lavoro, ospitare il file system del contenitore e memorizzare le immagini estratte localmente. La codifica e il numero di dischi variano in funzione del provider di infrastrutture.

Esiste una limitazione temporanea quando si utilizza un'istanza single tenant di Key Protect per la crittografia BYOK (Bring Your Own Key) per il disco di avvio dei nodi worker e la crittografia segreta del cluster. Per utilizzare un'istanza di un singolo tenant con il cluster, è necessario assicurarsi che il criterio di autorizzazione da servizio a servizio sia impostato sul livello del servizio o dell'istanza di Key Protect e non su una chiave o un anello di chiavi. Questa limitazione si applica solo alle istanze single tenant di Key Protect.

nodi di lavoro VPC: Per impostazione predefinita, il disco primario dei nodi di lavoro VPC è AES-256 bit crittografato a riposo dal provider dell'infrastruttura VPC sottostante. È possibile gestire la crittografia dei nodi worker abilitando un provider KMS a livello di pool worker. Per ulteriori informazioni, sulla crittografia dei dischi del nodo di lavoro VPC, vedi Configurazione della crittografia del disco del nodo di lavoro per i cluster VPC.
Nodi di lavoro classici: Il disco primario ha le immagini kernel per avviare il tuo nodo di lavoro. Questo disco non è codificato. Il disco secondario contiene il file system del contenitore e le immagini estratte localmente. Questo disco è crittografato AES a 256 bit con una chiave di crittografia LUKS gestita da IBM, unica per il nodo worker e memorizzata come segreto Kubernetes nel cluster. Quando ricarichi o aggiorni i tuoi nodi di lavoro, le chiavi LUKS vengono ruotate.
Satellite nodi di lavoro: La codifica del disco SO e del disco secondario viene gestita al livello IAAS della piattaforma su cui è distribuito Satellite. La codifica dei volumi di archiviazione persistenti utilizzati nel cluster viene gestita a livello del plug-in di archiviazione persistente e a livello del dispositivo di archiviazione di backup. Per ulteriori informazioni sulla codifica per periferiche di archiviazione o plug-in, consultare la documentazione del provider di periferiche o la documentazione del plug-in di archiviazione.

Segreti cluster

I segreti Kubernetes sono codificati base64 per impostazione predefinita. È possibile proteggere ulteriormente i segreti di Kubernetes e le credenziali memorizzate nei segreti abilitando un provider di servizi di gestione delle chiavi (KMS), come IBM® Key Protect for IBM Cloud®.

Quando si abilita un provider KMS (key management service) per il cluster, si porta la propria chiave root. La chiave root viene utilizzata per crittografare le chiavi di crittografia dei dati (DEK) che vengono quindi utilizzate per crittografare i segreti nel tuo cluster. La chiave principale è memorizzata nell'istanza del provider KMS controllata dall'utente. Le DEK codificate sono archiviate in etcd e possono essere decodificate solo utilizzando la chiave root dal provider KMS. Per ulteriori informazioni su come funziona la crittografia delle chiavi, vedi Crittografia envelope.

Esamina le seguenti note sulla crittografia del segreto del cluster.

I segreti cluster vengono crittografati utilizzando il tuo KMS.
I segreti cluster vengono aggiornati automaticamente dopo la rotazione delle chiavi root.
I cluster che utilizzano la chiave root sono visualizzabili dall'interfaccia del provider KMS.
I cluster rispondono automaticamente se si disabilitano, abilitano o ripristinano le chiavi root.
La disabilitazione di una chiave root limita la funzione del cluster fino a quando non si riabilita la chiave.
L'eliminazione di una chiave root rende il cluster inutilizzabile e irrecuperabile.
Puoi avere un solo provider KMS e una chiave abilitati nel cluster alla volta.
È possibile cambiare il provider e la chiave KMS.
Non è possibile disattivare la crittografia del provider KMS.

Per impostare la crittografia segreta del cluster, vedere Configurazione della crittografia segreta del cluster.

Archiviazione persistente

A seconda del tipo di memoria persistente che si utilizza, è possibile codificare i dati scritti nei volumi di archiviazione abilitando un provider KMS. Per ulteriori informazioni sui tipi di crittografia e archiviazione persistente disponibili, vedi Descrizione delle tue opzioni di archiviazione.

Passi successivi

Per continuare il processo di pianificazione, scegliere un'opzione di archiviazione. Se siete pronti a iniziare con la crittografia, passate a creare un'istanza KMS e una chiave principale.