Présentation de la sécurité

Cette page décrit l'architecture de sécurité de GKE sur AWS, y compris le chiffrement et la configuration des nœuds.

Les clusters GKE offrent des fonctionnalités permettant de sécuriser vos charges de travail, y compris le contenu de votre image de conteneur, l'environnement d'exécution du conteneur, le réseau du cluster et l'accès au serveur d'API du cluster.

Lorsque vous utilisez des clusters GKE, vous acceptez d'assumer certaines responsabilités pour vos clusters. Pour en savoir plus, consultez la page Responsabilités partagées des clusters GKE.

Chiffrement KMS AWS

GKE sur AWS utilise des clés symétriques AWS Key Management Service (KMS) gérées par le client pour chiffrer les éléments suivants:

Pour les environnements de production, nous vous recommandons d'utiliser différentes clés pour la configuration et le chiffrement du volume. Pour réduire davantage les risques si une clé est compromise, vous pouvez également créer des clés différentes pour chacun des éléments suivants :

Pour renforcer la sécurité, vous pouvez créer une stratégie de clé KMS AWS qui n'attribue que l'ensemble minimal d'autorisations requis. Pour en savoir plus, consultez la page Créer des clés KMS avec des autorisations spécifiques.

Chiffrement des données au repos

Le chiffrement des données au repos est le chiffrement des données stockées, par opposition aux données en transit. Par défaut, GKE sur AWS chiffre les données dans etcd et les volumes de stockage au repos à l'aide de clés gérées par la plate-forme AWS.

Les clusters GKE sur AWS stockent les données dans des volumes AWS Elastic Block Storage (EBS). Ces volumes EBS sont toujours chiffrés au repos avec des clés AWS Key Management System (AWS KMS). Lorsque vous créez des clusters et des pools de nœuds, vous pouvez fournir une clé KMS gérée par le client pour chiffrer les volumes EBS sous-jacents. Si vous ne spécifiez pas de clé, AWS utilise la clé gérée par défaut AWS dans la région AWS où le cluster est exécuté.

En outre, tous les clusters GKE activent le chiffrement des secrets au niveau de la couche d'application pour les données sensibles, telles que les objets Secret Kubernetes, qui sont stockés dans etcd. Même si des pirates informatiques accèdent au volume sous-jacent où les données etcd sont stockées, ces données sont chiffrées.

Lorsque vous créez un cluster, vous devez transmettre une clé KMS AWS au champ --database-encryption-kms-key-arn. Cette clé est utilisée pour le chiffrement encapsulé des données d'application. Comme ce champ de ressource est immuable et ne peut pas être modifié une fois le cluster créé, nous vous recommandons d'utiliser un alias de clé KMS. Vous pouvez utiliser des alias de clé pour alterner les clés utilisées pour le chiffrement au repos tout au long du cycle de vie du cluster.

Fonctionnement du chiffrement au niveau de l'application

Kubernetes propose le chiffrement au niveau de l'application grâce à une technique connue sous le nom de chiffrement encapsulé. Une clé locale, couramment appelée clé de chiffrement des données (DEK, Data Encryption Key), est utilisée pour chiffrer un secret. La DEK elle-même est ensuite chiffrée avec une deuxième clé appelée clé de chiffrement de clé (KEK, Key Encryption Key). La clé KEK n'est pas stockée par Kubernetes. Lorsque vous créez un secret Kubernetes, votre cluster effectue les opérations suivantes :

  1. Le serveur d'API Kubernetes génère une DEK unique pour le secret à l'aide d'un générateur de numéros aléatoires.

  2. Le serveur d'API Kubernetes chiffre le secret localement avec la DEK.

  3. Le serveur d'API Kubernetes envoie la DEK à KMS AWS pour chiffrement.

  4. AWS KMS utilise une KEK prégénérée pour chiffrer la DEK et la renvoie au plug-in AWS KMS du serveur d'API Kubernetes.

  5. Le serveur d'API Kubernetes enregistre le secret et la DEK chiffrés dans etcd. La DEK en texte brut n'est pas enregistrée sur le disque.

  6. Le serveur d'API Kubernetes crée une entrée de cache en mémoire pour mapper la DEK chiffrée à la DEK en texte brut. Cela permet au serveur d'API de déchiffrer les secrets récemment consultés sans interroger le service de gestion des clés AWS.

Lorsqu'un client demande un secret au serveur d'API Kubernetes, voici ce qui se passe :

  1. Le serveur d'API Kubernetes récupère le secret et la DEK chiffrés à partir d'etcd.

  2. Le serveur d'API Kubernetes vérifie la présence d'une entrée de mappage existante dans le cache et l'utilise pour déchiffrer le secret s'il en trouve une.

  3. En l'absence d'entrée de cache correspondante, le serveur d'API envoie la DEK à KMS AWS pour déchiffrement à l'aide de la KEK. La DEK déchiffrée est ensuite utilisée pour déchiffrer le secret.

  4. Enfin, le serveur d'API Kubernetes renvoie le secret déchiffré au client.

Rotation des clés

Contrairement à la rotation des certificats, la rotation des clés consiste à modifier le matériel de chiffrement sous-jacent contenu dans une clé de chiffrement de clé (KEK). Elle peut être déclenchée automatiquement dans le cadre d'une rotation planifiée, ou manuellement, généralement après un incident de sécurité où des clés ont pu être compromises. La rotation des clés ne remplace que le champ unique de la clé contenant les données brutes de la clé de chiffrement/déchiffrement.

Rotation des clés KMS

AWS KMS est compatible avec la rotation automatique des clés KMS. Lorsque cette option est activée, AWS génère automatiquement un nouveau matériel de clé cryptographique pour votre clé une fois par an. Aucune action manuelle n'est requise.

Pour en savoir plus, consultez la page Rotation des clés.

Confiance dans les clusters

Toutes les communications de cluster utilisent le protocole TLS (Transport Layer Security). Chaque cluster est provisionné avec les principales autorités de certification racine autosignées suivantes :

  • L'autorité de certification racine du cluster est utilisée pour valider les requêtes envoyées au serveur d'API.
  • L'autorité de certification racine etcd est utilisée pour valider les requêtes envoyées aux instances dupliquées etcd.

Chaque cluster possède une autorité de certification racine unique. Si l'autorité de certification d'un cluster est compromise, aucune autre autorité de certification de cluster n'est affectée. Toutes les autorités de certification racine ont une période de validité de 30 ans.

Sécurité des nœuds

GKE sur AWS déploie vos charges de travail sur des pools de nœuds d'instances AWS EC2. La section suivante décrit les fonctionnalités de sécurité des nœuds.

Ubuntu

Vos nœuds exécutent une version optimisée du système d'exploitation Ubuntu pour exécuter le plan de contrôle et les nœuds Kubernetes. Pour en savoir plus, consultez la section sur les fonctionnalités de sécurité dans la documentation Ubuntu.

Les clusters GKE mettent en œuvre plusieurs fonctionnalités de sécurité, par exemple:

Des guides de sécurité supplémentaires sont disponibles pour Ubuntu, tels que les suivants :

Sécuriser vos charges de travail

Kubernetes permet aux utilisateurs de provisionner, mettre à l'échelle et mettre à jour rapidement des charges de travail basées sur des conteneurs. Cette section décrit les tactiques que vous pouvez utiliser pour limiter les effets secondaires de l'exécution de conteneurs sur un cluster et les services Google Cloud.

Limiter les droits de processus en conteneur du pod

Limiter les droits des processus en conteneur est important pour la sécurité de votre cluster. Vous pouvez définir des options liées à la sécurité avec un contexte de sécurité. Ces paramètres vous permettent de modifier les paramètres de sécurité de vos processus, tels que les suivants :

  • Utilisateur et groupe exécutant le processus
  • Capacités Linux disponibles
  • Élévation des privilèges

Le système d'exploitation par défaut du nœud GKE sur AWS, Ubuntu, utilise les stratégies de sécurité Docker AppArmor par défaut pour tous les conteneurs. Vous pouvez consulter le modèle du profil sur GitHub. Entre autres choses, ce profil empêche d'utiliser les fonctionnalités de conteneur suivantes :

  • Écrire dans des fichiers directement dans un répertoire d'ID de processus (/proc/)
  • Écrire dans des fichiers qui ne se trouvent pas dans /proc/
  • Écrire dans des fichiers dans /proc/sys autres que /proc/sys/kernel/shm*
  • Installer des systèmes de fichiers

Restreindre les capacités d'automodification des charges de travail

Certaines charges de travail Kubernetes, en particulier les charges de travail système, sont autorisées à s'automodifier. Par exemple, certaines charges de travail effectuent des autoscaling verticaux sur elle-mêmes. Bien que cette capacité soit pratique, elle peut permettre à un pirate informatique ayant déjà compromis un nœud de passer au niveau supérieur dans le cluster. Par exemple, un pirate informatique peut faire en sorte qu'une charge de travail sur le nœud se modifie pour s'exécuter en tant que compte de service plus privilégié qui existe dans le même espace de noms.

Idéalement, les charges de travail ne doivent pas être autorisées à se modifier elles-mêmes. Si l'automodification est nécessaire, vous pouvez limiter les autorisations en installant Policy Controller ou Gatekeeper dans votre cluster et appliquer des contraintes, telles que NoUpdateServiceAccount de la bibliothèque Open Source Gatekeeper, qui fournit plusieurs règles de sécurité utiles.

Lorsque vous déployez des règles, il est généralement nécessaire de permettre aux contrôleurs qui gèrent le cycle de vie du cluster de contourner les règles. Cela est nécessaire pour que les contrôleurs puissent apporter des modifications au cluster, telles que l'application de mises à niveau de cluster. Par exemple, si vous déployez la stratégie NoUpdateServiceAccount sur GKE sur AWS, vous devez définir les paramètres suivants dans Constraint:

parameters:
  allowedGroups: []
  allowedUsers:
  - service-PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com

Remplacez PROJECT_NUMBER par le numéro (et non l'ID) du projet qui héberge le cluster.

Utiliser l'autorisation binaire

Une autre façon de sécuriser vos charges de travail consiste à activer l'autorisation binaire. L'autorisation binaire est une fonctionnalité de sécurité qui garantit que seules des images de conteneur fiables sont déployées sur des clusters GKE.

Voici comment ce processus fonctionne:

  1. Les administrateurs créent une stratégie qui définit les conditions requises pour le déploiement d'une image. Cela inclut la spécification des entités de confiance et autorisées (certificateurs) pouvant signer des images, et peut inclure d'autres critères auxquels une image doit répondre pour être considérée comme sûre pour un déploiement.

  2. Un certificateur (par exemple, un développeur ou un système automatisé) utilise un algorithme cryptographique pour générer une paire de clés (clés privées et publiques).

  3. La clé privée, qui reste secrète, permet de générer une signature numérique (c'est-à-dire un ensemble unique de caractères) pour une image. Cette signature agit comme un sceau d'approbation : cela indique que l'image a passé toutes les vérifications et validations nécessaires.

  4. La signature numérique est ensuite "jointe" à l'image. En d'autres termes, la signature est stockée dans les métadonnées de l'image, généralement dans le registre d'images.

  5. La clé publique est ensuite enregistrée auprès du système d'autorisation binaire afin que le système puisse l'utiliser pour la vérification de la signature.

  6. Lorsqu'une requête de déploiement d'un conteneur est effectuée, le système d'autorisation binaire récupère la signature numérique associée à l'image dans le registre.

  7. Le système d'autorisation binaire utilise la clé publique enregistrée pour vérifier la signature numérique associée à l'image. Il vérifie également si l'image répond à tous les autres critères définis dans la stratégie. Si la signature numérique peut être validée à l'aide de la clé publique et des données d'image, et que l'image répond à tous les autres critères définis dans la stratégie, le système d'autorisation binaire permet de déployer le conteneur. Si la signature numérique ne peut pas être validée à l'aide de la clé publique et des données d'image, ou si l'image ne répond pas à d'autres critères définis dans la stratégie, le système d'autorisation binaire refuse le déploiement du conteneur.

Pour en savoir plus sur le fonctionnement de l'autorisation binaire, consultez la présentation de l'autorisation binaire.

Pour activer l'autorisation binaire sur un cluster existant ou lors de la création d'un cluster, consultez Activer l'autorisation binaire.

Étapes suivantes