Skip to main content
La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

Configurare la crittografia backend dello storage

Collaboratori

Con Astra Control Provivisioner, puoi migliorare la sicurezza dell'accesso ai dati abilitando la crittografia per il traffico tra il cluster gestito e il backend dello storage.

Astra Control Provivisioner supporta la crittografia Kerberos per due tipi di backend di storage:

  • On-premise ONTAP - Astra Control Provisioner supporta la crittografia Kerberos su connessioni NFSv3 e NFSv4 da Red Hat OpenShift e dai cluster Kubernetes upstream ai volumi ONTAP on-premise.

  • Azure NetApp Files - Astra Control Provisioner supporta la crittografia Kerberos su connessioni NFSv4,1 da cluster Kubernetes upstream a volumi Azure NetApp Files.

Puoi creare, eliminare, ridimensionare, creare snapshot, clonare clone di sola lettura e importare i volumi che utilizzano la crittografia NFS.

Configura la crittografia Kerberos in-flight con i volumi ONTAP on-premise

Puoi attivare la crittografia Kerberos sul traffico storage tra il cluster gestito e un backend dello storage ONTAP on-premise.

Nota La crittografia Kerberos per il traffico NFS con backend di storage ONTAP on-premise è supportata solo utilizzando ontap-nas driver di storage.
Prima di iniziare

  • Assicurarsi di avere "Abilitato Astra Control Provisioner" nel cluster gestito.

  • Assicurarsi di avere accesso a. tridentctl utility.

  • Assicurarsi di disporre dell'accesso come amministratore al back-end dello storage ONTAP.

  • Accertatevi di conoscere il nome del volume o dei volumi che condividerete dal back-end dello storage ONTAP.

  • Verificare di aver preparato la VM di storage ONTAP per supportare la crittografia Kerberos per i volumi NFS. Fare riferimento a. "Attivare Kerberos su una LIF dati" per istruzioni.

  • Verificare che tutti i volumi NFSv4 utilizzati con la crittografia Kerberos siano configurati correttamente. Consultare la sezione Configurazione di dominio NetApp NFSv4 (pagina 13) della "Guida ai miglioramenti e alle Best practice di NetApp NFSv4".

Aggiungere o modificare criteri di esportazione ONTAP

Devi aggiungere regole alle policy di esportazione ONTAP esistenti o creare nuove policy di esportazione che supportino la crittografia Kerberos per il volume root delle macchine virtuali di storage ONTAP, oltre a qualsiasi volume ONTAP condiviso con il cluster Kubernetes upstream. Le regole dei criteri di esportazione aggiunte o i nuovi criteri di esportazione creati devono supportare i seguenti protocolli di accesso e autorizzazioni di accesso:

Protocolli di accesso

Configura la policy di esportazione con i protocolli di accesso NFS, NFSv3 e NFSv4.

Dettagli di accesso

È possibile configurare una delle tre diverse versioni della crittografia Kerberos, a seconda delle esigenze del volume:

  • Kerberos 5 - (autenticazione e crittografia)

  • Kerberos 5i - (autenticazione e crittografia con protezione dell'identità)

  • Kerberos 5p - (autenticazione e crittografia con protezione di identità e privacy)

Configurare la regola dei criteri di esportazione ONTAP con le autorizzazioni di accesso appropriate. Ad esempio, se i cluster montano i volumi NFS con una combinazione di crittografia Kerberos 5i e Kerberos 5p, utilizza le seguenti impostazioni di accesso:

Tipo Accesso in sola lettura Accesso in lettura/scrittura Accesso superutente

UNIX

Attivato

Attivato

Attivato

Kerberos 5i

Attivato

Attivato

Attivato

Kerberos 5p

Attivato

Attivato

Attivato

Per informazioni su come creare policy di esportazione e regole delle policy di esportazione di ONTAP, consulta la seguente documentazione:

Creazione di un backend dello storage

Puoi creare una configurazione backend dello storage Astra Control Provivisioner che include funzionalità di crittografia Kerberos.

A proposito di questa attività

Quando si crea un file di configurazione backend di archiviazione che configura la crittografia Kerberos, è possibile specificare una delle tre versioni diverse della crittografia Kerberos utilizzando spec.nfsMountOptions parametro:

  • spec.nfsMountOptions: sec=krb5 (autenticazione e crittografia)

  • spec.nfsMountOptions: sec=krb5i (autenticazione e crittografia con protezione dell'identità)

  • spec.nfsMountOptions: sec=krb5p (autenticazione e crittografia con protezione di identità e privacy)

Specificare un solo livello Kerberos. Se si specificano più livelli di crittografia Kerberos nell'elenco dei parametri, viene utilizzata solo la prima opzione.

Fasi

  1. Nel cluster gestito, creare un file di configurazione backend dello storage utilizzando l'esempio seguente. Sostituire i valori tra parentesi <> con le informazioni dell'ambiente:

    apiVersion: v1
kind: Secret
metadata:
  name: backend-ontap-nas-secret
type: Opaque
stringData:
  clientID: <CLIENT_ID>
  clientSecret: <CLIENT_SECRET>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: backend-ontap-nas
spec:
  version: 1
  storageDriverName: "ontap-nas"
  managementLIF: <STORAGE_VM_MGMT_LIF_IP_ADDRESS>
  dataLIF: <PROTOCOL_LIF_FQDN_OR_IP_ADDRESS>
  svm: <STORAGE_VM_NAME>
  username: <STORAGE_VM_USERNAME_CREDENTIAL>
  password: <STORAGE_VM_PASSWORD_CREDENTIAL>
  nasType: nfs
  nfsMountOptions: ["sec=krb5i"] #can be krb5, krb5i, or krb5p
  qtreesPerFlexvol:
  credentials:
    name: backend-ontap-nas-secret

  2. Utilizzare il file di configurazione creato nel passaggio precedente per creare il backend:

    tridentctl create backend -f <backend-configuration-file>

    Se la creazione del backend non riesce, si è verificato un errore nella configurazione del backend. È possibile visualizzare i log per determinare la causa eseguendo il seguente comando:

    tridentctl logs

    Dopo aver identificato e corretto il problema con il file di configurazione, è possibile eseguire nuovamente il comando create.

Creare una classe di storage

È possibile creare una classe di archiviazione per il provisioning dei volumi con la crittografia Kerberos.

A proposito di questa attività

Quando si crea un oggetto classe di archiviazione, è possibile specificare una delle tre versioni diverse della crittografia Kerberos utilizzando mountOptions parametro:

  • mountOptions: sec=krb5 (autenticazione e crittografia)

  • mountOptions: sec=krb5i (autenticazione e crittografia con protezione dell'identità)

  • mountOptions: sec=krb5p (autenticazione e crittografia con protezione di identità e privacy)

Specificare un solo livello Kerberos. Se si specificano più livelli di crittografia Kerberos nell'elenco dei parametri, viene utilizzata solo la prima opzione. Se il livello di crittografia specificato nella configurazione backend di archiviazione è diverso dal livello specificato nell'oggetto della classe di archiviazione, l'oggetto della classe di archiviazione ha la precedenza.

Fasi

  1. Creare un oggetto Kubernetes StorageClass, usando il seguente esempio:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ontap-nas-sc
provisioner: csi.trident.netapp.io
mountOptions: ["sec=krb5i"] #can be krb5, krb5i, or krb5p
parameters:
  backendType: "ontap-nas"
  storagePools: "ontapnas_pool"
  trident.netapp.io/nasType: "nfs"
allowVolumeExpansion: True

  2. Creare la classe di storage:

    kubectl create -f sample-input/storage-class-ontap-nas-sc.yaml

  3. Assicurarsi che la classe di archiviazione sia stata creata:

    kubectl get sc ontap-nas-sc

    L'output dovrebbe essere simile a quanto segue:

    NAME            PROVISIONER             AGE
ontap-nas-sc    csi.trident.netapp.io   15h

Provisioning dei volumi

Dopo aver creato un backend di storage e una classe di storage, è ora possibile eseguire il provisioning di un volume. Fare riferimento a queste istruzioni per "provisioning di un volume".

Configurare la crittografia Kerberos in-flight con i volumi Azure NetApp Files

È possibile attivare la crittografia Kerberos sul traffico di storage tra il cluster gestito e un singolo backend di storage Azure NetApp Files o un pool virtuale di backend di storage Azure NetApp Files.

Prima di iniziare

  • Assicurati di aver abilitato Astra Control Provivisioner sul cluster Red Hat OpenShift gestito. Fare riferimento a. "Abilita Astra Control Provisioner" per istruzioni.

  • Assicurarsi di avere accesso a. tridentctl utility.

  • Assicurarsi di aver preparato il backend dello storage Azure NetApp Files per la crittografia Kerberos annotando i requisiti e seguendo le istruzioni in "Documentazione Azure NetApp Files".

  • Verificare che tutti i volumi NFSv4 utilizzati con la crittografia Kerberos siano configurati correttamente. Consultare la sezione Configurazione di dominio NetApp NFSv4 (pagina 13) della "Guida ai miglioramenti e alle Best practice di NetApp NFSv4".

Creazione di un backend dello storage

È possibile creare una configurazione backend dello storage Azure NetApp Files che include la funzionalità di crittografia Kerberos.

A proposito di questa attività

Quando si crea un file di configurazione backend dello storage che configura la crittografia Kerberos, è possibile definirlo in modo che venga applicato a uno dei due livelli possibili:

  • Il livello backend di archiviazione utilizzando spec.kerberos campo

  • Il livello pool virtuale utilizzando spec.storage.kerberos campo

Quando si definisce la configurazione a livello del pool virtuale, il pool viene selezionato utilizzando l'etichetta nella classe di archiviazione.

In entrambi i livelli, è possibile specificare una delle tre diverse versioni della crittografia Kerberos:

  • kerberos: sec=krb5 (autenticazione e crittografia)

  • kerberos: sec=krb5i (autenticazione e crittografia con protezione dell'identità)

  • kerberos: sec=krb5p (autenticazione e crittografia con protezione di identità e privacy)

Fasi

  1. Nel cluster gestito, creare un file di configurazione backend dello storage utilizzando uno dei seguenti esempi, a seconda del punto in cui occorre definire il backend dello storage (livello di backend dello storage o livello del pool virtuale). Sostituire i valori tra parentesi <> con le informazioni dell'ambiente:

    Esempio di livello di backend di archiviazione
    apiVersion: v1
kind: Secret
metadata:
  name: backend-tbc-anf-secret
type: Opaque
stringData:
  clientID: <CLIENT_ID>
  clientSecret: <CLIENT_SECRET>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: backend-tbc-anf
spec:
  version: 1
  storageDriverName: azure-netapp-files
  subscriptionID: <SUBSCRIPTION_ID>
  tenantID: <TENANT_ID>
  location: <AZURE_REGION_LOCATION>
  serviceLevel: Standard
  networkFeatures: Standard
  capacityPools: <CAPACITY_POOL>
  resourceGroups: <RESOURCE_GROUP>
  netappAccounts: <NETAPP_ACCOUNT>
  virtualNetwork: <VIRTUAL_NETWORK>
  subnet: <SUBNET>
  nasType: nfs
  kerberos: sec=krb5i #can be krb5, krb5i, or krb5p
  credentials:
    name: backend-tbc-anf-secret
    Esempio di livello del pool virtuale
    apiVersion: v1
kind: Secret
metadata:
  name: backend-tbc-anf-secret
type: Opaque
stringData:
  clientID: <CLIENT_ID>
  clientSecret: <CLIENT_SECRET>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: backend-tbc-anf
spec:
  version: 1
  storageDriverName: azure-netapp-files
  subscriptionID: <SUBSCRIPTION_ID>
  tenantID: <TENANT_ID>
  location: <AZURE_REGION_LOCATION>
  serviceLevel: Standard
  networkFeatures: Standard
  capacityPools: <CAPACITY_POOL>
  resourceGroups: <RESOURCE_GROUP>
  netappAccounts: <NETAPP_ACCOUNT>
  virtualNetwork: <VIRTUAL_NETWORK>
  subnet: <SUBNET>
  nasType: nfs
  storage:
    - labels:
        type: encryption
      kerberos: sec=krb5i #can be krb5, krb5i, or krb5p
  credentials:
    name: backend-tbc-anf-secret

  2. Utilizzare il file di configurazione creato nel passaggio precedente per creare il backend:

    tridentctl create backend -f <backend-configuration-file>

    Se la creazione del backend non riesce, si è verificato un errore nella configurazione del backend. È possibile visualizzare i log per determinare la causa eseguendo il seguente comando:

    tridentctl logs

    Dopo aver identificato e corretto il problema con il file di configurazione, è possibile eseguire nuovamente il comando create.

Creare una classe di storage

È possibile creare una classe di archiviazione per il provisioning dei volumi con la crittografia Kerberos.

Fasi

  1. Creare un oggetto Kubernetes StorageClass, usando il seguente esempio:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: anf-sc-nfs
provisioner: csi.trident.netapp.io
parameters:
  backendType: "azure-netapp-files"
  trident.netapp.io/nasType: "nfs"
  selector: "type=encryption"

  2. Creare la classe di storage:

    kubectl create -f sample-input/storage-class-anf-sc-nfs.yaml

  3. Assicurarsi che la classe di archiviazione sia stata creata:

    kubectl get sc anf-sc-nfs

    L'output dovrebbe essere simile a quanto segue:

    NAME         PROVISIONER             AGE
anf-sc-nfs    csi.trident.netapp.io   15h

Provisioning dei volumi

Dopo aver creato un backend di storage e una classe di storage, è ora possibile eseguire il provisioning di un volume. Fare riferimento a queste istruzioni per "provisioning di un volume".