Documentation Oracle Cloud Infrastructure

Cyrptage de clés secrètes Kubernetes inactives dans etcd

Découvrez comment crypter les données de configuration stockées en tant que clés secrètes Kubernetes dans etcd lors de l'utilisation de Container Engine for Kubernetes (OKE).

Le plan de contrôle de cluster Kubernetes stocke les données de configuration sensibles (telles que les jetons d'authentification, les certificats et les informations d'identification) en tant qu'objets de clé secrète Kubernetes dans etcd. etcd est une banque clé-valeur distribuée open source utilisée par Kubernetes pour la coordination des clusters et la gestion des états. Dans les clusters Kubernetes créés par Container Engine for Kubernetes, etcd écrit et lit les données vers des volumes de stockage de blocs du service Oracle Cloud Infrastructure Block Volume ainsi qu'à partir de ceux-ci. Par défaut, Oracle chiffre les données des volumes de blocs inactifs, notamment les clés secrètes etcd et Kubernetes. Oracle gère ce cryptage par défaut à l'aide d'une clé de cryptage maître, sans aucune action de votre part. Pour plus de contrôle sur le cycle de vie de la clé de cryptage maître et sur son utilisation, vous pouvez choisir de gérer vous-même la clé de cryptage maître au lieu d'avoir Oracle à la gérer pour vous.

Si vous choisissez de gérer vous-même la clé de cryptage maître, vous indiquez la clé à utiliser et vous avez le contrôle du moment où la clé fait l'objet d'une rotation. La clé de cryptage maître est stockée dans le service Oracle Cloud Infrastructure Vault (reportez-vous à Key Management). Les clés secrètes Kubernetes inactives dans etcd sont cryptées à l'aide d'une clé de cryptage de données (DEK) à l'aide de l'algorithme de cryptage AES-CBC avec remplissage PKCS#7. Une nouvelle DEK est générée pour chaque chiffrement. Les clés de cryptage de données sont cryptées à l'aide de la clé de cryptage maître (MEK), un concept connu sous le nom de cryptage d'enveloppe.

Avant de créer un cluster pour lequel vous souhaitez gérer vous-même la clé de cryptage maître, vous devez :

  • Créer une clé de cryptage maître appropriée dans Vault (ou obtenir le nom et l'OCID d'une telle clé)
  • Créez un groupe dynamique incluant tous les clusters du compartiment dans lequel vous voulez créer le cluster
  • Créez une stratégie autorisant le groupe dynamique à utiliser la clé de cryptage maître.

Une fois que vous avez créé le cluster et spécifié que vous souhaitez gérer la clé de cryptage maître vous-même, vous pouvez éventuellement restreindre l'utilisation de la clé de cryptage maître en modifiant le groupe dynamique afin d'inclure uniquement ce cluster.

Tenez compte des éléments suivants :

  • Vous pouvez uniquement sélectionner l'option permettant de gérer vous-même la clé de cryptage maître lors de la création d'un cluster dans le workflow 'Création personnalisée'. Vous ne pouvez pas choisir de gérer la clé de cryptage maître lors de la création d'un cluster dans le workflow "Création rapide". En outre, vous ne pouvez pas choisir de gérer les clés de cryptage maître pour les clusters créés précédemment dans le workflow 'Création personnalisée'.
Attention

Si vous sélectionnez l'option permettant de gérer vous-même la clé de cryptage maître, ne supprimez pas la clé de cryptage maître dans le service Vault. Dès que vous programmez la suppression d'une clé dans Vault, les clés secrètes Kubernetes stockées pour le cluster dans etcd deviennent inaccessibles. Si vous avez déjà programmé la suppression de la clé, celle-ci est peut-être toujours en attente de suppression. Si tel est le cas, annulez la suppression programmée de la clé (reportez-vous à Annulation d'une suppression de clé de cryptage maître) afin de restaurer l'accès aux clés secrètes Kubernetes. Si vous laissez la suppression programmée de la clé aboutir et que la clé de cryptage maître est supprimée, les clés secrètes Kubernetes stockées pour le cluster dans etcd deviennent définitivement inaccessibles. Par conséquent, les mises à niveau du cluster échoueront. Dans ce cas, vous n'avez pas d'autre choix que de supprimer et de recréer le cluster.

Configuration de l'accès à la clé de cryptage maître

Si vous choisissez de gérer la clé de cryptage maître qui chiffre les clés secrètes Kubernetes dans la banque clé-valeur etcd du cluster lors de la création d'un cluster dans le workflow 'Création personnalisée', configurez l'accès à la clé de cryptage maître :

  1. Connectez-vous à la console.

  2. Si vous connaissez l'OCID de la clé de cryptage maître à utiliser pour crypter les clés secrètes Kubernetes, passez directement à l'étape suivante. Sinon :

    • Si une clé de cryptage maître appropriée existe déjà dans Vault, mais que vous n'êtes pas sûr de connaître son OCID, suivez les instructions fournies dans Liste des clés de cryptage maître et notez l'OCID de la clé de cryptage maître.
    • Si une clé de cryptage maître appropriée n'existe pas déjà dans Vault, suivez les instructions fournies dans Création d'une clé de cryptage maître pour en créer une, en définissant :
      • Protection Mode to Software or HSM.
      • Forme de clé : algorithme vers AES, RSA ou ECDSA.
      • Forme de clé : longueur pour les clés AES (128, 256) et RSA (2048, 3072, 4096) ou Forme de clé : ID de courbe pour les clés ECDSA (NIST_P256, NIST_P384, NIST_P521).
      Une fois que vous avez créé une clé de cryptage maître, notez son OCID.

  3. Accordez l'accès à la clé de cryptage maître dans Vault.

    Vous pouvez accorder l'accès à la clé de cryptage maître de deux manières :

    Création d'une stratégie IAM (recommandé)
    1. Ouvrez le menu de navigation et cliquez sur Identité et sécurité. Sous Identité, cliquez sur Stratégies.
    2. Suivez les instructions dans Procédure de création d'une stratégie et nommez la stratégie (par exemple, acme-oke-kms-policy).

    3. Entrez une instruction de stratégie au format suivant pour autoriser l'accès à la clé de cryptage maître :

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

      où :

      • <compartment-name> est le nom du compartiment contenant la clé de cryptage maître.
      • <key-OCID> est l'OCID de la clé de cryptage maître dans Vault.

      Par exemple :

      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. Cliquez sur Créer pour créer la stratégie.
    Créer un groupe dynamique, puis créer une stratégie IAM
    1. Ouvrez le menu de navigation et cliquez sur Identité et sécurité. Sous Identité, cliquez sur Domaines. Sous Domaine d'identité, cliquez sur Groupes dynamiques.
    2. Suivez les instructions fournies dans Procédure de création d'un groupe dynamique et donnez un nom au groupe dynamique (par exemple, acme-oke-kms-dyn-grp).

    3. Entrez une règle qui inclut tous les clusters du compartiment au format suivant :

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

      où <compartment-ocid> est l'OCID du compartiment dans lequel vous avez l'intention de créer le cluster.

      Par exemple :

      ALL {resource.type = 'cluster', resource.compartment.id = 'ocid1.compartment.oc1..aaaaaaaa23______smwa'}
    4. Cliquez sur Créer un groupe dynamique.

      Une fois que vous avez créé un groupe dynamique incluant tous les clusters du compartiment, vous pouvez créer une stratégie afin d'autoriser le groupe dynamique à accéder à la clé de cryptage maître dans Vault.

    5. Ouvrez le menu de navigation et cliquez sur Identité et sécurité. Sous Identité, cliquez sur Stratégies.
    6. Suivez les instructions fournies dans Procédure de création d'une stratégie et donnez un nom à la stratégie (par exemple, acme-oke-kms-dyn-grp-policy).

    7. Entrez une instruction de stratégie au format suivant pour autoriser le groupe dynamique à accéder à la clé de cryptage maître :

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

      où :

      • <dynamic-group-name> est le nom du groupe dynamique créé précédemment.
      • <compartment-name> est le nom du compartiment contenant la clé de cryptage maître.
      • <key-OCID> est l'OCID de la clé de cryptage maître dans Vault.

      Par exemple :

      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. Cliquez sur Créer pour créer la stratégie.

  4. Lorsque vous créez un cluster, sélectionnez l'option Crypter à l'aide d'une clé que vous gérez et indiquez la clé de cryptage maître (reportez-vous à Utilisation de la console pour créer un cluster avec des paramètres définis explicitement dans le workflow Création personnalisée).

  5. (Facultatif) Une fois le cluster créé, effectuez les opérations suivantes pour plus de sécurité :

    1. Notez l'OCID du cluster que vous venez de créer.

    2. Limitez l'utilisation de la clé de cryptage maître :

      • si vous avez simplement créé une stratégie IAM, modifiez l'instruction de stratégie pour inclure explicitement l'OCID du nouveau cluster, plutôt que tous les clusters du compartiment. Par exemple :

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

      • Si vous avez créé un groupe dynamique, modifiez la règle de groupe dynamique créée précédemment afin d'indiquer explicitement l'OCID du nouveau cluster, plutôt que tous les clusters du compartiment. Par exemple :

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

Rotation de la clé de cryptage maître

Si vous sélectionnez l'option permettant de gérer vous-même la clé de cryptage maître, vous pouvez effectuer la rotation de cette dernière dans le service Vault, en créant une nouvelle version de la clé de cryptage maître (reportez-vous à Rotation d'une clé de coffre).

Dans ce cas, la clé de cryptage maître n'est pas elle-même supprimée (la ressource de clé de cryptage maître continue d'exister, avec le même OCID), mais la clé de cryptage maître a une nouvelle valeur. Toutes les nouvelles clés secrètes Kubernetes stockées pour le cluster seront cryptées à l'aide de la nouvelle valeur de la clé de cryptage maître. Toutes les clés secrètes Kubernetes cryptées existantes restent accessibles, car la version d'origine de la clé de cryptage maître est toujours disponible dans le service Vault. Si vous souhaitez que les clés secrètes Kubernetes existantes soient cryptées à l'aide de la nouvelle version de la clé de cryptage maître, vous devez effectuer la rotation des clés secrètes Kubernetes afin qu'elles soient à nouveau cryptées. Par exemple, exécutez la commande suivante :
kubectl get secrets --all-namespaces -o json | kubectl annotate --overwrite -f - encryption-key-rotation-time="<time>"

où <time> est une chaîne indiquant quand effectuer la rotation. Par exemple :

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

Clés de cryptage maître dans d'autres locations

Vous pouvez créer dans une location un cluster utilisant une clé de cryptage maître d'une autre location. Dans ce cas, vous devez écrire des stratégies inter-locations pour permettre au cluster dans sa location d'accéder à la clé de cryptage maître dans la location du service Vault. Si vous souhaitez créer un cluster et spécifier une clé de cryptage maître se trouvant dans une autre location, vous ne pouvez pas utiliser la console pour créer le cluster.

Par exemple, supposons que le cluster se trouve dans ClusterTenancy et la clé de cryptage maître dans KeyTenancy. Les utilisateurs appartenant à un groupe (OKEAdminGroup) de ClusterTenancy disposent des droits d'accès nécessaires pour créer des clusters. Un groupe dynamique (OKEAdminDynGroup) a été créé dans le cluster, avec la règle ALL {resource.type = 'cluster', resource.compartment.id = 'ocid1.compartment.oc1..<unique_ID>'}. Tous les clusters créés dans ClusterTenancy appartiennent donc au groupe dynamique.

Dans le compartiment racine de KeyTenancy, les stratégies suivantes :

  • utilisent l'OCID de ClusterTenancy pour mettre en correspondance ClusterTenancy avec l'alias OKE_Tenancy,
  • utilisent les OCID d'OKEAdminGroup et d'OKEAdminDynGroup pour les mettre en correspondance avec les alias RemoteOKEAdminGroup et RemoteOKEClusterDynGroup respectivement,
  • donnent à RemoteOKEAdminGroup et RemoteOKEClusterDynGroup la possibilité de répertorier, de visualiser et d'effectuer des opérations cryptographiques avec une clé maître particulière de 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>'

Dans le compartiment racine de ClusterTenancy, les stratégies suivantes :

  • utilisent l'OCID de KeyTenancy pour mettre en correspondance KeyTenancy avec l'alias KMS_Tenancy,
  • donnent à OKEAdminGroup et à OKEAdminDynGroup la possibilité d'utiliser des clés maître de KeyTenancy,
  • permettent à OKEAdminDynGroup d'utiliser une clé maître spécifique obtenue à partir de KeyTenancy dans 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>'

Pour plus d'exemples d'écriture de stratégies inter-locations, reportez-vous à Accès aux ressources Object Storage dans des locations.

Une fois les stratégies entrées, vous pouvez exécuter une commande semblable à la suivante pour créer dans ClusterTenancy un cluster utilisant la clé maître obtenue à partir de 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>