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 s'implémente defense-in-depth pour vos applications Kubernetes et ne nécessite aucune action de votre part.

Amazon EKS utilise le service de gestion des AWS clés (KMS) avec le fournisseur Kubernetes KMS v2 pour cette couche de sécurité supplémentaire avec une clé appartenant à Amazon Web Services et la possibilité pour vous d'apporter votre propre clé gérée par le client (CMK) auprès de KMS. AWS

Comprendre le chiffrement d’enveloppe

Le chiffrement d'enveloppe consiste à chiffrer des données en texte brut à l'aide d'une clé de chiffrement des données (DEK) avant leur envoi à la banque de données (etcd), puis à chiffrer la DEK avec une clé KMS racine stockée dans un système KMS (KMS) distant géré de manière centralisée (KMS).AWS Il s'agit d'une defense-in-depth stratégie car elle protège les données à l'aide d'une clé de chiffrement (DEK), puis ajoute une autre couche de sécurité en protégeant cette DEK avec une clé de chiffrement séparée et stockée de manière sécurisée appelée clé de chiffrement (KEK).

Comment Amazon EKS active le chiffrement d'enveloppe par défaut 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 d'API appelle le plug-in KMS pour chiffrer le seed DEK à l'aide d'une clé de chiffrement par clé distante (KEK) fournie par 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. Ensuite, le serveur API utilise la graine DEK mise en cache pour générer d'autres données à usage unique DEKs basées sur une fonction de dérivation de clés (KDF). Chacun de ces éléments générés n' DEKs est ensuite utilisé qu'une seule fois pour chiffrer une seule ressource Kubernetes avant qu'elle ne soit stockée 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 KMS AWS, mais vous pouvez éventuellement apporter le vôtre.

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 EC2 instances 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 d'API appelle le plug-in KMS pour chiffrer le DEK à l'aide d'une clé de chiffrement à distance (KEK) fournie par 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. Ensuite, le serveur API utilise la graine DEK mise en cache pour générer d'autres données à usage unique DEKs basées sur une fonction de dérivation de clés (KDF). Chacun de ces éléments générés n' DEKs est ensuite utilisé qu'une seule fois pour chiffrer une seule ressource Kubernetes avant qu'elle ne soit stockée dans etcd.

Il est important de noter que des appels supplémentaires sont effectués depuis le serveur API pour vérifier le bon fonctionnement et le fonctionnement normal de l'intégration AWS KMS. Ces bilans 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 d'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. En outre, vous pouvez consulter les journaux AWS CloudTrail d'événements associés à l'utilisation de la clé CMK de votre cluster.

Si votre cluster utilise une clé AWS détenue, celle-ci sera détaillée dans la console EKS (à l'exception de l'ARN de la clé).

Puis-je AWS accéder à la clé AWS détenue utilisée pour le chiffrement des enveloppes par défaut dans Amazon EKS ?

Non. AWS dispose de contrôles de sécurité stricts dans Amazon EKS qui empêchent toute personne d'accéder aux clés de chiffrement en texte brut utilisées pour sécuriser les données de la base de données etcd. Ces mesures de sécurité sont également appliquées à la clé KMS AWS détenue.

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 eks:kms-storage-migrator RBAC ClusterRole pour faire migrer les données qui n'étaient pas auparavant 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. Toutefois, si vous utilisez votre propre clé AWS KMS, la tarification KMS normale s'appliquera.

Combien coûte l'utilisation de ma propre clé AWS KMS pour chiffrer les données de l'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 de KMS pour un compte, de sorte que le coût d'utilisation de votre propre clé AWS KMS sur votre cluster sera affecté par l'utilisation de cette clé sur d'autres clusters ou AWS ressources 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, le serveur API 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 de KMS v2 dans les améliorations de 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 clé CMK est désactivée, le cluster sera immédiatement placé dans un unhealthy/degraded état tel que nous ne serons pas en mesure de respecter notre engagement de service tant que vous n'aurez pas réactivé la clé CMK associée.

Lorsqu’une CMK est désactivée, vous recevrez des notifications concernant la dégradation de l’état 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é disabled/deleted CMK ?

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 CloudWatch alarme pour être informé 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, le succès de la restauration de votre cluster EKS dépendra également de la question de savoir s'il subit ou non des modifications perturbatrices de l'API en raison d'une mise à niveau automatique de Kubernetes qui peut avoir lieu alors que le cluster est dans un état. unhealthy/degraded

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

Le serveur API du plan de contrôle EKS utilise une clé DEK cryptée et mise en cache dans la mémoire du serveur API pour chiffrer tous les objets pendant les create/update opérations 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. Toutefois, lorsque l'instance du serveur d'API est redémarrée, elle ne possède pas de DEK en cache et devra 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 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, voir État du cluster FAQs et codes d'erreur avec chemins de résolution.

Vais-je quand même être débité pour un cluster degraded/unhealthy EKS parce que j'ai désactivé ou supprimé ma clé CMK ?

Oui. Bien que le plan de contrôle EKS ne soit pas utilisable en cas de désactivation d'une clé CMK, les ressources d'infrastructure dédiées allouées au cluster EKS AWS continueront d'être utilisées jusqu'à ce qu'il soit supprimé 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 l’état normal de votre cluster EKS.

Mon cluster EKS peut-il être automatiquement mis à niveau lorsqu'il est dans un unhealthy/degraded état en raison d'une clé 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.