Provisioning dei PVC nel servizio di storage di file

Quando si utilizza il servizio di storage di file per eseguire il provisioning dei PVC, si specifica la cifratura in transito indipendentemente dalla cifratura in archivio.

Il servizio di storage di file cifra sempre i dati in archivio, utilizzando le chiavi di cifratura gestite da Oracle per impostazione predefinita. Tuttavia, hai la possibilità di specificare la cifratura in archivio utilizzando le tue chiavi di cifratura master che gestisci tu stesso nel servizio Vault. Come specificare la crittografia at-rest dipende dal fatto che si stia eseguendo il provisioning di un PVC su:

• un nuovo file system creato dinamicamente dal plugin del volume CSI (vedere Cifratura dei dati in archivio su un nuovo file system)
• un file system esistente creato manualmente (vedere Cifratura dei dati in archivio su un file system esistente)

Se si desidera gestire le proprie chiavi di cifratura master per cifrare i dati in archivio, è necessario effettuare le operazioni riportate di seguito.

• Creare una chiave di cifratura master appropriata nel vault (o ottenere l'OCID di tale chiave). Vedere Gestione delle chiavi.
• Creare un criterio che conceda l'accesso alla chiave di cifratura principale. Vedere Create Policy to Access User-Managed Encryption Keys for Encrypting Boot Volumes, Block Volumes, and/or File Systems.

Il servizio di storage di file può facoltativamente cifrare i dati in transito. Se si specifica la cifratura in transito, i dati in transito vengono cifrati utilizzando un certificato TLS (Transport Layer Security) sempre gestito da Oracle, indipendentemente dal fatto che i dati in archivio siano cifrati utilizzando chiavi gestite da Oracle o utilizzando chiavi gestite dall'utente. La cifratura in transito protegge i dati trasferiti tra le istanze e i file system di cui è stato eseguito il MOUNT utilizzando la cifratura TLS v. 1.2. Per ulteriori informazioni sulla cifratura in transito e sul servizio di storage di file, vedere Using In-transit TLS Encryption. Come specificare la cifratura in transito dipende dal fatto che si stia eseguendo il provisioning di un PVC su:

• un nuovo file system creato dinamicamente dal plugin del volume CSI (vedere Cifratura dei dati in transito in un nuovo file system)
• un file system esistente creato manualmente (vedere Cifratura dei dati in transito su un file system esistente)

Tenere presente che quando si utilizza il servizio di storage di file per eseguire il provisioning dei PVC, la cifratura in transito è supportata solo quando le istanze di computazione che ospitano nodi di lavoro eseguono Oracle Linux 7 e Oracle Linux 8.

Per eseguire il provisioning dinamico di un PVC su un nuovo file system creato dinamicamente dal plugin volume CSI nel servizio di storage di file:

1. (Opzionale) Creare una destinazione di accesso nel servizio di storage di file. Vedere Creating a Mount Target.

   Il plugin del volume CSI richiede una destinazione di accesso attiva (ovvero una destinazione di accesso con un indirizzo IP assegnato) per creare un nuovo file system. Se non si crea una destinazione di accesso in anticipo, specificare la subnet in cui il plugin del volume CSI deve creare una nuova destinazione di accesso quando si definisce la classe di storage.

2. Definire una nuova classe di storage che utilizzi il provisioninger fss.csi.oraclecloud.com:
   1. Creare un file manifesto (ad esempio, in un file denominato fss-dyn-st-class.yaml), specificare un nome per la nuova classe di memorizzazione e specificare i valori per i parametri obbligatori e facoltativi:

      kind: StorageClass
      apiVersion: storage.k8s.io/v1
      metadata:
        name: <storage-class-name>
      provisioner: fss.csi.oraclecloud.com
      parameters:
        availabilityDomain: <ad-name>
        mountTargetOcid: <mt-ocid> | mountTargetSubnetOcid: <mt-subnet-ocid>
        compartmentOcid: <compartment-ocid>
        kmsKeyOcid: <key-ocid>
        exportPath: <path>
        exportOptions: "[{<options-in-json-format>}]"
        encryptInTransit: "true"|"false"
        oci.oraclecloud.com/initial-defined-tags-override: '{"<tag-namespace>": {"<tag-key>": "<tag-value>"}}'
        oci.oraclecloud.com/initial-freeform-tags-override: '{"<tag-key>": "<tag-value>"}'

      Dove:

      • name: <storage-class-name>: obbligatorio. Nome scelto per la classe di memorizzazione.
      • availabilityDomain: <ad-name>: obbligatorio. Il nome del dominio di disponibilità in cui creare il nuovo file system (e in cui creare la nuova destinazione di accesso, se non viene specificato un OCID di destinazione di accesso esistente). Ad esempio, US-ASHBURN-AD-1. Per determinare il nome del dominio di disponibilità da utilizzare, eseguire il comando CLI oci iam availability-domain list oppure utilizzare l'operazione ListAvailabilityDomains. Per ulteriori informazioni, vedere Nomi dei domini di disponibilità della tenancy.
      • mountTargetOcid: <mt-ocid> | mountTargetSubnetOcid: <mt-subnet-ocid>: obbligatorio. L'OCID di una destinazione di accesso attiva esistente (mountTargetOcid: <mt-ocid>) o l'OCID di una subnet in cui creare una nuova destinazione di accesso (mountTargetSubnetOcid: <mt-subnet-ocid>). Specificare mountTargetOcid o mountTargetSubnetOcid. Se si specifica sia mountTargetOcid che mountTargetSubnetOcid nella definizione della classe di memorizzazione, viene utilizzata la destinazione di accesso esistente specificata da mountTargetOcid e mountTargetSubnetOcid viene ignorato. Ad esempio:
        • mountTargetSubnetOcid: ocid1.subnet.oc1.iad.aaaaaaaa2xpk______zva
        • mountTargetOcid: ocid1.mounttarget.oc1.iad.aaaaaaaa4np______fuy
      • compartmentOcid: <compartment-ocid>: facoltativo. L'OCID del compartimento a cui deve appartenere il nuovo file system (e la nuova destinazione di accesso, se non viene specificato un OCID di destinazione di accesso esistente). Se non viene specificato, per impostazione predefinita viene utilizzato lo stesso compartimento del cluster. Ad esempio, compartmentOcid: ocid1.compartment.oc1..aaaaaaaay______t6q
      • kmsKeyOcid: <key-ocid>: facoltativo. OCID di una chiave di cifratura master gestita dall'utente, con la quale cifrare i dati in archivio. Se non viene specificato, i dati vengono cifrati in archivio utilizzando le chiavi di cifratura gestite da Oracle. Vedere Cifratura dei dati in archivio in un nuovo file system. Ad esempio, kmsKeyOcid: ocid1.key.oc1.iad.anntl______usjh
      • exportPath: <path>: facoltativo. Il percorso di un'esportazione che identifica in modo univoco il file system all'interno della destinazione di accesso. Il percorso di esportazione deve iniziare con una barra (/) seguita da una sequenza di zero o più elementi separati da barre. Ad esempio, /FileSystem1. Per ulteriori informazioni, vedere Percorsi nei file system.

        Se si include exportPath: <path> in una definizione di classe di memorizzazione, non specificare un percorso (come percorso o come sottopercorso di un percorso esistente) già esistente. Se si specifica un percorso già esistente, viene restituito un errore perché più file system con la stessa destinazione di accesso non possono avere lo stesso percorso di esportazione. Pertanto, se si include exportPath: <path> nella definizione della classe di memorizzazione, utilizzare questa definizione della classe di memorizzazione solo per creare un file system.

        Se non si include exportPath: <path> nella definizione della classe di memorizzazione, per impostazione predefinita il percorso viene impostato sul nome visualizzato del file system creato dal plugin del volume CSI (a partire da /csi-fss-).

      • exportOptions: "[{<options-in-json-format>}]" Facoltativo. Set di parametri (in formato JSON valido) all'interno dell'esportazione che specifica il livello di accesso concesso ai client NFS quando si connettono a una destinazione di accesso. Una voce delle opzioni di esportazione NFS all'interno di un'esportazione definisce l'accesso per un singolo indirizzo IP o intervallo di blocchi CIDR. Per ulteriori informazioni, vedere Utilizzo delle opzioni di esportazione e di esportazione NFS. Se non viene specificato, viene utilizzato il seguente valore predefinito:

        exportOptions: "[{\"source\":\"0.0.0.0/0\",\"requirePrivilegedSourcePort\":false,\"access\":\"READ_WRITE\",\"identitySquash\":\"NONE\"}]"

      • encryptInTransit: "true"|"false": facoltativo. Indica se cifrare i dati in transito. Se si specifica "true", assicurarsi di completare i passi di impostazione descritti nella sezione Cifratura dei dati in transito in un nuovo file system. Se non specificato, per impostazione predefinita viene utilizzato "false". Ad esempio, encryptInTransit: "true".
      • oci.oraclecloud.com/initial-defined-tags-override: '{"<tag-namespace>": {"<tag-key>": "<tag-value>"}}' Facoltativo. Specifica un tag definito per il nuovo file system. Ad esempio, oci.oraclecloud.com/initial-defined-tags-override: '{"Operations": {"CostCenter": "42"}}'

        Tenere presente che per applicare le tag definite da uno spazio di nomi tag appartenente a un compartimento a una risorsa del file system appartenente a un compartimento diverso, è necessario includere un'istruzione dei criteri per consentire al cluster di utilizzare lo spazio di nomi tag. Vedere Criterio IAM aggiuntivo quando un cluster e uno spazio di nomi tag si trovano in compartimenti diversi.

      • oci.oraclecloud.com/initial-freeform-tags-override: '{"<tag-key>": "<tag-value>"}' Facoltativo. Specifica un tag in formato libero per il nuovo file system. Ad esempio, oci.oraclecloud.com/initial-freeform-tags-override: '{"Department": "Finance"}'

      Ad esempio:

      kind: StorageClass
      apiVersion: storage.k8s.io/v1
      metadata:
        name: fss-dyn-storage
      provisioner: fss.csi.oraclecloud.com
      parameters:
        availabilityDomain: US-ASHBURN-AD-1
        mountTargetSubnetOcid: ocid1.subnet.oc1.iad.aaaaaaaa2xpk______zva
        compartmentOcid: ocid1.compartment.oc1..aaaaaaaay______t6q
        kmsKeyOcid: ocid1.key.oc1.iad.anntl______usjh
        exportPath: /FileSystem1
        exportOptions: "[{\"source\":\"0.0.0.0/0\",\"requirePrivilegedSourcePort\":false,\"access\":\"READ_WRITE\",\"identitySquash\":\"NONE\"}]"
        encryptInTransit: "true"

   2. Creare la classe di memorizzazione dal file manifest immettendo:

      kubectl create -f <filename>

      Ad esempio:

      kubectl create -f fss-dyn-st-class.yaml

3. Creare regole di sicurezza in un gruppo di sicurezza di rete (consigliato) o in una lista di sicurezza sia per la destinazione di accesso a cui viene fatto riferimento nella definizione della classe di storage (o da cui viene creata) sia per i nodi di lavoro del cluster.

   Le regole di sicurezza da creare dipendono dalle posizioni di rete relative della destinazione di accesso e dei nodi di lavoro, in base agli scenari riportati di seguito.

   • Scenario B: destinazione e istanza di accesso nella stessa subnet
   • Scenario A: destinazione e istanza di accesso in subnet diverse (consigliato)

   Questi scenari, le regole di sicurezza da creare e la posizione in cui crearli, sono descritti completamente nella documentazione del servizio di storage di file (vedere Configurazione delle regole di sicurezza VCN per lo storage di file).

4. Creare un PVC di cui eseguire il provisioning dal nuovo file system nel servizio di storage di file, come indicato di seguito.
   1. Creare un file manifest per definire il PVC:

      apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        name: <pvc-name>
      spec:
        accessModes:
          - ReadWriteMany
        storageClassName: "<storage-class-name>"
        resources:
          requests:
            storage: 50Gi

      Dove:

      • name: <pvc-name>: richiesto. Ad esempio, fss-dynamic-claim
      • storageClassName: "<storage-class-name>": obbligatorio. Il nome della classe di memorizzazione definita in precedenza. Ad esempio, fss-dyn-storage.
      • accessModes: - ReadWriteMany: obbligatorio. Si noti che accessModes: deve specificare ReadWriteMany.
      • storage: 50Gi: obbligatorio. Si noti che Kubernetes richiede di specificare un valore per storage: nel file manifesto in PVC. Tuttavia, il servizio di storage di file non supporta la specifica di una dimensione di file system e crea un nuovo file system con una dimensione predefinita, indipendentemente dal valore specificato per storage:.

      Ad esempio, il seguente file manifesto (denominato fss-dyn-claim.yaml) definisce un PVC denominato fss-dynamic-claim di cui viene eseguito il provisioning dal file system definito nella classe di memorizzazione fss-dyn-storage:

      apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        name: fss-dynamic-claim
      spec:
        accessModes:
          - ReadWriteMany
        storageClassName: "fss-dyn-storage"
        resources:
          requests:
            storage: 50Gi

   2. Creare il PVC dal file manifesto inserendo:

      kubectl create -f <filename>

      Ad esempio:

      kubectl create -f fss-dyn-claim.yaml

   Viene creato un nuovo PVC. Il plugin del volume CSI crea un nuovo volume persistente (PV) e un nuovo file system nel servizio di storage di file (insieme a una nuova destinazione di accesso se non è stata specificata una destinazione di accesso esistente).

   Il nuovo PVC è legato al nuovo PV. I dati vengono cifrati in archivio, utilizzando le chiavi di cifratura gestite da Oracle o dall'utente.

5. Verificare che il PVC sia stato legato al nuovo volume persistente inserendo:

   kubectl get pvc

   L'output del comando precedente conferma che il PVC è stato associato con successo:

   			
   NAME                STATUS    VOLUME                 CAPACITY   ACCESSMODES   STORAGECLASS      AGE
   fss-dynamic-claim   Bound     csi-fss-<unique_ID>    50Gi       RWX           fss-dyn-storage   4m

6. Utilizzare il nuovo PVC quando si creano altri oggetti, come i baccelli. Ad esempio, è possibile creare un nuovo pod dalla seguente definizione pod:

   apiVersion: v1
   kind: Pod
   metadata:
     name: fss-dynamic-app
   spec:
     containers:
       - name: nginx
         image: nginx:latest
         ports:
           - name: http
             containerPort: 80
         volumeMounts:
           - name: persistent-storage
             mountPath: /usr/share/nginx/html
     volumes:
     - name: persistent-storage
       persistentVolumeClaim:
         claimName: fss-dynamic-claim

7. Dopo aver creato un nuovo pod come descritto nell'esempio nel passaggio precedente, è possibile verificare che il pod stia utilizzando il nuovo PVC inserendo:

   kubectl describe pod nginx

Per creare un PVC su un file system esistente nel servizio di storage di file (utilizzando chiavi di cifratura gestite da Oracle per cifrare i dati in archivio):

1. Creare un file system con una destinazione di accesso nel servizio di storage di file, selezionando l'opzione di cifratura Cifra mediante chiavi gestite da Oracle. Vedere Creazione di un file system.
2. Creare regole di sicurezza in un gruppo di sicurezza di rete (consigliato) o in una lista di sicurezza sia per la destinazione di accesso che esporta il file system sia per i nodi di lavoro del cluster.
   Le regole di sicurezza da creare dipendono dalle posizioni di rete relative della destinazione di accesso e dei nodi di lavoro, in base agli scenari riportati di seguito.

   • Scenario B: destinazione e istanza di accesso nella stessa subnet
   • Scenario A: destinazione e istanza di accesso in subnet diverse (consigliato)

   Questi scenari, le regole di sicurezza da creare e la posizione in cui crearli, sono descritti completamente nella documentazione del servizio di storage di file (vedere Configurazione delle regole di sicurezza VCN per lo storage di file).

3. Creare un PV supportato dal file system nel servizio di storage di file come indicato di seguito.

   1. Creare un file manifesto per definire un PV e, nella sezione csi:, impostare:

      • Da driver a fss.csi.oraclecloud.com
      • Da volumeHandle a <FileSystemOCID>:<MountTargetIP>:<path>
        Dove:

        • <FileSystemOCID> è l'OCID del file system definito nel servizio di storage di file.
        • <MountTargetIP> è l'indirizzo IP assegnato alla destinazione di accesso.
        • <path> è il percorso di accesso al file system relativo all'indirizzo IP della destinazione di accesso, a partire da una barra.

        Ad esempio: ocid1.filesystem.oc1.iad.aaaa______j2xw:10.0.0.6:/FileSystem1

      Ad esempio, il seguente file manifesto (denominato fss-pv.yaml) definisce un PV denominato fss-pv supportato da un file system nel servizio di storage di file:

      apiVersion: v1
      kind: PersistentVolume
      metadata:
        name: fss-pv
      spec:
        capacity:
          storage: 50Gi
        volumeMode: Filesystem
        accessModes:
          - ReadWriteMany
        persistentVolumeReclaimPolicy: Retain
        csi:
          driver: fss.csi.oraclecloud.com
          volumeHandle: ocid1.filesystem.oc1.iad.aaaa______j2xw:10.0.0.6:/FileSystem1

   2. Creare il PV dal file manifesto immettendo:

      kubectl create -f <filename>

      Ad esempio:

      kubectl create -f fss-pv.yaml

4. Creare un PVC fornito dal PV creato, come segue:
   1. Creare un file manifesto per definire il PVC e impostare:
      • Da storageClassName a "". Si noti che è necessario specificare un valore vuoto per storageClassName, anche se la classe di memorizzazione non è applicabile in caso di provisioning statico dello storage persistente. Se non si specifica un valore vuoto per storageClassName, viene utilizzata la classe di memorizzazione predefinita (oci-bv), che causa un errore.
      • volumeName al nome del PV creato (ad esempio, fss-pv)

      Ad esempio, il seguente file manifesto (denominato fss-pvc.yaml) definisce un PVC denominato fss-pvc di cui viene eseguito il provisioning da un PV denominato fss-pv:

      apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        name: fss-pvc
      spec:
        accessModes:
          - ReadWriteMany
        storageClassName: ""
        resources:
          requests:
            storage: 50Gi
        volumeName: fss-pv

      Si noti che l'elemento requests: storage: deve essere presente nel file manifesto del PVC e che il relativo valore deve corrispondere al valore specificato per l'elemento capacity: storage: nel file manifesto del PV. A parte questo, il valore dell'elemento requests: storage: viene ignorato.

   2. Creare il PVC dal file manifesto inserendo:

      kubectl create -f <filename>

      Ad esempio:

      kubectl create -f fss-pvc.yaml

Il PVC è associato al PV supportato dal file system del servizio di storage di file. I dati vengono cifrati in archivio utilizzando le chiavi di cifratura gestite da Oracle.