Provisionando PVCs no Serviço File Storage

Ao usar o serviço File Storage para provisionar PVCs, você especifica a criptografia em trânsito independentemente da criptografia em repouso.

O serviço File Storage sempre criptografa dados em repouso, usando chaves de criptografia gerenciadas pela Oracle por padrão. No entanto, você tem a opção de especificar a criptografia em repouso usando suas próprias chaves de criptografia principais que você gerencia no serviço Vault. Como especificar a criptografia em repouso depende se você está provisionando uma PVC em:

• um novo sistema de arquivos criado dinamicamente pelo plug-in de volume CSI (consulte Criptografando Dados em Repouso em um Novo Sistema de Arquivos)
• um sistema de arquivos existente que você criou manualmente (consulte Criptografando Dados em Repouso em um Sistema de Arquivos Existente)

Se você quiser gerenciar suas próprias chaves de criptografia mestras para criptografar dados em repouso, terá que:

• Crie uma chave principal de criptografia adequada no Vault (ou obtenha o OCID dessa chave). Consulte Gerenciando Chaves.
• Crie uma política que conceda acesso à chave de criptografia principal. Consulte Criar Política para Acessar Chaves de Criptografia Gerenciadas pelo Usuário para Criptografar Volumes de Inicialização, Volumes em Blocos e/ou Sistemas de Arquivos.

Opcionalmente, o serviço File Storage pode criptografar dados em trânsito. Se você especificar criptografia em trânsito, os dados em trânsito serão criptografados usando um certificado TLS (Transport Layer Security) que é sempre gerenciado pela Oracle, independentemente de os dados em repouso serem criptografados usando chaves gerenciadas pela Oracle ou usando chaves gerenciadas pelo usuário. A criptografia em trânsito protege os dados que estão sendo transferidos entre instâncias e sistemas de arquivos montados usando a criptografia TLS v. 1.2. Para obter mais informações sobre criptografia em trânsito e o serviço File Storage, consulte Using In-transit TLS Encryption. Como especificar a criptografia em trânsito depende de se você está provisionando uma PVC em:

• um novo sistema de arquivos criado dinamicamente pelo plug-in de volume CSI (consulte Criptografando Dados em Trânsito em um Novo Sistema de Arquivos)
• um sistema de arquivos existente que você criou manualmente (consulte Criptografando Dados em Trânsito em um Sistema de Arquivos Existente)

Observe que, ao usar o serviço File Storage para provisionar PVCs, a criptografia em trânsito só é suportada quando as instâncias de computação que hospedam nós de trabalho estão executando o Oracle Linux 7 e o Oracle Linux 8.

Para provisionar dinamicamente uma PVC em um novo sistema de arquivos criado dinamicamente pelo plug-in de volume CSI no serviço File Storage:

1. (Opcional) Crie um destino de montagem no serviço File Storage. Consulte Criando um Destino de Montagem.

   O plug-in de volume CSI requer um ponto de acesso NFS ativo (ou seja, um ponto de acesso NFS com um endereço IP designado) para criar um novo sistema de arquivos. Se você não criar um ponto de acesso NFS com antecedência, especifique a sub-rede na qual o plug-in de volume CSI deverá criar um novo ponto de acesso NFS ao definir a classe de armazenamento.

2. Defina uma nova classe de armazenamento que use o provisionador fss.csi.oracleclould.com:
   1. Crie um arquivo de manifesto (por exemplo, em um arquivo chamado fss-dyn-st-class.yaml), especifique um nome para a nova classe de armazenamento e especifique valores para os parâmetros obrigatórios e opcionais:

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

      em que:

      • name: <storage-class-name>: Obrigatório. Um nome de sua escolha para a classe de armazenamento.
      • availabilityDomain: <ad-name>: Obrigatório. O nome do domínio de disponibilidade no qual criar o novo sistema de arquivos (e no qual criar o novo ponto de acesso NFS, se um OCID de ponto de acesso NFS existente não for especificado). Por exemplo, US-ASHBURN-AD-1. Para descobrir o nome do domínio de disponibilidade a ser usado, execute o comando da CLI oci iam availability-domain list (ou use a operação ListAvailabilityDomains). Para obter mais informações, consulte Nomes de Domínio de Disponibilidade da Sua Tenancy.
      • mountTargetOcid: <mt-ocid> | mountTargetSubnetOcid: <mt-subnet-ocid>: Obrigatório. O OCID de um ponto de acesso NFS ativo existente (mountTargetOcid: <mt-ocid>) ou o OCID de uma sub-rede na qual será criado um novo ponto de acesso NFS (mountTargetSubnetOcid: <mt-subnet-ocid>). Especifique mountTargetOcid ou mountTargetSubnetOcid. Se você especificar mountTargetOcid e mountTargetSubnetOcid na definição da classe de armazenamento, o ponto de acesso NFS existente especificado por mountTargetOcid será usado e mountTargetSubnetOcid será ignorado. Por exemplo:
        • mountTargetSubnetOcid: ocid1.subnet.oc1.iad.aaaaaaaa2xpk______zva
        • mountTargetOcid: ocid1.mounttarget.oc1.iad.aaaaaaaa4np______fuy
      • compartmentOcid: <compartment-ocid>: Opcional. O OCID do compartimento ao qual o novo sistema de arquivos (e o novo ponto de acesso NFS, se um OCID de ponto de acesso NFS existente não for especificado) pertencerá. Se não for especificado, o padrão será o mesmo compartimento do cluster. Por exemplo, compartmentOcid: ocid1.compartment.oc1..aaaaaaaay______t6q
      • kmsKeyOcid: <key-ocid>: Opcional. O OCID de uma chave de criptografia mestra que você gerencia, com a qual criptografar dados em repouso. Se não for especificado, os dados serão criptografados em repouso usando chaves de criptografia gerenciadas pela Oracle. Consulte Criptografando Dados em Repouso em um Novo Sistema de Arquivos. Por exemplo, kmsKeyOcid: ocid1.key.oc1.iad.anntl______usjh
      • exportPath: <path>: Opcional. O caminho em uma exportação que identifica de forma exclusiva o sistema de arquivos dentro do destino de montagem. O caminho de exportação deve começar com uma barra (/) seguida por uma sequência de zero ou mais elementos separados por barra. Por exemplo, /FileSystem1. Para obter mais informações, consulte Caminhos em Sistemas de Arquivos.

        Se você incluir exportPath: <path> em uma definição de classe de armazenamento, não especifique um caminho (como um caminho ou como o subcaminho de um caminho existente) que já exista. Se você especificar um caminho que já existe, um erro será retornado porque vários sistemas de arquivos com o mesmo ponto de acesso NFS não podem ter o mesmo caminho de exportação. Portanto, se você incluir exportPath: <path> na definição de classe de armazenamento, use apenas essa definição de classe de armazenamento para criar um sistema de arquivos.

        Se você não incluir exportPath: <path> na definição da classe de armazenamento, o caminho assumirá como padrão o nome para exibição do sistema de arquivos criado pelo plug-in de volume CSI (começando com /csi-fss-).

      • exportOptions: "[{<options-in-json-format>}]" Opcional. Um conjunto de parâmetros (no formato JSON válido) dentro da exportação que especifica o nível de acesso concedido aos clientes NFS quando eles se conectam a um ponto de acesso NFS. Uma entrada de opções de exportação NFS dentro de uma exportação define o acesso para um único endereço IP ou faixa de blocos CIDR. Para obter mais informações, consulte Working with NFS Exports and Export Options. Se não for especificado, o seguinte padrão será usado:

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

      • encryptInTransit: "true"|"false": Opcional. Indica se os dados devem ser criptografados em trânsito. Se você especificar "true", certifique-se de concluir as etapas de configuração descritas em Criptografando Dados em Trânsito em um Novo Sistema de Arquivos. Se não for especificado, o padrão será "false". Por exemplo, encryptInTransit: "true".
      • oci.oraclecloud.com/initial-defined-tags-override: '{"<tag-namespace>": {"<tag-key>": "<tag-value>"}}' Opcional. Especifica uma tag definida para o novo sistema de arquivos. Por exemplo, oci.oraclecloud.com/initial-defined-tags-override: '{"Operations": {"CostCenter": "42"}}'

        Observe que, para aplicar tags definidas de um namespace de tag pertencente a um compartimento a um recurso do sistema de arquivos pertencente a outro compartimento, inclua uma instrução de política para permitir que o cluster use o namespace de tag. Consulte Política Adicional do IAM quando um Cluster e um Namespace de Tag estão em Diferentes Compartimentos.

      • oci.oraclecloud.com/initial-freeform-tags-override: '{"<tag-key>": "<tag-value>"}' Opcional. Especifica uma tag de formato livre para o novo sistema de arquivos. Por exemplo, oci.oraclecloud.com/initial-freeform-tags-override: '{"Department": "Finance"}'

      Por exemplo:

      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. Crie a classe de armazenamento a partir do arquivo de manifesto digitando:

      kubectl create -f <filename>

      Por exemplo:

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

3. Crie regras de segurança em um grupo de segurança de rede (recomendado) ou em uma lista de segurança para o ponto de acesso NFS referenciado na definição da classe de armazenamento (ou criado por) e para os nós de trabalho do cluster.

   As regras de segurança a serem criadas dependem dos locais de rede relativos do ponto de acesso NFS e dos nós de trabalho, de acordo com os seguintes cenários:

   • Cenário B: Ponto de acesso NFS e instância na mesma sub-rede
   • Cenário A: Ponto de acesso NFS e instância em sub-redes diferentes (recomendado)

   Esses cenários, as regras de segurança a serem criadas e onde criá-las, são totalmente descritos na documentação do serviço File Storage (consulte Configurando Regras de Segurança da VCN para o Serviço File Storage).

4. Crie uma PVC a ser provisionada pelo novo sistema de arquivos no serviço File Storage, da seguinte forma:
   1. Crie um arquivo de manifesto para definir a PVC:

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

      em que:

      • name: <pvc-name>: Obrigatório. Por exemplo, fss-dynamic-claim
      • storageClassName: "<storage-class-name>": Obrigatório. O nome da classe de armazenamento definida anteriormente. Por exemplo, fss-dyn-storage.
      • accessModes: - ReadWriteMany: Obrigatório. Observe que accessModes: deve especificar ReadWriteMany.
      • storage: 50Gi: Obrigatório. Observe que o Kubernetes exige que você especifique um valor para storage: no manifesto de PVC. No entanto, o serviço File Storage não suporta a especificação de um tamanho de sistema de arquivos e cria um novo sistema de arquivos com um tamanho padrão, independentemente do valor especificado para storage:.

      Por exemplo, o seguinte arquivo de manifesto (denominado fss-dyn-claim.yaml) define uma PVC denominada fss-dynamic-claim que é provisionada pelo sistema de arquivos definido na classe de armazenamento fss-dyn-storage:

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

   2. Crie a PVC a partir do arquivo de manifesto digitando:

      kubectl create -f <filename>

      Por exemplo:

      kubectl create -f fss-dyn-claim.yaml

   Um novo PVC é criado. O plug-in de volume CSI cria um novo volume persistente (PV) e um novo sistema de arquivos no serviço File Storage (junto com um novo ponto de acesso NFS se você não tiver especificado um ponto de acesso NFS existente).

   O novo PVC está ligado ao novo PV. Os dados são criptografados em repouso, usando chaves de criptografia gerenciadas pela Oracle ou por você.

5. Verifique se a PVC foi vinculada ao novo volume persistente digitando:

   kubectl get pvc

   A saída do comando anterior confirma que a PVC foi vinculada com sucesso:

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

6. Use a nova PVC ao criar outros objetos, como pods. Por exemplo, você pode criar um novo pod com base na seguinte definição de 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. Depois de criar um novo pod conforme descrito no exemplo da etapa anterior, você pode verificar se o pod está usando a nova PVC digitando:

   kubectl describe pod nginx

Para criar uma PVC em um sistema de arquivos existente no serviço File Storage (usando chaves de criptografia gerenciadas pela Oracle para criptografar dados em repouso):

1. Crie um sistema de arquivos com um ponto de acesso NFS no serviço File Storage, selecionando a opção de criptografia Criptografar usando chaves gerenciadas pela Oracle. Consulte Criando um Sistema de Arquivos.
2. Crie regras de segurança em um grupo de segurança de rede (recomendado) ou em uma lista de segurança para o ponto de acesso NFS que exporta o sistema de arquivos e para os nós de trabalho do cluster.
   As regras de segurança a serem criadas dependem dos locais de rede relativos do ponto de acesso NFS e dos nós de trabalho, de acordo com os seguintes cenários:

   • Cenário B: Ponto de acesso NFS e instância na mesma sub-rede
   • Cenário A: Ponto de acesso NFS e instância em sub-redes diferentes (recomendado)

   Esses cenários, as regras de segurança a serem criadas e onde criá-las, são totalmente descritos na documentação do serviço File Storage (consulte Configurando Regras de Segurança da VCN para o Serviço File Storage).

3. Crie um PV suportado pelo sistema de arquivos no serviço File Storage da seguinte forma:

   1. Crie um arquivo de manifesto para definir um PV e, na seção csi:, defina:

      • driver a fss.csi.oraclecloud.com
      • volumeHandle a <FileSystemOCID>:<MountTargetIP>:<path>
        em que:

        • <FileSystemOCID> é o OCID do sistema de arquivos definido no serviço File Storage.
        • <MountTargetIP> é o endereço IP designado ao ponto de acesso NFS.
        • <path> é o caminho de montagem para o sistema de arquivos relativo ao endereço IP do ponto de acesso NFS, começando com uma barra.

        Por exemplo: ocid1.filesystem.oc1.iad.aaaa______j2xw:10.0.0.6:/FileSystem1

      Por exemplo, o seguinte arquivo de manifesto (denominado fss-pv.yaml) define um PV chamado fss-pv suportado por um sistema de arquivos no serviço File Storage:

      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. Crie o PV a partir do arquivo de manifesto digitando:

      kubectl create -f <filename>

      Por exemplo:

      kubectl create -f fss-pv.yaml

4. Crie uma PVC provisionada pelo PV que você criou, da seguinte forma:
   1. Crie um arquivo de manifesto para definir a PVC e defina:
      • storageClassName a ""
      • volumeName para o nome do PV criado (por exemplo, fss-pv)

      Por exemplo, o seguinte arquivo de manifesto (denominado fss-pvc.yaml) define uma PVC chamada fss-pvc que é provisionada por um PV chamado fss-pv:

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

      Observe que o elemento requests: storage: deve estar presente no arquivo de manifesto da PVC, e seu valor deve corresponder ao valor especificado para o elemento capacity: storage: no arquivo de manifesto do PV. Além disso, o valor do elemento requests: storage: é ignorado.

   2. Crie a PVC a partir do arquivo de manifesto digitando:

      kubectl create -f <filename>

      Por exemplo:

      kubectl create -f fss-pvc.yaml

A PVC está vinculada ao PV suportado pelo sistema de arquivos do serviço File Storage. Os dados são criptografados em repouso, usando chaves de criptografia gerenciadas pela Oracle.