Documentazione di Oracle Cloud Infrastructure

Crittografia dei segreti Kubernetes in archivio in eccd

Scopri come cifrare i dati di configurazione memorizzati come segreti Kubernetes in etcd quando si utilizza Kubernetes Engine (OKE).

Il piano di controllo del cluster Kubernetes memorizza i dati di configurazione riservati (ad esempio token di autenticazione, certificati e credenziali) come oggetti segreti Kubernetes in etcd. Etcd è un keystore distribuito open source che Kubernetes utilizza per il coordinamento dei cluster e la gestione dello stato. Nei cluster Kubernetes creati da Kubernetes Engine, etcd scrive e legge i dati da e verso i volumi di storage a blocchi nel servizio Oracle Cloud Infrastructure Block Volume. Per impostazione predefinita, Oracle cifra i dati nei volumi a blocchi in archivio, inclusi etcd e i segreti Kubernetes. Oracle gestisce questa cifratura predefinita utilizzando una chiave di cifratura master, senza richiedere alcuna azione da parte dell'utente. Per un ulteriore controllo sul ciclo di vita della chiave di cifratura master e sul modo in cui viene utilizzata, è possibile scegliere di gestire la chiave di cifratura master autonomamente, anziché far sì che Oracle la gestisca automaticamente.

Se si sceglie di gestire la chiave di cifratura principale, si specifica la chiave da utilizzare e si ha il controllo su quando la chiave viene ruotata. La chiave di cifratura master viene memorizzata nel servizio Oracle Cloud Infrastructure Vault (vedere Gestione delle chiavi). I segreti Kubernetes in archivio in etcd vengono cifrati utilizzando una chiave di cifratura dati (DEK) utilizzando l'algoritmo di cifratura AES-CBC con riempimento PKCS#7. Viene generato un nuovo DEK per ogni cifratura. Le chiavi di cifratura dei dati vengono cifrate utilizzando la chiave di cifratura master (MEK), un concetto noto come crittografia dell'envelope.

Prima di poter creare un cluster per il quale si desidera gestire la chiave di cifratura master, è necessario:

  • creare una chiave di cifratura master appropriata nel vault (o ottenere il nome e l'OCID di tale chiave)
  • creare un gruppo dinamico che includa tutti i cluster nel compartimento in cui si sta per creare il nuovo cluster
  • creare un criterio che autorizzi il gruppo dinamico a utilizzare la chiave di cifratura master

Dopo aver creato il cluster e aver specificato che si desidera gestire autonomamente la chiave di cifratura master, è possibile limitare l'uso della chiave di cifratura master modificando il gruppo dinamico in modo che includa solo tale cluster.

Tenere presente quanto riportato di seguito.

  • È possibile selezionare solo l'opzione per gestire manualmente la chiave di cifratura principale quando si crea un nuovo cluster nel workflow 'Creazione personalizzata'. Non è possibile scegliere di gestire la chiave di cifratura principale quando si crea un nuovo cluster nel workflow 'Creazione rapida'. Non è inoltre possibile scegliere di gestire le chiavi di cifratura master per i cluster creati in precedenza nel workflow 'Creazione personalizzata'.
Attenzione

Se si seleziona l'opzione per gestire manualmente la chiave di cifratura master, non eliminare successivamente la chiave di cifratura master nel servizio Vault. Non appena pianifichi l'eliminazione di una chiave nel vault, i segreti Kubernetes memorizzati per il cluster in etcd diventano inaccessibili. Se la chiave è già stata pianificata per l'eliminazione, è possibile che si trovi ancora nello stato Eliminazione in sospeso. In questo caso, annullare l'eliminazione della chiave pianificata (vedere Annullamento dell'eliminazione di una chiave di cifratura master) per ripristinare l'accesso ai segreti Kubernetes. Se si consente il completamento dell'operazione di eliminazione della chiave pianificata e l'eliminazione della chiave di cifratura principale, i segreti Kubernetes memorizzati per il cluster in etcd sono inaccessibili in modo permanente. Di conseguenza, gli aggiornamenti del cluster non riusciranno. In questa situazione, non si ha altra scelta che eliminare e ricreare il cluster.

Impostazione dell'accesso alle chiavi di cifratura master

Se si sceglie di gestire la chiave di cifratura master che cifra i segreti Kubernetes nell'area di memorizzazione chiave/valore etcd del cluster durante la creazione di un nuovo cluster nel workflow 'Creazione personalizzata', impostare l'accesso alla chiave di cifratura master:

  1. Eseguire il login a Console.

  2. Se si conosce l'OCID della chiave di cifratura master da utilizzare per cifrare i segreti Kubernetes, andare direttamente al passo successivo. Altrimenti:

    • Se nel vault esiste già una chiave di cifratura master adatta, ma non si è certi del relativo OCID, seguire le istruzioni riportate in Lista delle chiavi di cifratura master e prendere nota dell'OCID della chiave di cifratura master.
    • Se nel vault non esiste già una chiave di cifratura master appropriata, seguire le istruzioni riportate in Creazione di una chiave di cifratura master per crearne una, impostando le opzioni riportate di seguito.
      • Modalità di protezione per il software o HSM.
      • Forma chiave: algoritmo in AES, RSA o ECDSA.
      • Forma chiave: lunghezza per le chiavi AES (128, 256) e le chiavi RSA (2048, 3072, 4096) o Forma chiave: ID curva per le chiavi ECDSA (NIST_P256, NIST_P384, NIST_P521).
      Dopo aver creato una nuova chiave di cifratura master, prendere nota del relativo OCID.

  3. Concedere l'accesso alla chiave di cifratura master nel vault.

    È possibile concedere l'accesso alla chiave di cifratura master in due modi:

    Creare un nuovo criterio IAM (consigliato)
    1. Aprire il menu di navigazione e selezionare Identità e sicurezza. In Identità, selezionare Criteri.
    2. Seguire le istruzioni in Per creare un criterio e assegnare un nome al criterio, ad esempio acme-oke-kms-policy.

    3. Immettere un'istruzione criterio per concedere l'accesso alla chiave di cifratura principale nel formato seguente:

      Allow any-user to use keys in compartment <compartment-name> where ALL {request.principal.type = 'cluster', target.key.id = '<key-ocid>'}

      Dove:

      • <compartment-name> è il nome del compartimento contenente la chiave di cifratura master.
      • <key-OCID> è l'OCID della chiave di cifratura master nel vault.

      Ad esempio:

      Allow any-user to use keys in compartment acme-kms-key-compartment where ALL {request.principal.type = 'cluster', target.key.id = 'ocid1.key.oc1.iad.annrl______trfg'}
    4. Selezionare Crea per creare il nuovo criteri.
    Creare un nuovo gruppo dinamico, quindi creare un nuovo criterio IAM
    1. Aprire il menu di navigazione e selezionare Identità e sicurezza. In Identità, selezionare Domini. In Dominio di Identity, selezionare Gruppi dinamici.
    2. Seguire le istruzioni in Per creare un gruppo dinamico e assegnare al gruppo dinamico un nome (ad esempio, acme-oke-kms-dyn-grp).

    3. Immettere una regola che includa tutti i cluster nel compartimento nel formato:

      ALL {resource.type = 'cluster', resource.compartment.id = '<compartment-ocid>'}

      dove <compartment-ocid> è l'OCID del compartimento in cui si intende creare il nuovo cluster.

      Ad esempio:

      ALL {resource.type = 'cluster', resource.compartment.id = 'ocid1.compartment.oc1..aaaaaaaa23______smwa'}
    4. Selezionare Crea gruppo dinamico.

      Dopo aver creato un gruppo dinamico che include tutti i cluster nel compartimento, ora è possibile creare un criterio per concedere al gruppo dinamico l'accesso alla chiave di cifratura master nel vault.

    5. Aprire il menu di navigazione e selezionare Identità e sicurezza. In Identità, selezionare Criteri.
    6. Seguire le istruzioni in Per creare un criterio e assegnare un nome al criterio, ad esempio acme-oke-kms-dyn-grp-policy.

    7. Immettere un'istruzione criterio per concedere al gruppo dinamico l'accesso alla chiave di cifratura principale nel formato seguente:

      Allow dynamic-group <dynamic-group-name> to use keys in compartment <compartment-name> where target.key.id = '<key-OCID>'

      Dove:

      • <dynamic-group-name> è il nome del gruppo dinamico creato in precedenza.
      • <compartment-name> è il nome del compartimento contenente la chiave di cifratura master.
      • <key-OCID> è l'OCID della chiave di cifratura master nel vault.

      Ad esempio:

      Allow dynamic-group <acme-oke-kms-dyn-grp> to use keys in compartment acme-kms-key-compartment where target.key.id = 'ocid1.key.oc1.iad.annrl______trfg'
    8. Selezionare Crea per creare il nuovo criteri.

  4. Quando si crea un nuovo cluster, selezionare l'opzione Cifra utilizzando una chiave gestita e specificare la chiave di cifratura principale (vedere Utilizzo della console per creare un cluster con impostazioni definite in modo esplicito nel workflow 'Creazione personalizzata').

  5. (Facoltativo) Dopo aver creato il cluster, per maggiore sicurezza:

    1. Prendere nota dell'OCID del nuovo cluster appena creato.

    2. Limitare l'uso della chiave di cifratura principale:

      • se è stato semplicemente creato un criterio IAM, modificare l'istruzione del criterio in modo che includa in modo esplicito l'OCID del nuovo cluster, anziché tutti i cluster nel compartimento. Ad esempio:

        Allow any-user to use keys in compartment acme-kms-key-compartment where ALL {request.principal.type = 'cluster', target.key.id = 'ocid1.key.oc1.iad.annrl______trfg', request.principal.id = 'ocid1.cluster.oc1.iad.aaaaaaaaaf______yg5q'}

      • se è stato creato un gruppo dinamico, modificare la regola del gruppo dinamico creata in precedenza per specificare in modo esplicito l'OCID del nuovo cluster, anziché tutti i cluster nel compartimento. Ad esempio:

        resource.id = 'ocid1.cluster.oc1.iad.aaaaaaaaaf______yg5q'

Rotazione della chiave di cifratura principale

Se si seleziona l'opzione per gestire manualmente la chiave di cifratura master, è possibile ruotare la chiave di cifratura master nel servizio Vault, creando una nuova versione della chiave di cifratura master (vedere Rotating a Vault Key).

In questa situazione, la chiave di cifratura master non viene eliminata (la risorsa della chiave di cifratura master continua a esistere, con lo stesso OCID), ma la chiave di cifratura master ha un nuovo valore. Tutti i nuovi segreti Kubernetes memorizzati per il cluster verranno cifrati utilizzando il nuovo valore della chiave di cifratura master. Tutti i segreti Kubernetes cifrati esistenti saranno comunque accessibili, perché la versione originale della chiave di cifratura master è ancora disponibile nel servizio Vault. Se desideri che i segreti Kubernetes esistenti vengano cifrati utilizzando la nuova versione della chiave di cifratura master, devi ruotare i segreti Kubernetes in modo che vengano cifrati di nuovo. Ad esempio, eseguendo il comando seguente:
kubectl get secrets --all-namespaces -o json | kubectl annotate --overwrite -f - encryption-key-rotation-time="<time>"

dove <time> è una stringa che indica quando eseguire la rotazione. Ad esempio:

kubectl get secrets --all-namespaces -o json | kubectl annotate --overwrite -f - encryption-key-rotation-time="20210909_2135"

Chiavi di cifratura principali in altre tenancy

È possibile creare un cluster in una tenancy che utilizza una chiave di cifratura master in una tenancy diversa. In questo caso, è necessario scrivere criteri cross-tenancy per consentire al cluster nella propria tenancy di accedere alla chiave di cifratura master nella tenancy del servizio Vault. Tenere presente che se si desidera creare un cluster e specificare una chiave di cifratura master che si trova in una tenancy diversa, non è possibile utilizzare la console per creare il cluster.

Ad esempio, si supponga che il cluster si trovi in ClusterTenancy e che la chiave di cifratura master sia in KeyTenancy. Gli utenti appartenenti a un gruppo (OKEAdminGroup) in ClusterTenancy dispongono delle autorizzazioni per creare i cluster. Nel cluster è stato creato un gruppo dinamico (OKEAdminDynGroup) con la regola ALL {resource.type = 'cluster', resource.compartment.id = 'ocid1.compartment.oc1..<unique_ID>'}, pertanto tutti i cluster creati nel file ClusterTenancy appartengono al gruppo dinamico.

Nel compartimento radice di KeyTenancy, i criteri seguenti:

  • utilizzare l'OCID di ClusterTenancy per mappare ClusterTenancy all'alias OKE_Tenancy
  • utilizzare gli OCID di OKEAdminGroup e OKEAdminDynGroup per mapparli rispettivamente agli alias RemoteOKEAdminGroup e RemoteOKEClusterDynGroup
  • offrire a RemoteOKEAdminGroup e RemoteOKEClusterDynGroup la possibilità di elencare, visualizzare ed eseguire operazioni crittografiche con una particolare chiave master in KeyTenancy
Define tenancy OKE_Tenancy as ocid1.tenancy.oc1..<unique_ID>
Define dynamic-group RemoteOKEClusterDynGroup as ocid1.dynamicgroup.oc1..<unique_ID>
Define group RemoteOKEAdminGroup as ocid1.group.oc1..<unique_ID>
Admit dynamic-group RemoteOKEClusterDynGroup of tenancy ClusterTenancy to use keys in tenancy where target.key.id = 'ocid1.key.oc1..<unique_ID>'
Admit group RemoteOKEAdminGroup of tenancy ClusterTenancy to use keys in tenancy where target.key.id = 'ocid1.key.oc1..<unique_ID>'

Nel compartimento radice di ClusterTenancy, i criteri seguenti:

  • utilizzare l'OCID di KeyTenancy per mappare KeyTenancy all'alias KMS_Tenancy
  • assegnare a OKEAdminGroup e OKEAdminDynGroup la possibilità di utilizzare le chiavi master in KeyTenancy
  • consentire a OKEAdminDynGroup di utilizzare una chiave master specifica ottenuta da KeyTenancy nel file ClusterTenancy
Define tenancy KMS_Tenancy as ocid1.tenancy.oc1..<unique_ID>
Endorse group OKEAdminGroup to use keys in tenancy KMS_Tenancy
Endorse dynamic-group OKEAdminDynGroup to use keys in tenancy KMS_Tenancy
Allow dynamic-group OKEAdminDynGroup to use keys in tenancy where target.key.id = 'ocid1.key.oc1..<unique_ID>'

Per ulteriori esempi sulla scrittura di criteri cross-tenancy, vedere Accesso alle risorse di storage degli oggetti tra tenancy.

Dopo aver immesso i criteri, è ora possibile eseguire un comando simile al seguente per creare un cluster in ClusterTenancy che utilizza la chiave master ottenuta da KeyTenancy:
oci ce cluster create --name oke-with-cross-kms --kubernetes-version v1.16.8 --vcn-id ocid1.vcn.oc1.iad.<unique_ID> --service-lb-subnet-ids '["ocid1.subnet.oc1.iad.<unique_ID>"]' --compartment-id ocid1.compartment.oc1..<unique_ID> --kms-key-id ocid1.key.oc1.iad.<unique_ID>