Crittografia in transito per IBM Cloud File Storage for VPC

Cloud privato virtuale

Utilizza la crittografia in transito (EIT) per proteggere i dati durante il trasferimento tra i nodi di lavoro e il servizio File Storage for VPC. Questo argomento tratta l'EIT sia per le condivisioni di file zonali che utilizzano il profilo " dp2 " sia per le condivisioni di file regionali che utilizzano il profilo " rfs ".

Condivisioni di file a livello di zona — Configurazione della crittografia in transito

Se si decide di utilizzare la crittografia in transito, è necessario trovare un equilibrio tra i requisiti di sicurezza e le esigenze in termini di prestazioni. La crittografia dei dati in transito può influire sulle prestazioni, poiché i dati devono essere crittografati e decrittografati agli endpoint. Per ulteriori informazioni, consultare la sezione " Crittografia VPC in transito ".

Sui nodi di lavoro RHCOS ( CoreOS ), l'EIT non è attivo finché il nodo non viene riavviato dopo che l'operatore ha installato i pacchetti necessari. Quando si abilita l'EIT, è necessario pianificare un riavvio graduale.

  • EIT è disponibile per le versioni del cluster 4.16 e successive.
  • Per impostazione predefinita, le condivisioni di file vengono crittografate a riposo tramite la crittografia gestita d IBM.
  • Per utilizzare EIT con i cluster “Secure by Default”, è necessario aggiungere la seguente regola in uscita al gruppo di sicurezza “ kube-<clusterID> ”. Questa regola viene aggiunta automaticamente per i cluster ROKS a partire dalla versione 4.18 e successive. Per le versioni precedenti di Cluster, aggiungere la regola manualmente.
    • Protocollo: Qualsiasi
    • Tipo di fonte: Qualsiasi
    • Fonte: 0.0.0.0/0
    • Destinazione: 169.254.169.254
  • L'EIT non è disponibile per i volumi configurati in modo statico. Per configurare EIT, è necessario utilizzare il provisioning dinamico.
  • I pacchetti EIT vengono aggiornati automaticamente nel cluster quando EIT è abilitato.
  • La crittografia dei dati in transito può influire sulle prestazioni. L'impatto dipende dalle caratteristiche del carico di lavoro. I carichi di lavoro che eseguono scritture sincrone o aggirano la cache VSI, come i database, potrebbero subire un impatto significativo sulle prestazioni quando la funzione EIT è abilitata. Per valutare l'impatto, confronta il tuo carico di lavoro con e senza EIT.
  • Anche senza l’EIT, i dati transitano attraverso una rete di data center sicura. Per ulteriori informazioni sulla sicurezza della rete, consulta le sezioni " Sicurezza nella tua VPC " e "Protezione dei servizi di infrastruttura del Virtual Private Cloud(VPC)con restrizioni basate sul contesto ".

File Storage for VPC è considerato un servizio certificato per i servizi finanziari solo quando è abilitata la crittografia in transito. Per ulteriori informazioni, consulta la sezione " Che cos’è un servizio Financial Services Validated?".

Seguire la procedura riportata di seguito per configurare la crittografia in transito (EIT) per le condivisioni di file nel cluster di Red Hat OpenShift on IBM Cloud. L'abilitazione di EIT installa i pacchetti necessari sui nodi di lavoro.

  1. Prendi nota dei pool di worker nel tuo cluster in cui desideri abilitare l'EIT.

  2. Modifica il file addon-vpc-file-csi-driver-configmap.

    oc edit cm addon-vpc-file-csi-driver-configmap -n kube-system

  3. Nella ConfigMap, imposta “ ENABLE_EIT: "true" ” e aggiungi i pool di worker per i quali desideri abilitare l’EIT nel campo “ EIT_ENABLED_WORKER_POOLS ”. Ad esempio: "wp1,wp2". È inoltre possibile impostare i parametri EIT_METADATA_RETRY_COUNT e EIT_METADATA_RETRY_INTERVAL per controllare il comportamento dei tentativi di recupero durante il recupero dei metadati dell'istanza.

    apiVersion: v1
data:
  EIT_ENABLED_WORKER_POOLS: "wp1,wp2" # Specify the worker pools where you want to enable EIT. If this field is blank, EIT is not enabled on any worker pools.
  ENABLE_EIT: "true"                   # Specify true/false
  EIT_METADATA_RETRY_COUNT: "3"        # Number of retries for fetching instance metadata before an error is returned
  EIT_METADATA_RETRY_INTERVAL: "30"    # Interval in seconds between each metadata fetch retry
kind: ConfigMap
metadata:
  creationTimestamp: "2024-06-18T09:45:48Z"
  labels:
    app.kubernetes.io/name: ibm-vpc-file-csi-driver
  name: addon-vpc-file-csi-driver-configmap
  namespace: kube-system
  ownerReferences:
  - apiVersion: csi.drivers.ibmcloud.io/v1
    blockOwnerDeletion: true
    controller: true
    kind: VPCFileCSIDriver
    name: ibm-vpc-file-csi-driver
    uid: d3c8bbcd-24fa-4203-9352-4ab7aa72a055
  resourceVersion: "1251777"
  uid: 5c9d6679-4135-458b-800d-217b34d27c75

  4. Dopo aver abilitato l'EIT, salvare e chiudere la configmap.

Il completamento di questa fase può richiedere fino a 5 minuti, poiché l'operatore deve installare i pacchetti EIT sui nodi di lavoro specificati.

  1. Per verificare che l'EIT sia abilitato, controllare gli eventi della configmap file-csi-driver-status per confermare che l'installazione dell'EIT sia avvenuta correttamente su ciascun nodo worker. Cerca gli eventi " Package installation successful " per ciascun nodo nei pool di worker specificati.

    oc describe cm file-csi-driver-status -n kube-system

    Output di esempio

    apiVersion: v1
data:
  EIT_ENABLED_WORKER_NODES: |
    default:
    - 10.240.0.10
    - 10.240.0.8
  PACKAGE_DEPLOYER_VERSION: v1.0.0
  events: |
    - event: EnableVPCFileCSIDriver
      description: 'VPC File CSI Driver enable successful, DriverVersion: v2.0.3'
      timestamp: "2024-06-13 09:17:07"
    - event: EnableEITRequest
      description: 'Request received to enableEIT, workerPools: , check the file-csi-driver-status
        configmap for eit installation status on each node of each workerpool.'
      timestamp: "2024-06-13 09:17:31"
    - event: 'Enabling EIT on host: 10.240.0.10'
      description: 'Package installation successful on host: 10.240.0.10, workerpool: wp1'
      timestamp: "2024-06-13 09:17:48"
    - event: 'Enabling EIT on host: 10.240.0.8'
      description: 'Package installation successful on host: 10.240.0.8, workerpool: wp2'
      timestamp: "2024-06-13 09:17:48"

  2. Se i pool di worker contengono nodi RHCOS ( CoreOS ), eseguire il drain e il riavvio di ciascun nodo interessato per attivare i pacchetti EIT. L'EIT non è operativo sui nodi RHCOS finché il nodo non viene riavviato. Lo svuotamento del nodo garantisce innanzitutto che i carichi di lavoro in esecuzione vengano riprogrammati su altri nodi prima del riavvio, evitando così qualsiasi impatto sulle applicazioni di produzione.

    Svuotare il nodo per terminare in modo sicuro tutti i pod in esecuzione.

    oc drain <node-name> --ignore-daemonsets --delete-emptydir-data

    Riavvia il nodo in stato di drenaggio.

    ibmcloud ks worker reboot --cluster CLUSTER_ID --worker WORKER_ID

    Una volta che il nodo è tornato online e si trova nello stato " Ready ", rimuovine il blocco per consentire nuovamente la pianificazione dei carichi di lavoro su di esso.

    oc uncordon <node-name>

  3. Selezionare una classe di archiviazione preinstallata che supporti EIT oppure crearne una personalizzata.

    • Crea un PVC utilizzando la classe di archiviazione “ ibmc-vpc-file-eit ”.
    • Crea una classe di archiviazione personalizzata e imposta il parametro “ isEITEnabled ” su “ true ”.

  4. Crea un PVC che faccia riferimento alla classe di archiviazione selezionata, quindi distribuisci un'app che utilizzi il tuo PVC.

Se, dopo aver completato questi passaggi, dovessi riscontrare problemi con EIT, consulta le seguenti sezioni dedicate alla risoluzione dei problemi:

Condivisione di file a livello regionale — Configurazione della crittografia in transito (Beta)

Il servizio "Regional File Storage " (RFS) con crittografia in transito (EIT) offre connessioni NFS sicure e crittografate con il protocollo " TLS " per la condivisione di file tra più zone di disponibilità all'interno di una regione. Il componente aggiuntivo " File Storage for VPC " gestisce automaticamente un sidecar stunnel su ciascun nodo di lavoro, che incapsula tutto il traffico NFS in TLS 1.3 o versioni successive, in modo trasparente per le vostre applicazioni.

Per ulteriori informazioni su Regional File Storage, consultare la panoramica sull'archiviazione regionale dei file.

RFS con EIT è disponibile solo come versione beta e se ne consiglia l'uso esclusivamente a scopo sperimentale. Non utilizzare questa funzionalità nei carichi di lavoro di produzione.

Modalità di funzionamento

Quando si crea un PVC con classe di archiviazione RFS EIT e un pod lo monta, l'add-on configura automaticamente un tunnel stunnel crittografato sul nodo worker e instrada attraverso di esso tutto il traffico NFS. La crittografia è trasparente per le applicazioni: queste continuano a utilizzare i collegamenti standard NFS, mentre tutti i dati in transito sono protetti con TLS 1.3 o versioni successive.

Il ciclo di vita del tunnel è interamente gestito dal driver: viene creato quando un pod monta il volume e viene smantellato quando il pod viene eliminato.

Prima di iniziare

Limitazioni

Prima di abilitare RFS EIT, prendere visione delle seguenti limitazioni.

  • Numero massimo di collegamenti PVC per nodo: 300, una porta per ogni PVC nell'intervallo di porte 11300–11599, con vincolo su 127.0.0.1.
  • Conflitto di porte per le applicazioni con hostNetwork: true: i pod delle applicazioni che utilizzano hostNetwork: true e si collegano a 127.0.0.1 nell'intervallo di porte 11300–11599 potrebbero entrare in conflitto con i montaggi PVC RFS EIT esistenti.
  • Si applicano inoltre tutte le limitazioni previste per VPC File Storage.

Configurazione della crittografia in transito per Regional File Storage

Seguire la procedura riportata di seguito per configurare una condivisione file regionale con crittografia in transito.

  1. Creare una classe di archiviazione che specifichi il profilo " rfs " e imposti " isEITEnabled: "true"". Salva il seguente codice YAML in un file denominato “ rfs-eit-sc.yaml ”.

    Per RFS EIT sono richiesti i seguenti parametri: profile: "rfs", isENIEnabled: "true", isEITEnabled: "true" e proto=tcp nelle opzioni di montaggio.

    apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ibmc-vpc-file-rfs-eit-custom
  labels:
    app.kubernetes.io/name: ibm-vpc-file-csi-driver
provisioner: vpc.file.csi.ibm.io
parameters:
  profile: "rfs"           # Regional File Storage profile
  billingType: "hourly"
  throughput: "1000"       # Bandwidth in MB/s (25–8192 MB/s for RFS profile)
  encrypted: "false"
  encryptionKey: ""        # Specify the CRK CRN if encrypted is true
  resourceGroup: ""        # Defaults to the resource group in the storage secret store
  isENIEnabled: "true"     # Required for RFS — enables ENI/VNI feature
  isEITEnabled: "true"     # Enables encryption in transit with stunnel
  securityGroupIDs: ""     # Defaults to the cluster security group kube-<clusterID>
  subnetID: ""             # Defaults to an available subnet in the cluster VPC
  region: ""               # Defaults to the region from the cluster node topology
  primaryIPID: ""          # Optional: existing reserved IP ID (region is required)
  primaryIPAddress: ""     # Optional: IP address for ENI/VNI (region and subnetID required)
  tags: ""
  uid: "0"
  gid: "0"
  classVersion: "1"
mountOptions:
  - hard
  - nfsvers=4.1
  - sec=sys
  - proto=tcp              # Required for stunnel (encryption in transit)
reclaimPolicy: "Delete"
allowVolumeExpansion: true

  2. Applicare la classe di archiviazione.

    oc apply -f rfs-eit-sc.yaml

  3. Creare un PVC che faccia riferimento alla classe di archiviazione “ ibmc-vpc-file-rfs-eit-custom ”. Salva il seguente codice YAML in un file denominato “ rfs-eit-pvc.yaml ”.

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-rfs-eit-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Gi
  storageClassName: ibmc-vpc-file-rfs-eit-custom

  4. Applicare il PVC.

    oc apply -f rfs-eit-pvc.yaml

  5. Crea un pod che monti il PVC. Salva il seguente codice YAML in un file denominato “ rfs-eit-pod.yaml ”.

    apiVersion: v1
kind: Pod
metadata:
  name: my-rfs-eit-app
spec:
  containers:
  - name: app
    image: nginx:latest
    volumeMounts:
    - name: rfs-eit-storage
      mountPath: /data
  volumes:
  - name: rfs-eit-storage
    persistentVolumeClaim:
      claimName: my-rfs-eit-pvc

  6. Applicare la capsula.

    oc apply -f rfs-eit-pod.yaml

Verifica che la crittografia in transito sia attiva

Una volta avviato il pod, verificare che la crittografia in transito funzioni correttamente controllando la destinazione della condivisione dei file. Il target di montaggio deve visualizzare " Transit Encryption: stunnel " per confermare che l'EIT sia attivo.

  1. Attendere che il pod raggiunga lo stato “ Running ” e che il PVC raggiunga lo stato “ Bound ”.

    oc get pod my-rfs-eit-app
oc get pvc my-rfs-eit-pvc

  2. Recupera l'ID della condivisione file e l'ID della destinazione di montaggio dal volume persistente.

    oc describe pv <pv-name> | grep -E "fileShareId|fileShareTargetId"

    Prendere nota dei valori “ fileShareId ” e “ fileShareTargetId ” riportati nell’output. Li utilizzerai nel passaggio successivo per verificare l'EIT sul lato VPC.

  3. Verificare che la destinazione di montaggio della condivisione file indichi “ stunnel ” come metodo di crittografia di transito.

    ibmcloud is share-mount-target FILE_SHARE_ID FILE_SHARE_TARGET_ID | grep "Transit Encryption"

    Esempio di output che conferma che l'EIT è attivo:

    Transit Encryption          stunnel

Risoluzione dei problemi di RFS EIT

Per assistenza sugli errori più comuni relativi a RFS EIT, consultare la sezione " Risoluzione dei problemi relativi alla crittografia " File Storage " regionale durante il trasferimento ".

Passi successivi