Chiffrement des clés secrètes Kubernetes au repos dans etcd
Découvrez comment chiffrer les données de configuration stockées en tant que clés secrètes Kubernetes dans etcd lors de l'utilisation du moteur Kubernetes (OKE).
Le plan de contrôle de la grappe Kubernetes stocke les données de configuration sensibles (comme les jetons d'authentification, les certificats et les données d'identification) en tant qu'objets de clé secrète Kubernetes dans etcd. Etcd est un magasin de valeurs de clés distribué à code source libre, utilisé par Kubernetes pour la coordination et la gestion des états des grappes. Dans les grappes Kubernetes créées par Kubernetes Engine, etcd écrit et lit les données vers et depuis les volumes de stockage par blocs dans le service Oracle Cloud Infrastructure Block Volume. Par défaut, Oracle chiffre les données des volumes par blocs au repos, notamment les clés secrètes etcd et Kubernetes. Oracle gère ce chiffrement par défaut à l'aide d'une clé de chiffrement principale, sans aucune action de votre part. Pour un contrôle supplémentaire sur le cycle de vie de la clé de chiffrement principale et sur la façon dont elle est utilisée, vous pouvez choisir de la gérer vous-même, plutôt qu'Oracle de la gérer pour vous.
Si vous choisissez de gérer vous-même la clé de chiffrement principale, vous spécifiez la clé à utiliser et vous avez le contrôle du moment de la rotation de la clé. La clé de chiffrement principale est stockée dans le service Oracle Cloud Infrastructure Vault (voir Gestion des clés). Les clés secrètes Kubernetes au repos dans etcd sont chiffrées à l'aide d'une clé de chiffrement des données (DEK) à l'aide de l'algorithme de chiffrement AES-CBC avec remplissage PKCS#7. Une nouvelle clé DEK est générée pour chaque cryptage. Les clés de chiffrement des données sont chiffrées à l'aide de la clé de chiffrement principale (la clé MEK), un concept connu sous le nom de chiffrement d'enveloppe.
Avant de créer une grappe pour laquelle vous voulez gérer vous-même la clé de chiffrement principale, vous devez :
- créer une clé de chiffrement principale appropriée dans la chambre forte (ou obtenir le nom et l'OCID d'une telle clé)
- créer un groupe dynamique contenant toutes les grappes du compartiment dans lequel vous allez créer la nouvelle grappe
- créer une politique qui autorise le groupe dynamique à utiliser la clé de chiffrement principale
Une fois que vous avez créé la grappe et spécifié que vous voulez gérer vous-même la clé de chiffrement principale, vous pouvez éventuellement restreindre l'utilisation de la clé de chiffrement principale en modifiant le groupe dynamique pour qu'il contienne uniquement cette grappe.
Notez ce qui suit :
- Vous ne pouvez sélectionner l'option permettant de gérer vous-même la clé de chiffrement principale que lors de la création d'une grappe dans le flux de création personnalisée. Vous ne pouvez pas choisir de gérer la clé de chiffrement principale lors de la création d'une grappe dans le flux de création rapide. Vous ne pouvez pas non plus choisir de gérer les clés de chiffrement principales pour les grappes que vous avez créées précédemment dans le flux de création personnalisée.
Si vous sélectionnez vous-même l'option de gestion de la clé de chiffrement principale, ne supprimez pas la clé de chiffrement principale dans le service de chambre forte. Dès qu'une clé est programmée pour suppression dans le service de chambre forte, les clés secrètes Kubernetes stockées pour la grappe dans etcd deviennent inaccessibles. Si vous avez déjà programmé la clé pour suppression, il est possible qu'elle soit encore à l'état Suppression en attente. Si tel est le cas, annulez la suppression programmée de la clé (voir Annulation d'une suppression de clé de chiffrement principale) pour rétablir l'accès aux clés secrètes Kubernetes. Si vous autorisez l'exécution de l'opération de suppression programmée de la clé et la suppression de la clé de chiffrement principale, les clés secrètes Kubernetes stockées pour la grappe dans etcd deviennent inaccessibles de manière permanente. Les mises à niveau des grappes ne peuvent plus aboutir. Dans cette situation, vous n'avez pas d'autre choix que de supprimer et de recréer la grappe.
Configuration de l'accès à la clé de chiffrement principale
Si vous choisissez de gérer la clé de chiffrement principale qui chiffre les clés secrètes Kubernetes dans le magasin de valeurs de clés etcd de la grappe lors de la création d'une nouvelle grappe dans le flux de création personnalisée, configurez l'accès à la clé de chiffrement principale :
- Connectez-vous à la console.
-
Si vous connaissez l'OCID de la clé de chiffrement principale à utiliser pour chiffrer les clés secrètes Kubernetes, passez directement à l'étape suivante. Sinon :
- Si une clé de chiffrement principale appropriée existe déjà dans la chambre forte mais que vous ne connaissez pas son OCID, suivez les instructions sous Liste des clés de chiffrement principales et notez l'OCID de la clé de chiffrement principale.
- Si aucune clé de chiffrement principale appropriée n'existe dans le service de chambre forte, suivez les instructions sous Création d'une clé de chiffrement principale pour en créer une, paramètre :
- Mode de protection pour le logiciel ou le module de sécurité matériel.
- Forme clé : Algorithme pour AES, RSA ou ECDSA.
- Forme de clé : Longueur pour les clés AES (128, 256) et les clés RSA (2048, 3072, 4096) ou Forme de clé : ID courbe pour les clés ECDSA (NIST_P256, NIST_P384, NIST_P521).
-
Accorder l'accès à la clé de chiffrement principale dans la chambre forte.
Vous pouvez accorder l'accès à la clé de chiffrement principale de deux manières :
Créer une nouvelle politique IAM (recommandé)- Ouvrez le menu de navigation et sélectionnez Identité et sécurité. Sous identité, sélectionnez Politiques.
- Suivez les instructions sous Pour créer une politique et donnez un nom à la politique (par exemple,
acme-oke-kms-policy
). -
Entrez un énoncé pour autoriser l'accès à la clé de chiffrement principale, dans le format suivant :
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 chiffrement principale.<key-OCID>
est l'OCID de la clé de chiffrement principale dans le service de chambre forte.
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'}
- Sélectionnez Créer pour créer la politique.
Créer un nouveau groupe dynamique, puis créer une nouvelle politique IAM- Ouvrez le menu de navigation et sélectionnez Identité et sécurité. Sous Identité, sélectionnez Domaines. Sous Domaine d'identité, sélectionnez Groupes dynamiques.
- Suivez les instructions de la rubrique Pour créer un groupe dynamique et attribuez un nom au groupe dynamique (par exemple,
acme-oke-kms-dyn-grp
). -
Entrez une règle incluant toutes les grappes du compartiment dans le format :
ALL {resource.type = 'cluster', resource.compartment.id = '<compartment-ocid>'}
où
<compartment-ocid>
est l'OCID du compartiment dans lequel vous prévoyez de créer la nouvelle grappe.Par exemple :
ALL {resource.type = 'cluster', resource.compartment.id = 'ocid1.compartment.oc1..aaaaaaaa23______smwa'}
- Sélectionnez Créer un groupe dynamique.
Après avoir créé un groupe dynamique incluant toutes les grappes du compartiment, vous pouvez créer une politique pour autoriser ce groupe à accéder à la clé de chiffrement principale dans le service de chambre forte.
- Ouvrez le menu de navigation et sélectionnez Identité et sécurité. Sous identité, sélectionnez Politiques.
- Suivez les instructions de la rubrique Pour créer une politique et attribuez un nom à la politique (par exemple,
acme-oke-kms-dyn-grp-policy
). -
Entrez un énoncé pour autoriser le groupe dynamique à accéder à la clé de chiffrement principale, dans le format suivant :
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 que vous avez créé précédemment.<compartment-name>
est le nom du compartiment contenant la clé de chiffrement principale.<key-OCID>
est l'OCID de la clé de chiffrement principale dans le service de chambre forte.
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'
- Sélectionnez Créer pour créer la politique.
-
Lorsque vous créez une grappe, sélectionnez l'option Chiffrer à l'aide d'une clé que vous gérez et spécifiez la clé de chiffrement principale (voir Utilisation de la console pour créer une grappe avec des paramètres définis explicitement dans le flux de création personnalisée).
-
(Facultatif) Après avoir créé la grappe, pour plus de sécurité :
- Notez l'OCID de la grappe que vous venez de créer.
-
Restreindre l'utilisation de la clé de chiffrement principale :
-
si vous avez simplement créé une politique IAM, modifiez l'énoncé de politique pour inclure explicitement l'OCID de la nouvelle grappe, plutôt que toutes les grappes 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 que vous avez créée précédemment pour spécifier explicitement l'OCID de la nouvelle grappe, plutôt que toutes les grappes du compartiment. Par exemple :
resource.id = 'ocid1.cluster.oc1.iad.aaaaaaaaaf______yg5q'
-
Rotation de la clé de chiffrement principale
Si vous sélectionnez vous-même l'option pour gérer la clé de chiffrement principale, vous pouvez effectuer la rotation de la clé de chiffrement principale dans le service de chambre forte, en créant une nouvelle version de la clé de chiffrement principale (voir Rotation d'une clé de chambre forte).
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 principales de chiffrement dans d'autres locations
Vous pouvez créer une grappe dans une location qui utilise une clé principale de chiffrement dans une location différente. Dans ce cas, vous devez écrire des politiques interlocations pour permettre à la grappe dans sa location d'accéder à la clé de chiffrement principale de la location du service de chambre forte. Notez que si vous voulez créer une grappe et spécifier une clé principale de chiffrement située dans une location différente, vous ne pouvez pas utiliser la console pour créer la grappe.
Par exemple, supposons que la grappe se trouve dans ClusterTenancy et que la clé principale de chiffrement se trouve dans KeyTenancy. Les utilisateurs appartenant à un groupe (OKEAdminGroup) dans ClusterTenancy sont autorisés à créer des grappes. Un groupe dynamique (OKEAdminDynGroup) a été créé dans la grappe, avec la règle ALL {resource.type = 'cluster', resource.compartment.id = 'ocid1.compartment.oc1..<unique_ID>'}
, de sorte que toutes les grappes créées dans ClusterTenancy appartiennent au groupe dynamique.
Dans le compartiment racine de KeyTenancy, les politiques suivantes :
- Utilisent l'OCID de ClusterTenancy pour mapper ClusterTenancy à l'alias OKE_Tenancy
- Utilisent les OCID d'OKEAdminGroup et OKEAdminDynGroup pour les mapper aux alias RemoteOKEAdminGroup et RemoteOKEClusterDynGroup, respectivement
- Donnent à RemoteOKEAdminGroup et RemoteOKEClusterDynGroup la possibilité de lister, voir et exécuter des opérations cryptographiques avec une clé principale spécifique dans 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 politiques suivantes :
- Utilisent l'OCID de KeyTenancy pour mapper KeyTenancy à l'alias KMS_Tenancy
- Donnent à OKEAdminGroup et OKEAdminDynGroup la possibilité d'utiliser les clés principales dans KeyTenancy
- Permettent à OKEAdminDynGroup d'utiliser une clé principale 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>'
Voir Accès aux ressources de stockage d'objets entre des locations pour plus d'exemples d'écriture de politiques interlocations.
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>