Présentation du chiffrement
Cloud privé virtuel Infrastructure classique
Protégez les informations sensibles dans votre IBM Cloud® Kubernetes Service cluster pour garantir l’intégrité des données et empêcher vos données d’être exposées à des utilisateurs non autorisés en configurant un fournisseur de services de gestion de clés (KMS).
IBM Cloud Kubernetes Service propose un chiffrement sur plusieurs couches de votre cluster. Le cryptage de certains composants est géré par IBM tandis que, pour d'autres composants, vous avez la possibilité d'apporter vos propres références de fournisseur KMS pour gérer le cryptage vous-même.
Lorsque vous aurez terminé cette page, essayez le quiz.
Le tableau suivant présente les options de chiffrement pour IBM Cloud Kubernetes Service groupes.
| Composant | Chiffré par défaut? | Apportez votre propre support de clé? | Durée d'activation | Fournisseurs KMS pris en charge | Prise en charge des comptes croisés? |
|---|---|---|---|---|---|
| plan de contrôle | Oui | Non | Lors de la création du cluster. | IBM géré Key Protect | N/A |
| Disques de noeud worker | Oui | Oui | Lors de la création de cluster ou de pool de noeuds worker. |
|
Oui |
| Secrets de cluster | Non | Oui | Après la création du cluster à l'aide de kms enable. |
|
Compte croisé pris en charge pour les clusters Classic et VPC uniquement. |
| Stockage de persistance | Cela dépend du fournisseur de services de stockage. | Dépend du fournisseur | Après la création du cluster, lors de la configuration du stockage. |
|
Cela dépend du fournisseur de services de stockage. |
| Trafic de noeud worker à noeud worker | Non | Non | Après la création du cluster. | N/A | Non |
Plan de contrôle
Le chiffrement du plan de contrôle est géré par IBM.
- Les composants du maître Kubernetes démarrent sur un lecteur crypté LUKS à l'aide d'une clé gérée par IBM.
- Le composant etcd du maître stocke les fichiers de configuration de vos ressources Kubernetes, tels que les déploiements et les secrets.
- Les données d'etcd sont stockées sur le disque local du maître Kubernetes et sauvegardées dans IBM Cloud Object Storage.
- Les données sont chiffrées lors du transit vers IBM Cloud Object Storage et au repos.
Disques de noeud worker
Les disques attachés sont utilisés pour démarrer votre nœud de travail, héberger le système de fichiers du conteneur et stocker les images tirées localement. Le chiffrement et le nombre de disques varient en fonction des fournisseurs d'infrastructure.
- Nœuds worker VPC
- Par défaut, l'unique disque primaire des nœuds de travail VPC est chiffré à AES-256 bit au repos par le fournisseur d'infrastructure VPC sous-jacent. Vous pouvez gérer le chiffrement des noeuds worker en activant un fournisseur KMS au niveau du pool de noeuds worker. Pour plus d'informations sur le chiffrement des disques de noeud worker VPC, voir Configuration du chiffrement de disque de noeud worker pour les clusters de VPC.
- Noeuds worker classiques
- Le disque principal contient les images du noyau pour initialiser votre noeud worker. Ce disque est non chiffré. Le disque secondaire contient le système de fichiers de conteneur et les images extraites en local. Ce disque est crypté AES 256 octets avec une clé de chiffrement LUKS gérée par IBM qui est unique au noeud worker et stockée en tant que secret Kubernetes dans votre cluster. Lorsque vous rechargez ou mettez à jour vos noeuds worker, les clés LUKS font l'objet d'une rotation.
Secrets de cluster
Les secrets Kubernetes sont base64 codés par défaut. Vous pouvez également protéger les secrets Kubernetes et les données d'identification stockées dans les secrets en activant un fournisseur de service de gestion de clés (KMS), tel que IBM® Key Protect for IBM Cloud® ou Hyper Protect Crypto Services.
Lorsque vous activez un fournisseur de service de gestion de clés (KMS) pour votre cluster, vous apportez votre propre clé racine. La clé racine est utilisée pour chiffrer les clés de chiffrement de données (DEKs+) qui sont ensuite utilisées pour chiffrer les secrets de votre cluster. La clé racine est stockée dans l'instance du fournisseur KMS que vous contrôlez. Les DEKs cryptés sont stockés dans etcd et ne peuvent être chiffrés qu'à l'aide de la clé racine du fournisseur KMS. Pour plus d'informations sur le chiffrement de clé, voir Chiffrement d'enveloppe.
Passez en revue les remarques suivantes sur le chiffrement des secrets de cluster.
- Les secrets de cluster sont chiffrés à l'aide de votre KMS.
- Les secrets de cluster sont automatiquement mis à jour après rotation des clés racine.
- Les clusters qui utilisent la clé racine sont visibles à partir de l'interface du fournisseur KMS.
- Les clusters répondent automatiquement si vous désactivez, activez ou restaurez les clés racine.
- La désactivation d'une clé racine restreint la fonctionnalité d'un cluster tant que vous ne réactivez pas la clé.
- La suppression d'une clé racine rend le cluster inutilisable et irrécupérable.
- Vous ne pouvez activer qu'un seul fournisseur KMS et une seule clé à la fois dans le cluster.
- Vous pouvez changer de fournisseur KMS et de clé.
- Vous ne pouvez pas désactiver le chiffrement du fournisseur KMS.
Pour configurer le chiffrement secret du cluster, consultez Configuration du chiffrement secret du cluster.
Stockage de persistance
En fonction du type de stockage persistant que vous utilisez, vous pouvez chiffrer les données écrites sur les volumes de stockage en activant un fournisseur KMS. Pour plus d'informations sur les types de stockage persistant et de chiffrement disponibles, voir Description de vos options de stockage.
Trafic de noeud worker à noeud worker
Vous pouvez configurer le chiffrement des données circulant entre les noeuds worker de votre cluster à l'aide de WireGuard. Pour plus d'informations, voir Chiffrement du trafic entre les noeuds worker avec WireGuard.
Etapes suivantes
Testez vos connaissances avec un quiz.
Pour poursuivre le processus de planification, choisissez une option de stockage. Si vous êtes prêt à commencer le chiffrement, passez à la création d'une instance KMS et d'une clé racine.