Bonnes pratiques de chiffrement pour Amazon EKS

Amazon Elastic Kubernetes Service (Amazon EKS) vous permet d'exécuter AWS Kubernetes sans avoir à installer ou à gérer votre propre plan de contrôle ou vos propres nœuds Kubernetes. Dans Kubernetes, les secrets vous aident à gérer des informations sensibles, telles que les certificats utilisateur, les mots de passe ou les clés d'API. Par défaut, ces secrets sont stockés non chiffrés dans l'entrepôt de données sous-jacent du serveur d'API, appelé etcd. Sur Amazon EKS, les volumes Amazon Elastic Block Store (Amazon EBS) etcd pour les nœuds sont chiffrés avec le chiffrement Amazon EBS. Tout utilisateur disposant d'un accès à une API ou d'un accès à etcd peut récupérer ou modifier un secret. En outre, toute personne autorisée à créer un pod dans un espace de noms peut utiliser cet accès pour lire n'importe quel secret dans cet espace de noms. Vous pouvez chiffrer ces secrets au repos dans Amazon EKS à l'aide AWS KMS keys de clés gérées ou de clés AWS gérées par le client. Une autre approche consiste à utiliser etcd AWS Secrets and Config Provider (ASCP) (GitHub référentiel). ASCP s'intègre aux politiques IAM et basées sur les ressources pour limiter et restreindre l'accès aux secrets uniquement au sein de pods Kubernetes spécifiques au sein d'un cluster.

Vous pouvez utiliser les services de AWS stockage suivants avec Kubernetes :

• Pour Amazon EBS, vous pouvez utiliser le pilote de stockage intégré ou le pilote Amazon EBS CSI. Ils incluent tous deux des paramètres permettant de chiffrer les volumes et de fournir une clé gérée par le client.

• Pour Amazon Elastic File System (Amazon EFS), vous pouvez utiliser le pilote CSI Amazon EFS avec prise en charge de l'allocation dynamique et statique.

Tenez compte des bonnes pratiques de chiffrement suivantes pour ce service :

• Si vous utilisez etcd, qui stocke les objets secrets non chiffrés par défaut, procédez comme suit pour protéger les secrets :

  • Encrypt secret data at rest (documentation Kubernetes).

  • AWS KMS À utiliser pour le chiffrement des enveloppes des secrets Kubernetes. Cela vous permet de chiffrer vos secrets avec une clé de données unique. Vous pouvez utiliser une AWS KMS clé de chiffrement pour chiffrer la clé de données. Vous pouvez automatiquement faire pivoter la clé de chiffrement selon un calendrier récurrent. Avec le AWS KMS plugin pour Kubernetes, tous les secrets de Kubernetes sont stockés sous forme de texte chiffré. etcd Ils ne peuvent être déchiffrés que par le serveur d'API Kubernetes. Pour plus d'informations, consultez Utiliser le support du fournisseur de chiffrement Amazon EKS pour une défense approfondie et Chiffrer les secrets Kubernetes sur des AWS KMS clusters existants.

  • Activez ou spécifiez l'autorisation via des règles de contrôle d'accès basé sur les rôles (RBAC) qui limitent la lecture et l'écriture du secret. Limitez les autorisations pour créer des secrets ou remplacer des secrets existants. Pour plus d'informations, veuillez consulter Authorization overview (documentation Kubernetes).

  • Si vous définissez plusieurs conteneurs dans un pod et qu'un seul de ces conteneurs a besoin d'accéder à un secret, définissez le montage du volume afin que les autres conteneurs n'aient pas accès à ce secret. Les secrets montés en tant que volumes sont instanciés en tant que volumes tmpfs et sont automatiquement retirés du nœud lorsque le pod est supprimé. Vous pouvez également utiliser des variables d'environnement, mais nous ne recommandons pas cette approche, car les valeurs des variables d'environnement peuvent apparaître dans les journaux. Pour plus d'informations, veuillez consulter Secrets (documentation Kubernetes).

  • Dans la mesure du possible, évitez d'accorder l'accès aux demandes watch et list pour des secrets dans un espace de noms. Dans l'API Kubernetes, ces demandes sont performantes, car elles permettent au client d'inspecter les valeurs de chaque secret de cet espace de noms.

  • Autorisez uniquement les administrateurs du cluster à accéder à etcd, y compris l'accès en lecture seule.

  • S'il existe plusieurs instances etcd, assurez-vous qu'etcd utilise le protocole TLS pour la communication entre pairs etcd.

• Si vous utilisez le protocole ASCP, procédez comme suit pour protéger les secrets :

  • Utilisez des rôles IAM pour les comptes de service pour limiter l'accès au secret aux seuls pods autorisés.

  • Activez le chiffrement des secrets Kubernetes en utilisant le fournisseur de AWS chiffrement (GitHub référentiel) pour implémenter le chiffrement des enveloppes avec une clé KMS gérée par le client.

• Pour atténuer le risque de fuite de données provenant de variables d'environnement, nous vous recommandons d'utiliser le pilote CSI AWS Secrets Manager and Config Provider for Secret Store (GitHub). Ce pilote vous permet de faire en sorte que les secrets stockés dans Secrets Manager et les paramètres stockés dans Parameter Store apparaissent sous forme de fichiers montés dans des pods Kubernetes.

  Note

  AWS Fargate n'est pas pris en charge.

• Créez un filtre de CloudWatch métriques Amazon et une alarme pour envoyer des alertes pour les opérations spécifiées par l'administrateur, telles que la suppression secrète ou l'utilisation d'une version secrète pendant la période d'attente avant la suppression. Pour plus d'informations, veuillez consulter Creating an alarm based on anomaly detection.