Provisionnement de revendications de volume persistant dans le service de stockage de fichiers

Lorsque vous utilisez le service File Storage pour provisionner des PVC, vous spécifiez le chiffrement en transit indépendamment du chiffrement au repos.

Le service File Storage chiffre toujours les données au repos, à l'aide de clés de chiffrement gérées par Oracle par défaut. Toutefois, vous avez la possibilité de spécifier le chiffrement au repos à l'aide de vos propres clés de chiffrement principales que vous gérez vous-même dans le service de chambre forte. La façon de spécifier le chiffrement au repos dépend du fait de savoir si vous provisionnez une revendication de volume persistant sur :

• un nouveau système de fichiers créé dynamiquement par le plugiciel de volume CSI (voir Chiffrement des données au repos dans un nouveau système de fichiers)
• un système de fichiers existant que vous avez créé manuellement (voir Chiffrement des données au repos sur un système de fichiers existant)

Si vous voulez gérer vos propres clés de chiffrement principales pour chiffrer les données au repos, vous devez :

• Créez une clé de chiffrement principale appropriée dans la chambre forte (ou obtenez l'OCID d'une telle clé). Voir Gestion des clés.
• Créez une politique accordant l'accès à la clé de chiffrement principale. Voir Créer une politique pour accéder aux clés de chiffrement gérées par l'utilisateur pour chiffrer les volumes de démarrage, les volumes par blocs ou les systèmes de fichiers.

Le service File Storage peut facultativement chiffrer les données en transit. Si vous spécifiez le chiffrement en transit, les données en transit sont chiffrées à l'aide d'un certificat TLS (Transport Layer Security) toujours géré par Oracle, que les données au repos soient chiffrées à l'aide de clés gérées par Oracle ou à l'aide de clés gérées par l'utilisateur. Le chiffrement en transit sécurise le transfert de données entre des instances et des systèmes de fichiers montés à l'aide du chiffrement TLS v.1.2. Pour plus d'informations sur le chiffrement en transit et le service de stockage de fichiers, voir Utilisation du chiffrement TLS en transit. La façon de spécifier le chiffrement en transit varie selon que vous provisionnez une revendication de volume persistant sur :

• un nouveau système de fichiers créé dynamiquement par le plugiciel de volume CSI (voir Chiffrement des données en transit dans un nouveau système de fichiers)
• un système de fichiers existant que vous avez créé manuellement (voir Chiffrement des données en transit dans un système de fichiers existant)

Notez que lorsque vous utilisez le service File Storage pour provisionner des PVC, le chiffrement en transit n'est pris en charge que lorsque les instances de calcul hébergeant des noeuds de travail exécutent Oracle Linux 7 et Oracle Linux 8.

Pour provisionner dynamiquement une revendication de volume persistant dans un nouveau système de fichiers créé dynamiquement par le plugiciel de volume CSI dans le service de stockage de fichiers :

1. (Facultatif) Créez une cible de montage dans le service de stockage de fichiers. Voir Création d'une cible de montage.

   Le plugiciel de volume CSI nécessite une cible de montage active (c'est-à-dire une cible de montage avec une adresse IP affectée) pour créer un nouveau système de fichiers. Si vous ne créez pas de cible de montage à l'avance, spécifiez le sous-réseau dans lequel le plugiciel de volume CSI doit créer une nouvelle cible de montage lorsque vous définissez la classe de stockage.

2. Définissez une nouvelle classe de stockage qui utilise le provisionneur fss.csi.oraclecloud.com :
   1. Créez un fichier manifeste (par exemple, dans un fichier nommé fss-dyn-st-class.yaml), spécifiez un nom pour la nouvelle classe de stockage et spécifiez des valeurs pour les paramètres obligatoires et facultatifs :

      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>"}'

      où :

      • name: <storage-class-name> : Obligatoire. Nom de votre choix pour la classe de stockage.
      • availabilityDomain: <ad-name> : Obligatoire. Nom du domaine de disponibilité dans lequel créer le nouveau système de fichiers (et dans lequel créer la nouvelle cible de montage, si l'OCID d'une cible de montage existante n'est pas spécifié). Par exemple : US-ASHBURN-AD-1. Pour connaître le nom du domaine de disponibilité à utiliser, exécutez la commande d'interface de ligne de commande oci iam availability-domain list (ou utilisez l'opération ListAvailabilityDomains). Pour plus d'informations, voir Noms de domaine de disponibilité de votre location.
      • mountTargetOcid: <mt-ocid> | mountTargetSubnetOcid: <mt-subnet-ocid> : Obligatoire. OCID d'une cible de montage active existante (mountTargetOcid: <mt-ocid>) ou OCID d'un sous-réseau dans lequel créer une nouvelle cible de montage (mountTargetSubnetOcid: <mt-subnet-ocid>). Spécifiez mountTargetOcid ou mountTargetSubnetOcid. Si vous spécifiez mountTargetOcid et mountTargetSubnetOcid dans la définition de la classe de stockage, la cible de montage existante spécifiée par mountTargetOcid est utilisée et mountTargetSubnetOcid est ignoré. Par exemple :
        • mountTargetSubnetOcid: ocid1.subnet.oc1.iad.aaaaaaaa2xpk______zva
        • mountTargetOcid: ocid1.mounttarget.oc1.iad.aaaaaaaa4np______fuy
      • compartmentOcid: <compartment-ocid> : Facultatif. L'OCID du compartiment auquel le nouveau système de fichiers (et la nouvelle cible de montage, si l'OCID d'une cible de montage existante n'est pas spécifié) doit appartenir. S'il n'est pas spécifié, le compartiment par défaut est le même que celui de la grappe. Par exemple, compartmentOcid: ocid1.compartment.oc1..aaaaaaaay______t6q
      • kmsKeyOcid: <key-ocid> : Facultatif. OCID d'une clé de chiffrement principale que vous gérez, avec laquelle chiffrer les données au repos. S'il n'est pas spécifié, les données sont chiffrées au repos à l'aide de clés de chiffrement gérées par Oracle. Voir Chiffrement des données au repos dans un nouveau système de fichiers. Par exemple, kmsKeyOcid: ocid1.key.oc1.iad.anntl______usjh
      • exportPath: <path> : Facultatif. Chemin dans une exportation qui identifie de manière unique le système de fichiers dans la cible de montage. Le chemin d'exportation doit commencer par une barre oblique (/) suivie d'une séquence de zéros ou de plusieurs éléments séparés par une barre oblique. Par exemple, /FileSystem1. Pour plus d'informations, voir Chemins dans les systèmes de fichiers.

        Si vous incluez exportPath: <path> dans une définition de classe de stockage, ne spécifiez pas de chemin (soit comme chemin, soit comme sous-chemin d'un chemin existant) qui existe déjà. Si vous spécifiez un chemin qui existe déjà, une erreur est retournée car plusieurs systèmes de fichiers avec la même cible de montage ne peuvent pas avoir le même chemin d'exportation. Par conséquent, si vous incluez exportPath: <path> dans la définition de la classe de stockage, utilisez cette définition de classe de stockage uniquement pour créer un système de fichiers.

        Si vous n'incluez pas exportPath: <path> dans la définition de la classe de stockage, le chemin d'accès par défaut est le nom d'affichage du système de fichiers créé par le plugiciel de volume CSI (commençant par /csi-fss-).

      • exportOptions: "[{<options-in-json-format>}]" Facultatif. Jeu de paramètres (dans un format JSON valide) dans l'exportation qui spécifie le niveau d'accès accordé aux clients NFS lors de la connexion à une cible de montage. Une entrée d'options d'exportation NFS dans une exportation définit l'accès pour une adresse IP ou un intervalle de blocs CIDR. Pour plus d'informations, voir Utilisation des options d'exportation et d'exportation NFS. En l'absence de valeur, la valeur par défaut suivante est utilisée :

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

      • encryptInTransit: "true"|"false" : Facultatif. Indique s'il faut chiffrer les données en transit. Si vous spécifiez "true", assurez-vous d'effectuer les étapes de configuration décrites dans Chiffrement des données en transit dans un nouveau système de fichiers. Si vous ne spécifiez pas de valeur, la valeur par défaut est "false". Par exemple, encryptInTransit: "true".
      • oci.oraclecloud.com/initial-defined-tags-override: '{"<tag-namespace>": {"<tag-key>": "<tag-value>"}}' Facultatif. Spécifie un marqueur défini pour le nouveau système de fichiers. Par exemple, oci.oraclecloud.com/initial-defined-tags-override: '{"Operations": {"CostCenter": "42"}}'

        Notez que pour appliquer des marqueurs définis d'un espace de noms de marqueur appartenant à un compartiment à une ressource de système de fichiers appartenant à un autre compartiment, vous devez inclure un énoncé de politique pour permettre à la grappe d'utiliser l'espace de noms de marqueur. Voir Politique IAM supplémentaire lorsqu'une grappe et un espace de noms de marqueur se trouvent dans des compartiments différents.

      • oci.oraclecloud.com/initial-freeform-tags-override: '{"<tag-key>": "<tag-value>"}' Facultatif. Spécifie un marqueur à structure libre pour le nouveau système de fichiers. Par exemple, oci.oraclecloud.com/initial-freeform-tags-override: '{"Department": "Finance"}'

      Par exemple :

      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. Créez la classe de stockage à partir du fichier manifeste en entrant :

      kubectl create -f <filename>

      Par exemple :

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

3. Créez des règles de sécurité dans un groupe de sécurité de réseau (recommandé) ou une liste de sécurité pour la cible de montage référencée dans (ou créée par) la définition de classe de stockage et pour les noeuds de travail de la grappe.

   Les règles de sécurité à créer dépendent des emplacements de réseau relatifs de la cible de montage et des noeuds de travail, selon les scénarios suivants :

   • Scénario B : Cible de montage et instance dans le même sous-réseau
   • Scénario A : Cible de montage et instance dans des sous-réseaux différents (recommandé)

   Ces scénarios, les règles de sécurité à créer et leur emplacement, sont entièrement décrits dans la documentation du service File Storage (voir Configuration des règles de sécurité de réseau VCN pour le service de stockage de fichiers).

4. Créez une revendication de volume persistant à provisionner par le nouveau système de fichiers dans le service File Storage, comme suit :
   1. Créez un fichier manifeste pour définir la revendication de volume persistant :

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

      où :

      • name: <pvc-name> : Obligatoire. Par exemple, fss-dynamic-claim
      • storageClassName: "<storage-class-name>" : Obligatoire. Nom de la classe de stockage que vous avez définie précédemment. Par exemple, fss-dyn-storage.
      • accessModes: - ReadWriteMany : Obligatoire. Notez que accessModes: doit spécifier ReadWriteMany.
      • storage: 50Gi : Obligatoire. Notez que Kubernetes nécessite que vous spécifiez une valeur pour storage: dans le manifeste de revendication de volume persistant. Toutefois, le service File Storage ne prend pas en charge la spécification d'une taille de système de fichiers et crée un nouveau système de fichiers avec une taille par défaut, quelle que soit la valeur que vous spécifiez pour storage:.

      Par exemple, le fichier manifeste suivant (nommé fss-dyn-claim.yaml) définit une revendication de volume persistant nommée fss-dynamic-claim qui est provisionnée par le système de fichiers défini dans la classe de stockage fss-dyn-storage :

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

   2. Créez la revendication de volume persistant à partir du fichier manifeste en entrant :

      kubectl create -f <filename>

      Par exemple :

      kubectl create -f fss-dyn-claim.yaml

   Un nouveau PVC est créé. Le plugiciel de volume CSI crée un nouveau volume persistant et un nouveau système de fichiers dans le service File Storage (ainsi qu'une nouvelle cible de montage si vous n'avez pas spécifié de cible de montage existante).

   Le nouveau PVC est lié au nouveau PV. Les données sont chiffrées au repos, à l'aide de clés de chiffrement gérées par Oracle ou par vous.

5. Vérifiez que la PVC a été liée au nouveau volume persistant en entrant :

   kubectl get pvc

   La sortie de la commande ci-dessus confirme que la PVC a été liée avec succès :

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

6. Utilisez la nouvelle revendication de PVC lors de la création d'autres objets, tels que des pods. Par exemple, vous pouvez créer un nouveau pod à partir de la définition de pod suivante :

   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. Après avoir créé un nouveau pod comme décrit dans l'exemple de l'étape précédente, vous pouvez vérifier que le pod utilise la nouvelle revendication de volume persistant en entrant :

   kubectl describe pod nginx

Pour créer une revendication de volume persistant sur un système de fichiers existant dans le service File Storage (à l'aide de clés de chiffrement gérées par Oracle pour chiffrer les données au repos) :

1. Créez un système de fichiers avec une cible de montage dans le service File Storage, en sélectionnant l'option de chiffrement Chiffrer à l'aide des clés gérées par Oracle. Voir Création d'un système de fichiers.
2. Créez des règles de sécurité dans un groupe de sécurité de réseau (recommandé) ou une liste de sécurité pour la cible de montage qui exporte le système de fichiers et pour les noeuds de travail de la grappe.
   Les règles de sécurité à créer dépendent des emplacements de réseau relatifs de la cible de montage et des noeuds de travail, selon les scénarios suivants :

   • Scénario B : Cible de montage et instance dans le même sous-réseau
   • Scénario A : Cible de montage et instance dans des sous-réseaux différents (recommandé)

   Ces scénarios, les règles de sécurité à créer et leur emplacement, sont entièrement décrits dans la documentation du service File Storage (voir Configuration des règles de sécurité de réseau VCN pour le service de stockage de fichiers).

3. Créez une valeur actualisée sauvegardée par le système de fichiers dans le service de stockage de fichiers comme suit :

   1. Créez un fichier manifeste pour définir un PV et, dans la section csi:, définissez :

      • driver à fss.csi.oraclecloud.com
      • volumeHandle à <FileSystemOCID>:<MountTargetIP>:<path>
        où :

        • <FileSystemOCID> est l'OCID du système de fichiers défini dans le service de stockage de fichiers.
        • <MountTargetIP> est l'adresse IP affectée à la cible de montage.
        • <path> est le chemin de montage du système de fichiers par rapport à l'adresse IP de la cible de montage, en commençant par une barre oblique.

        Par exemple : ocid1.filesystem.oc1.iad.aaaa______j2xw:10.0.0.6:/FileSystem1

      Par exemple, le fichier manifeste suivant (nommé fss-pv.yaml) définit une valeur ajoutée appelée fss-pv soutenue par un système de fichiers dans le service de stockage de fichiers :

      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. Créez le fichier PV à partir du fichier manifeste en entrant :

      kubectl create -f <filename>

      Par exemple :

      kubectl create -f fss-pv.yaml

4. Créez une revendication de volume persistant provisionnée par la valeur actualisée que vous avez créée, comme suit :
   1. Créez un fichier manifeste pour définir la revendication de volume persistant et définissez les éléments suivants :
      • storageClassName à "". Notez que vous devez spécifier une valeur vide pour storageClassName, même si la classe de stockage n'est pas applicable dans le cas du provisionnement statique du stockage persistant. Si vous ne spécifiez pas de valeur vide pour storageClassName, la classe de stockage par défaut (oci-bv) est utilisée, ce qui entraîne une erreur.
      • volumeName au nom du point de vente que vous avez créé (par exemple, fss-pv)

      Par exemple, le fichier manifeste suivant (nommé fss-pvc.yaml) définit une revendication de volume persistant nommée fss-pvc qui est provisionnée par une valeur actualisée nommée fss-pv :

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

      Notez que l'élément requests: storage: doit être présent dans le fichier manifeste de la revendication de volume persistant et que sa valeur doit correspondre à la valeur spécifiée pour l'élément capacity: storage: dans le fichier manifeste de la revendication de volume persistant. En outre, la valeur de l'élément requests: storage: est ignorée.

   2. Créez la revendication de volume persistant à partir du fichier manifeste en entrant :

      kubectl create -f <filename>

      Par exemple :

      kubectl create -f fss-pvc.yaml

La revendication de volume persistant est liée à la valeur actualisée potentielle soutenue par le système de fichiers du service de stockage de fichiers. Les données sont chiffrées au repos, à l'aide de clés de chiffrement gérées par Oracle.