Présentation de la sécurité
Cette page décrit l'architecture de sécurité de GKE sur Azure, 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 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 Azure 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 Azure.
Les clusters GKE sur Azure stockent les données dans des volumes Azure Disks. Ces volumes sont toujours chiffrés au repos à l'aide de clés Azure Key Vault. Lorsque vous créez des clusters et des pools de nœuds, vous pouvez fournir une clé KeyVault gérée par le client pour chiffrer les volumes de disque sous-jacents du cluster. Si vous ne spécifiez pas de clé, Azure utilise la clé par défaut gérée par Azure dans la région Azure où le cluster est exécuté.
De plus, 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 pouvez fournir une clé Azure Key Vault dans le paramètre--database-encryption-kms-key-arn. Cette clé est utilisée pour le chiffrement des données de votre application.
Si vous ne fournissez pas de clé lors de la création du cluster, GKE sur Azure en crée une automatiquement pour votre cluster. Ce champ de ressource est immuable et ne peut pas être modifié une fois le cluster créé.
Vous pouvez également créer manuellement une clé Key Vault ou utiliser votre propre clé (BYOK, Bring Your Own Key) avec un module de sécurité matérielle (HSM, Hardware Security Module). Pour en savoir plus, consultez la section Utiliser votre propre clé.
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 :
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.
Le serveur d'API Kubernetes chiffre le secret localement avec la DEK.
Le serveur d'API Kubernetes envoie la DEK à Azure Key Vault pour chiffrement.
Azure Key Vault utilise une KEK prégénérée pour chiffrer la DEK et renvoie la DEK chiffrée au plug-in Azure Key Vault du serveur d'API Kubernetes.
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.
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 utilisés sans interroger Azure Key Vault.
Lorsqu'un client demande un secret au serveur d'API Kubernetes, voici ce qui se passe :
Le serveur d'API Kubernetes récupère le secret et la DEK chiffrés à partir d'etcd.
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.
En l'absence d'entrée de cache correspondante, le serveur d'API envoie la DEK à Azure Key Vault pour le déchiffrement à l'aide de la KEK. La DEK déchiffrée est ensuite utilisée pour déchiffrer le secret.
Enfin, le serveur d'API Kubernetes renvoie le secret déchiffré au client.
Chiffrement de la configuration avec le pare-feu Key Vault
Si vous transmettez une clé publique pour le chiffrement, le compte principal de service n'a pas besoin d'être autorisé à chiffrer, mais il doit être autorisé à gérer les attributions de rôles. Pour ce faire, le moyen le plus simple consiste à attribuer le rôle intégré User Access Administrator Azure à votre compte principal de service.
Pour sécuriser davantage votre Azure Key Vault, vous pouvez activer le pare-feu Azure Key Vault. GKE sur Azure peut ensuite utiliser une clé publique pour le chiffrement et éviter l'accès réseau au coffre de clés.
Pour configurer le pare-feu, téléchargez la clé Key Vault avec la CLI Azure.
Vous transmettez la clé à --config-encryption-public-key lorsque vous créez un cluster avec la CLI Google Cloud.
Vous devez toujours activer les points de terminaison de service pour Key Vault dans tous les sous-réseaux utilisés pour votre cluster. Pour plus d'informations, consultez la page Points de terminaison des services de réseau virtuel pour Azure Key Vault.
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.
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 Azure déploie vos charges de travail sur des pools de nœuds des instances de VM Azure. 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:
Ensemble de packages optimisé
Noyau Linux adapté à Google Cloud
Des comptes utilisateur limités et une connexion racine désactivée
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 Azure, Ubuntu, utilise les règles 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/sysautres 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. Lorsqu'une automodification est nécessaire, vous pouvez limiter les autorisations en installant Policy Controller ou Gatekeeper dans votre cluster et en appliquant des contraintes telles que NoUpdateServiceAccount à partir 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 Azure, 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.
Isoler les charges de travail sur des pools de nœuds dédiés
Vous pouvez utiliser les rejets et les tolérances Kubernetes pour désigner des pools de nœuds spécifiques afin d'exécuter des types de charges de travail spécifiques. Par exemple, vous pouvez demander à GKE sur Azure de planifier les charges de travail utilisateur pour les écarter de la plupart des charges de travail gérées par le système, ou de placer des charges de travail avec différents niveaux de confiance sur différents pools de nœuds.
L'isolation de la charge de travail à l'aide de rejets et de tolérances n'est pas une mesure de sécurité garantie. Ne l'utilisez qu'avec les autres mesures de renforcement proposées par GKE sur Azure.
Pour en savoir plus, consultez Isoler des charges de travail dans des pools de nœuds dédiés.
Étapes suivantes
- Apprenez-en plus sur la rotation des clés.