Sicurezza
Utilizza i consigli elencati di seguito per assicurarti che l'installazione di Astra Trident sia sicura.
Eseguire Astra Trident nel proprio namespace
È importante impedire ad applicazioni, amministratori di applicazioni, utenti e applicazioni di gestione di accedere alle definizioni degli oggetti di Astra Trident o ai pod per garantire uno storage affidabile e bloccare potenziali attività dannose.
Per separare le altre applicazioni e gli utenti da Astra Trident, installare sempre Astra Trident nel proprio spazio dei nomi Kubernetes (trident
). L'inserimento di Astra Trident nel proprio spazio dei nomi garantisce che solo il personale amministrativo di Kubernetes abbia accesso al pod Astra Trident e agli artefatti (come i segreti di backend e CHAP, se applicabili) memorizzati negli oggetti CRD con spazio dei nomi. È necessario garantire che solo gli amministratori possano accedere allo spazio dei nomi Astra Trident e quindi a. tridentctl
applicazione.
Utilizza l'autenticazione CHAP con i backend SAN ONTAP
Astra Trident supporta l'autenticazione basata su CHAP per i carichi di lavoro SAN ONTAP (utilizzando il ontap-san
e. ontap-san-economy
driver). NetApp consiglia di utilizzare CHAP bidirezionale con Astra Trident per l'autenticazione tra un host e il backend dello storage.
Per i backend ONTAP che utilizzano i driver di storage SAN, Astra Trident può configurare CHAP bidirezionale e gestire i nomi utente e i segreti CHAP attraverso tridentctl
. Vedere "qui" Per capire come Astra Trident configura CHAP sui backend ONTAP.
|
Il supporto CHAP per i backend ONTAP è disponibile con Trident 20.04 e versioni successive. |
Utilizza l'autenticazione CHAP con backend NetApp HCI e SolidFire
NetApp consiglia di implementare CHAP bidirezionale per garantire l'autenticazione tra un host e i backend NetApp HCI e SolidFire. Astra Trident utilizza un oggetto segreto che include due password CHAP per tenant. Quando Trident viene installato come provider CSI, gestisce i segreti CHAP e li memorizza in un tridentvolume
Oggetto CR per il rispettivo PV. Quando si crea un PV, CSI Astra Trident utilizza i segreti CHAP per avviare una sessione iSCSI e comunicare con il sistema NetApp HCI e SolidFire su CHAP.
|
I volumi creati da CSI Trident non sono associati a alcun gruppo di accesso al volume. |
Nel frontend non CSI, l'attacco di volumi come dispositivi sui nodi di lavoro viene gestito da Kubernetes. Dopo la creazione del volume, Astra Trident effettua una chiamata API al sistema NetApp HCI/SolidFire per recuperare i segreti se il segreto per quel tenant non esiste già. Astra Trident poi passa i segreti su Kubernetes. Il kubelet situato su ciascun nodo accede ai segreti tramite l'API Kubernetes e li utilizza per eseguire/abilitare CHAP tra ciascun nodo che accede al volume e il sistema NetApp HCI/SolidFire in cui si trovano i volumi.
Utilizzare Astra Trident con NVE e NAE
NetApp ONTAP offre la crittografia dei dati inattivi per proteggere i dati sensibili in caso di furto, restituzione o riordinamento di un disco. Per ulteriori informazioni, fare riferimento a. "Panoramica sulla configurazione di NetApp Volume Encryption".
-
Se NAE è attivato sul backend, qualsiasi volume fornito in Astra Trident sarà abilitato per NAE.
-
Se NAE non è attivato sul backend, qualsiasi volume fornito in Astra Trident sarà abilitato per NVE, a meno che non si imposta il flag di crittografia NVE su
false
nella configurazione back-end.
|
I volumi creati in Astra Trident su un backend abilitato NAE devono essere crittografati con NVE o NAE.
|
-
È possibile creare manualmente un volume NVE in Astra Trident impostando esplicitamente il flag di crittografia NVE su
true
.
Per ulteriori informazioni sulle opzioni di configurazione del backend, fare riferimento a:
Abilitare la crittografia lato host per volume utilizzando Linux Unified Key Setup (LUKS)
È possibile abilitare la configurazione delle chiavi unificate Linux (LUKS) per crittografare i volumi SAN ONTAP e SAN ONTAP SU Astra Trident. In Astra Trident, i volumi con crittografia LUKS utilizzano il cifrario aes-xts-plain64 e la modalità, come consigliato da "NIST".
Per ulteriori informazioni sulle opzioni di configurazione back-end per ONTAP SAN, fare riferimento a. "Opzioni di configurazione SAN ONTAP"
-
Sui nodi di lavoro deve essere installata la versione 2.1 o superiore di cryptsetup. Per ulteriori informazioni, visitare il sito "Gitlab: Crittsetup".
-
Per motivi di performance, consigliamo ai nodi di lavoro di supportare Advanced Encryption Standard New Instructions (AES-NI). Per verificare il supporto AES-NI, eseguire il seguente comando:
grep "aes" /proc/cpuinfo
Se non viene restituito nulla, il processore non supporta AES-NI. Per ulteriori informazioni su AES-NI, visita: "Intel: Advanced Encryption Standard Instructions (AES-NI)".
-
Definire gli attributi di crittografia LUKS nella configurazione del back-end.
"storage": [ { "labels":{"luks": "true"}, "zone":"us_east_1a", "defaults": { "luksEncryption": "true" } }, { "labels":{"luks": "false"}, "zone":"us_east_1a", "defaults": { "luksEncryption": "false" } }, ]
-
Utilizzare
parameters.selector
Per definire i pool di storage utilizzando la crittografia LUKS. Ad esempio:apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: luks provisioner: netapp.io/trident parameters: selector: "luks=true" csi.storage.k8s.io/node-stage-secret-name: luks-${pvc.name} csi.storage.k8s.io/node-stage-secret-namespace: ${pvc.namespace}
-
Creare un Secret contenente la passphrase LUKS. Ad esempio:
apiVersion: v1 kind: Secret metadata: name: luks-pvc1 stringData: luks-passphrase-name: B luks-passphrase: secretB previous-luks-passphrase-name: A previous-luks-passphrase: secretA
Limitazioni
-
I volumi crittografati LUKS non potranno sfruttare la deduplica e la compressione ONTAP.
-
La rotazione della passphrase LUKS non è attualmente supportata. Per modificare le passphrase, copiare manualmente i dati da un PVC all'altro.