Aidez à améliorer cette page

Pour contribuer à ce guide de l’utilisateur, cliquez sur le lien Modifier cette page sur GitHub qui se trouve dans le volet droit de chaque page.

Chiffrement d’enveloppe par défaut pour toutes les données de l’API Kubernetes

Amazon Elastic Kubernetes Service (Amazon EKS) fournit un chiffrement par défaut pour toutes les données API Kubernetes dans les clusters EKS exécutant la version 1.28 ou supérieure de Kubernetes.

Le chiffrement des enveloppes protège les données que vous stockez avec le serveur d’API Kubernetes. Par exemple, le chiffrement d’enveloppe s’applique à la configuration de votre cluster Kubernetes, par exemple ConfigMaps. Le chiffrement des enveloppes ne s’applique pas aux données des nœuds ou des volumes EBS. EKS prenait déjà en charge le chiffrement des secrets Kubernetes, et désormais, ce chiffrement par enveloppe s’étend à toutes les données API Kubernetes.

Cela fournit une expérience gérée par défaut, qui implémente la défense en profondeur pour vos applications Kubernetes et ne nécessite aucune action de votre part.

Amazon EKS utilise AWS Key Management Service (KMS) avec le fournisseur Kubernetes KMS v2 pour cette couche de sécurité supplémentaire avec une clé appartenant à Amazon Web Services, et vous offre la possibilité d’utiliser votre propre clé gérée par le client (CMK) provenant de AWS KMS.

Comprendre le chiffrement d’enveloppe

Le chiffrement d’enveloppe consiste à chiffrer les données en texte clair à l’aide d’une clé de chiffrement des données (DEK) avant leur envoi vers l’entrepôt de données (etcd), puis à chiffrer la DEK à l’aide d’une clé KMS racine stockée dans un système KMS distant et géré de manière centralisée (AWS KMS). Il s’agit d’une stratégie de défense en profondeur, car elle protège les données à l’aide d’une clé de chiffrement (DEK), puis ajoute une couche de sécurité supplémentaire en protégeant cette DEK à l’aide d’une clé de chiffrement distincte et stockée de manière sécurisée, appelée clé de chiffrement de clé (KEK).

Comment Amazon EKS active le chiffrement par défaut des enveloppes avec KMS v2 et AWS KMS

Amazon EKS utilise KMS v2 pour mettre en œuvre le chiffrement par défaut de toutes les données API dans le plan de contrôle Kubernetes géré avant leur conservation dans la base de données etcd. Au démarrage, le serveur API du cluster génère une clé de chiffrement des données (DEK) à partir d’une graine secrète combinée à des données générées aléatoirement. Au démarrage également, le serveur API appelle le plug-in KMS pour chiffrer la graine DEK à l’aide d’une clé de chiffrement de clé (KEK) distante provenant de AWS KMS. Il s’agit d’un appel ponctuel exécuté au démarrage du serveur API et lors de la rotation du KEK. Le serveur API met ensuite en cache la graine DEK chiffrée. Après cela, le serveur API utilise la graine DEK mise en cache pour générer d’autres DEK à usage unique basés sur une fonction de dérivation de clé (KDF). Chacun de ces DEK générés n’est ensuite utilisé qu’une seule fois pour chiffrer une seule ressource Kubernetes avant d’être stocké dans etcd. Grâce à l’utilisation d’une graine DEK cryptée mise en cache dans KMS v2, le processus de cryptage des ressources Kubernetes dans le serveur API est à la fois plus performant et plus rentable.

Par défaut, ce KEK appartient à AWS, mais vous pouvez éventuellement apporter le vôtre depuis AWS KMS.

Le schéma ci-dessous décrit la génération et le chiffrement d’un DEK au démarrage du serveur d’API.

Le schéma de haut niveau ci-dessous décrit le chiffrement d’une ressource Kubernetes avant son stockage dans etcd.

Questions fréquentes (FAQ)

Comment le chiffrement d’enveloppe par défaut améliore-t-il le niveau de sécurité de mon cluster EKS ?

Cette fonctionnalité réduit la surface et la durée pendant lesquelles les métadonnées et le contenu client ne sont pas cryptés. Avec le chiffrement par défaut des enveloppes, les métadonnées et le contenu client ne sont temporairement déchiffrés que dans la mémoire du kube-apiserver avant d’être stockés dans etcd. La mémoire du kube-apiserver est sécurisée grâce au système Nitro. Amazon EKS utilise uniquement des instances EC2 basées sur Nitro pour le plan de contrôle Kubernetes géré. Ces instances sont dotées de dispositifs de contrôle de sécurité qui empêchent tout système ou toute personne d’accéder à leur mémoire.

Quelle version de Kubernetes dois-je exécuter pour bénéficier de cette fonctionnalité ?

Pour que le chiffrement par défaut des enveloppes soit activé, votre cluster Amazon EKS doit exécuter Kubernetes version 1.28 ou ultérieure.

Mes données sont-elles toujours sécurisées si j’utilise une version de cluster Kubernetes qui ne prend pas en charge cette fonctionnalité ?

Oui. Chez AWS, la sécurité est notre priorité absolue. Nous basons toute notre transformation numérique et notre innovation sur les pratiques opérationnelles les plus strictes en matière de sécurité, et nous nous engageons à relever encore davantage la barre.

Toutes les données stockées dans etcd sont chiffrées au niveau du disque pour chaque cluster EKS, quelle que soit la version de Kubernetes utilisée. EKS utilise des clés racines qui génèrent des clés de chiffrement de volume gérées par le service EKS. De plus, chaque cluster Amazon EKS est exécuté dans un VPC isolé à l’aide de machines virtuelles spécifiques au cluster. Grâce à cette architecture et à nos pratiques en matière de sécurité opérationnelle, Amazon EKS a obtenu plusieurs certifications et normes de conformité, notamment SOC 1, 2 et 3, PCI-DSS, ISO et HIPAA. Ces notes et normes de conformité sont maintenues pour tous les clusters EKS, avec ou sans chiffrement d’enveloppe par défaut.

Comment fonctionne le chiffrement des enveloppes dans Amazon EKS ?

Au démarrage, le serveur API du cluster génère une clé de chiffrement des données (DEK) à partir d’une graine secrète combinée à des données générées aléatoirement. Au démarrage également, le serveur API appelle le plug-in KMS pour chiffrer le DEK à l’aide d’une clé de chiffrement de clé (KEK) distante provenant d’AWS KMS. Il s’agit d’un appel ponctuel exécuté au démarrage du serveur API et lors de la rotation du KEK. Le serveur API met ensuite en cache la graine DEK chiffrée. Après cela, le serveur API utilise la graine DEK mise en cache pour générer d’autres DEK à usage unique basés sur une fonction de dérivation de clé (KDF). Chacun de ces DEK générés n’est ensuite utilisé qu’une seule fois pour chiffrer une seule ressource Kubernetes avant d’être stocké dans etcd.

Il est important de noter que des appels supplémentaires sont effectués depuis le serveur API afin de vérifier l’état et le fonctionnement normal de l’intégration AWS KMS. Ces contrôles de santé supplémentaires sont visibles dans votre AWS CloudTrail.

Dois-je effectuer une action ou modifier des autorisations pour que cette fonctionnalité fonctionne dans mon cluster EKS ?

Non, vous n’avez aucune démarche à effectuer. Le chiffrement des enveloppes dans Amazon EKS est désormais une configuration par défaut activée dans tous les clusters exécutant Kubernetes version 1.28 ou supérieure. L’intégration AWS KMS est établie par le serveur API Kubernetes géré par AWS. Cela signifie que vous n’avez pas besoin de configurer d’autorisations pour commencer à utiliser le chiffrement KMS pour votre cluster.

Comment savoir si le chiffrement d’enveloppe par défaut est activé sur mon cluster ?

Si vous migrez pour utiliser votre propre CMK, vous verrez alors l’ARN de la clé KMS associée à votre cluster. De plus, vous pouvez consulter les journaux d’événements AWS CloudTrail associés à l’utilisation du CMK de votre cluster.

Si votre cluster utilise une clé propriétaire AWS, cela sera indiqué dans la console EKS (à l’exception de l’ARN de la clé).

Est-ce que AWS peut accéder à la clé AWS propriétaire utilisée pour le chiffrement par défaut des enveloppes dans Amazon EKS ?

Non. AWS a mis en place des contrôles de sécurité stricts dans Amazon EKS qui empêchent toute personne d’accéder aux clés de chiffrement en clair utilisées pour sécuriser les données dans la base de données etcd. Ces mesures de sécurité sont également appliquées à la clé KMS détenue par AWS.

Le chiffrement d’enveloppe par défaut est-il activé dans mon cluster EKS existant ?

Si vous utilisez un cluster Amazon EKS avec la version 1.28 ou supérieure de Kubernetes, le chiffrement par enveloppe de toutes les données API Kubernetes est activé. Pour les clusters existants, Amazon EKS utilise le rôle eks:kms-storage-migrator RBAC ClusterRole pour migrer les données qui n’étaient pas précédemment chiffrées par enveloppe dans etcd vers ce nouvel état de chiffrement.

Qu’est-ce que cela signifie si j’ai déjà activé le chiffrement par enveloppe pour les secrets dans mon cluster EKS ?

Si vous disposez déjà d’une clé gérée par le client (CMK) dans KMS qui a été utilisée pour crypter vos secrets Kubernetes, cette même clé sera utilisée comme KEK pour le cryptage de tous les types de données API Kubernetes dans votre cluster.

Y a-t-il un coût supplémentaire pour l’exécution d’un cluster EKS avec le chiffrement par défaut des enveloppes ?

Il n’y a pas de coût supplémentaire associé au plan de contrôle Kubernetes géré si vous utilisez une clé appartenant à Amazon Web Services pour le chiffrement par défaut des enveloppes. Par défaut, chaque cluster EKS exécutant Kubernetes version 1.28 ou ultérieure utilise une clé appartenant à Amazon Web Service. Cependant, si vous utilisez votre propre clé AWS KMS, les tarifs KMS normaux s’appliqueront.

Combien coûte l’utilisation de ma propre clé AWS KMS pour chiffrer les données API Kubernetes dans mon cluster ?

Vous payez 1$ par mois pour stocker toute clé personnalisée que vous créez ou importez dans KMS. KMS facture les demandes de chiffrement et de déchiffrement. Il existe un forfait gratuit de 20 000 requêtes par mois et par compte. Au-delà de ce forfait gratuit, vous payez 0,03 $ par tranche de 10 000 requêtes supplémentaires par mois. Cela s’applique à toutes les utilisations AWS KMS d’un compte. Par conséquent, le coût d’utilisation de votre propre clé KMS sur votre cluster sera affecté par l’utilisation de cette clé sur d’autres clusters ou ressources AWS de votre compte.

Mes frais KMS seront-ils plus élevés maintenant que ma clé gérée par le client (CMK) est utilisée pour crypter toutes les données API Kubernetes et pas seulement les secrets ?

Non. Notre mise en œuvre avec KMS v2 réduit considérablement le nombre d’appels passés à AWS KMS. Cela permettra à son tour de réduire les coûts associés à votre CMK, indépendamment des données Kubernetes supplémentaires cryptées ou décryptées dans votre cluster EKS.

Comme indiqué ci-dessus, la clé DEK générée utilisée pour le chiffrement des ressources Kubernetes est stockée localement dans le cache du serveur API Kubernetes après avoir été chiffrée avec la clé KEK distante. Si la graine DEK chiffrée ne se trouve pas dans le cache du serveur API, celui-ci appellera AWS KMS pour chiffrer la graine DEK. Le serveur API met ensuite en cache la graine DEK chiffrée pour une utilisation future dans le cluster sans appeler KMS. De même, pour les demandes de déchiffrement, le serveur API appellera AWS KMS pour la première demande de déchiffrement, après quoi la graine DEK déchiffrée sera mise en cache et utilisée pour les futures opérations de déchiffrement.

Pour plus d’informations, consultez KEP-3299 : Améliorations KMS v2 dans les améliorations Kubernetes sur GitHub.

Puis-je utiliser la même clé CMK pour plusieurs clusters Amazon EKS ?

Oui. Pour réutiliser une clé, vous pouvez la lier à un cluster dans la même région en associant l’ARN au cluster lors de sa création. Toutefois, si vous utilisez la même CMK pour plusieurs clusters EKS, vous devez mettre en place les mesures nécessaires pour empêcher la désactivation arbitraire de la CMK. Sinon, une CMK désactivée associée à plusieurs clusters EKS aura un impact plus large sur les clusters en fonction de cette clé.

Qu’arrive-t-il à mon cluster EKS si ma clé CMK devient indisponible après l’activation du chiffrement d’enveloppe par défaut ?

Si vous désactivez une clé KMS, celle-ci ne peut plus être utilisée dans aucune opération cryptographique. Sans accès à une CMK existante, le serveur API ne pourra pas chiffrer et conserver les objets Kubernetes nouvellement créés, ni déchiffrer les objets Kubernetes précédemment chiffrés stockés dans etcd. Si la CMK est désactivée, le cluster sera immédiatement placé dans un état défaillant/dégradé, auquel cas nous ne serons plus en mesure de respecter notre engagement de service jusqu’à ce que vous réactiviez la CMK associée.

Lorsqu’une CMK est désactivée, vous recevrez des notifications concernant la dégradation de l’état de santé de votre cluster EKS et la nécessité de réactiver votre CMK dans les 30 jours suivant sa désactivation afin de garantir la restauration réussie de vos ressources du plan de contrôle Kubernetes.

Comment protéger mon cluster EKS de l’impact d’une clé CMK désactivée/supprimée ?

Pour protéger vos clusters EKS contre un tel événement, vos administrateurs clés doivent gérer l’accès aux opérations clés KMS à l’aide de politiques IAM basées sur le principe du moindre privilège afin de réduire le risque de désactivation ou de suppression arbitraire des clés associées aux clusters EKS. De plus, vous pouvez configurer une alerte CloudWatch pour être averti de l’état de votre CMK.

Mon cluster EKS sera-t-il restauré si je réactive le CMK ?

Pour garantir la réussite de la restauration de votre cluster EKS, nous vous recommandons vivement de réactiver votre CMK dans les 30 jours suivant sa désactivation. Cependant, la réussite de la restauration de votre cluster EKS dépendra également de l’existence ou non de modifications incompatibles avec l’API dues à une mise à niveau automatique de Kubernetes qui pourrait avoir lieu alors que le cluster est dans un état défaillant/dégradé.

Pourquoi mon cluster EKS est-il placé dans un état malsain/dégradé après avoir désactivé le CMK ?

Le serveur API du plan de contrôle EKS utilise une clé DEK qui est cryptée et mise en cache dans la mémoire du serveur API pour crypter tous les objets lors des opérations de création/mise à jour avant qu’ils ne soient stockés dans etcd. Lorsqu’un objet existant est récupéré depuis etcd, le serveur API utilise la même clé DEK mise en cache et déchiffre l’objet de ressource Kubernetes. Si vous désactivez la CMK, le serveur API ne subira aucun impact immédiat grâce à la clé DEK mise en cache dans la mémoire du serveur API. Cependant, lorsque l’instance du serveur API est redémarrée, elle ne dispose pas d’une clé DEK mise en cache et doit appeler AWS KMS pour les opérations de chiffrement et de déchiffrement. Sans CMK, ce processus échouera avec un code d’erreur KMS_KEY_DISABLED, empêchant le serveur API de démarrer correctement.

Qu’arrive-t-il à mon cluster EKS si je supprime mon CMK ?

La suppression de la clé CMK associée à votre cluster EKS dégradera son état de santé de manière irréversible. Sans la clé CMK de votre cluster, le serveur API ne sera plus en mesure de chiffrer et de conserver les nouveaux objets Kubernetes, ni de déchiffrer les objets Kubernetes précédemment chiffrés stockés dans la base de données etcd. Vous ne devez supprimer une clé CMK pour votre cluster EKS que lorsque vous êtes certain de ne plus avoir besoin d’utiliser ce cluster.

Veuillez noter que si la CMK est introuvable (KMS_KEY_NOT_FOUND) ou si les autorisations pour la CMK associée à votre cluster sont révoquées (KMS_GRANT_REVOKED), votre cluster ne pourra pas être restauré. Pour plus d’informations sur l’état du cluster et les codes d’erreur, consultez la FAQ sur l’état du cluster et les codes d’erreur avec les chemins de résolution.

Serai-je toujours facturé pour un cluster EKS dégradé/non fonctionnel parce que j’ai désactivé ou supprimé ma CMK ?

Oui. Bien que le plan de contrôle EKS ne soit pas utilisable en cas de désactivation de la CMK, AWS exécutera toujours des ressources d’infrastructure dédiées allouées au cluster EKS continueront de fonctionner jusqu’à ce qu’elles soient supprimées par le client. De plus, notre engagement de service ne s’appliquera pas dans une telle circonstance, car ce sera une action ou une inaction volontaire de la part du client qui empêchera le bon fonctionnement et la santé normale de votre cluster EKS.

Mon cluster EKS peut-il être automatiquement mis à niveau lorsqu’il est dans un état non fonctionnel/dégradé en raison d’une CMK désactivée ?

Oui. Toutefois, si votre cluster dispose d’une CMK désactivée, vous disposerez d’un délai de 30 jours pour la réactiver. Au cours de cette période de 30 jours, votre cluster Kubernetes ne sera pas automatiquement mis à niveau. Toutefois, si ce délai expire et que vous n’avez pas réactivé la CMK, le cluster sera automatiquement mis à niveau vers la version suivante (n+1) bénéficiant d’un support standard, conformément au cycle de vie des versions Kubernetes dans EKS.

Nous vous recommandons vivement de réactiver rapidement une CMK désactivée dès que vous constatez qu’un cluster est affecté. Il est important de noter que, bien qu’EKS mette automatiquement à niveau ces clusters concernés, rien ne garantit qu’ils seront restaurés avec succès, en particulier si le cluster subit plusieurs mises à niveau automatiques, car cela peut entraîner des modifications de l’API Kubernetes et un comportement inattendu dans le processus de démarrage du serveur API.

Puis-je utiliser un alias de clé KMS ?

Oui. Amazon EKS prend en charge l’utilisation des alias de clés KMS. Un alias est un nom convivial attribué à une clé KMS Amazon Web Service. Par exemple, un alias vous permet de faire référence à une clé KMS en tant que my-key au lieu de 1234abcd-12ab-34cd-56ef-1234567890ab .

Puis-je toujours sauvegarder et restaurer les ressources de mon cluster à l’aide de ma propre solution de sauvegarde Kubernetes ?

Oui. Vous pouvez utiliser une solution de sauvegarde Kubernetes (comme Velero) pour la reprise après sinistre, la migration des données et la protection des données du cluster Kubernetes. Si vous utilisez une solution de sauvegarde Kubernetes qui accède aux ressources du cluster via le serveur API, toutes les données récupérées par l’application seront déchiffrées avant d’atteindre le client. Cela vous permettra de récupérer les ressources du cluster dans un autre cluster Kubernetes.