Sécurité d'IBM Cloud Kubernetes Service

Vous pouvez utiliser les fonctions de sécurité intégrées dans IBM Cloud® Kubernetes Service pour l'analyse des risques et la protection en matière de sécurité. Ces fonctions vous aident à protéger l'infrastructure de votre cluster et la communication réseau, à isoler vos ressources de traitement, et à garantir la conformité aux règles de sécurité des composants de votre infrastructure et des déploiements de conteneurs.

Pour une analyse des instructions de sécurité par version du produit, voir Benchmark CIS de Kubernetes.

Présentation des menaces de sécurité concernant votre cluster

Pour protéger votre cluster de toute compromission, vous devez connaître les menaces de sécurité potentielles pouvant affecter votre cluster et les mesures à prendre pour réduire l'exposition à ces vulnérabilités.

Attaques externes: Des personnes malveillantes peuvent obtenir l'accès à votre cluster, aux ressources déployées, aux applications ou à des informations personnelles.
Déploiements vulnérables: Les vulnérabilités connues sont exploitées pour accéder à l'environnement cloud et exécuter des logiciels malveillants.
Données perdues ou compromises: Stockage incorrect des données sensibles et absence de chiffrement.
Partenaires et fournisseurs tiers: L'absence d'isolation et de segmentation du réseau peut entraîner une utilisation abusive des autorisations légitimes.

La sécurité du cloud et la protection contre les attaques de vos systèmes, de votre infrastructure et de vos données sont devenues très importantes ces dernières années alors que les sociétés continuent à déplacer leurs charges de travail sur le cloud public. Un cluster est constitué de plusieurs composants, chacun pouvant exposer votre environnement à des risques d'attaques malveillantes. Pour protéger votre cluster contre ces menaces de sécurité, vous devez veiller à appliquer les fonctions et les mises à jour de sécurité les plus récentes d'IBM Cloud Kubernetes Service et de Kubernetes dans tous les composants du cluster.

Ces composants sont les suivants :

Serveur d'API Kubernetes et magasin de données etcd
Nœuds worker
Réseau
Stockage de persistance
Surveillance et journalisation
Registre et images de conteneur
Isolement et sécurité des conteneurs
Informations personnelles

Serveur d'API et etcd

Le serveur d'API Kubernetes et le magasin de données etcd sont les composants les plus sensibles qui s'exécutent dans votre maître Kubernetes. Vous souhaitez empêcher l'accès non autorisé à ces composants, car ils permettent de définir et de stocker les configurations pour toutes les ressources qui s'exécutent dans votre cluster, y compris certains paramètres de sécurité de vos applications.

Kubernetes fournit des contrôles de sécurité et limite l'accès afin de protéger ces composants et de réduire le risque d'attaques.

Comment l'accès à mon serveur API est-il accordé?

Par défaut, Kubernetes nécessite que toutes les demandes suivent plusieurs étapes avant que l'accès au serveur d'API ne soit accordé.

Authentification: Valide l'identité d'un utilisateur ou d'un compte de service enregistré.
Autorisation: Limite les droits des utilisateurs authentifiés et des comptes de service pour s'assurer qu'ils peuvent accéder et utiliser uniquement les composants de cluster que vous souhaitez qu'ils soient.
Contrôle d'admission: Valide ou mute les demandes avant qu'elles ne soient traitées par le serveur API Kubernetes. De nombreuses fonctionnalités d' Kubernetes nécessitent des contrôleurs d'admission pour fonctionner correctement.

Comment IBM Cloud Kubernetes Service assure-t-il la sécurité de mon serveur API et de mon magasin de données etcd?

L'image suivante présente les paramètres de sécurité par défaut du cluster pour l'authentification, l'autorisation, le contrôle d'admission et la connectivité sécurisée entre le maître Kubernetes et les noeuds worker.

Décrit les étapes de sécurité lors de l'accès au serveur API. — Étapes de sécurité lors de l'accès au serveur API

Examinez les fonctions de sécurité suivantes du serveur d'API Kubernetes et d'etcd.

Maître Kubernetes entièrement géré et dédié

Chaque cluster dans IBM Cloud Kubernetes Service est régi par un maître Kubernetes dédié géré par IBM dans un compte IBM Cloud sous propriété IBM. Le maître Kubernetes est configuré avec les composants dédiés suivants qui ne sont pas partagés avec d'autres clients IBM.

Magasin de données etcd : stocke toutes les ressources Kubernetes d'un cluster, telles que Services, Deployments et Pods. Les éléments Kubernetes ConfigMaps et Secrets sont des données d'application stockées sous forme de paires clé-valeur pour pouvoir les utiliser dans une application s'exécutant dans un pod. 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. Vous pouvez choisir d'activer le chiffrement de vos données etcd sur le disque local de votre maître Kubernetes en activant le chiffrement IBM Key Protect pour votre cluster. Lorsque ces données sont envoyées à un pod, elles sont chiffrées avec TLS pour garantir leur protection et leur intégrité.
kube-apiserver : constitue le point d'entrée principal pour toutes les demandes de gestion de cluster du noeud worker au maître Kubernetes. Le serveur d'API valide et traite les demandes qui modifient l'état des ressources cluster, tels que les pods ou les services, et enregistre cet état dans le magasin de données etcd.
kube-scheduler : décide où déployer les pods en considérant la capacité du compte et les besoins en performances, les contraintes des règles en matière de matériel et de logiciel, les spécifications d'anti-affinité et les besoins de la charge de travail. Si aucun noeud worker ne répond à ces exigences, le pod n'est pas déployé dans le cluster.
kube-controller-manager : se charge de la surveillance des jeux de répliques et de la création de pods correspondants pour atteindre l'état spécifié.
Konnectivity : composant spécifique à l' IBM Cloud Kubernetes Service qui assure une connectivité réseau sécurisée pour toutes les communications entre les nœuds maîtres et les nœuds de travail d' Kubernetes. Le serveur Konnectivity fonctionne avec l'agent Konnectivity pour connecter en toute sécurité le nœud maître au nœud de travail. Cette connexion prend en charge les demandes apiserver proxy à vos pods et services, ainsi que les demandes kubectl top, exec, attach et logs au kubelet. La connexion entre les noeuds worker et le maître est automatiquement sécurisée avec des certificats TLS.

Surveillance continue par des ingénieurs IBM SRE (Site Reliability Engineer)

Le maître Kubernetes, y compris tous ses composants et toutes ses ressources de calcul, mise en réseau et stockage, est surveillé en permanence par des ingénieurs IBM SRE (Site Reliability Engineers). Ces ingénieurs appliquent les dernières normes en matière de sécurité, détectent et éliminent les activités malveillantes et travaillent pour assurer la fiabilité et la disponibilité d'IBM Cloud Kubernetes Service.

Test de performances du maître Kubernetes CIS

Pour configurer IBM Cloud Kubernetes Service, les techniciens IBM suivent les pratiques de cybersécurité pertinentes de la référence principal Kubernetes qui est publiée par le Center of Internet Security (CIS). Le maître cluster et tous les noeuds worker sont déployés avec des images répondant aux critères du test de performances.

Communication sécurisée via TLS

Pour utiliser IBM Cloud Kubernetes Service, vous devez vous authentifier auprès du service à l'aide de vos données d'identification. Une fois authentifié, IBM Cloud Kubernetes Service génère des certificats TLS qui chiffrent la communication en provenance et à destination du serveur d'API Kubernetes et du magasin de données etcd pour garantir une communication sécurisée de bout en bout entre les noeuds worker et le maître Kubernetes. Ces certificats ne sont jamais partagés entre les clusters ou entre les composants du maître Kubernetes.

Connectivité aux noeuds worker

Bien que Kubernetes sécurise les communications entre le maître Kubernetes et les noeuds worker à l'aide du protocole https, aucune authentification n'est fournie par défaut sur le noeud worker. Pour sécuriser cette communication, IBM Cloud Kubernetes Service établit automatiquement une connexion Konnectivity entre le nœud maître Kubernetes et le nœud de travail lors de la création du cluster.

Contrôle d'accès à granularité fine

En tant qu'administrateur de compte, vous pouvez accorder l'accès à d'autres utilisateurs pour IBM Cloud Kubernetes Service à l'aide de IBM Cloud Identity and Access Management (IAM). IBM Cloud IAM fournit une authentification sécurisée avec la plateforme IBM Cloud, IBM Cloud Kubernetes Service et toutes les ressources de votre compte. La configuration des rôles d'utilisateur et des droits d'accès est essentielle pour limiter le nombre de personnes pouvant accéder à vos ressources et réduire les dommages que pourrait causer un utilisateur en cas d'utilisation abusive de droits légitimes. Vous pouvez effectuer une sélection parmi les rôles d'utilisateur prédéfinis suivants qui déterminent l'ensemble des actions que l'utilisateur peut exécuter :

Rôles d'accès à la plateforme : ces rôles déterminent les actions de gestion liées au cluster et aux noeuds worker pouvant être exécutées par un utilisateur dans IBM Cloud Kubernetes Service.
Rôles d'accès au service : Déterminez le rôle RBAC Kubernetes attribué à l'utilisateur et les actions que celui-ci peut exécuter sur le serveur d'API Kubernetes. Les rôles RBAC permettent aux utilisateurs de créer des ressources Kubernetes telles que des déploiements d'application, des espaces de noms ou des mappes de configuration. Pour plus d'informations sur les rôles RBAC correspondants attribués à un utilisateur et les autorisations associées, consultez la section Rôles d'accès au service IAM.
Infrastructure classique : permet d'accéder à vos ressources d'infrastructure classique. Les exemples des actions autorisées par les rôles d'infrastructure classique incluent notamment l'affichage des détails de machines de noeud worker de cluster ou l'édition de ressources de mise en réseau et de stockage.
Infrastructure classique : permet d'accéder aux ressources de l'infrastructure VPC. Exemples d'actions autorisés par les rôles d'infrastructure VPC : création d'un VPC, ajout de sous-réseaux, modification d'adresses IP flottantes et création d'instances VPC Block Storage.

Pour plus d'informations sur le contrôle d'accès dans un cluster, voir Affectation d'accès au cluster.

Accès aux pods via le jeton de compte de service

Pour les clusters qui exécutent Kubernetes versions 1.21 et suivantes, les jetons du compte de service qui permettent aux pods de communiquer avec le serveur d'API Kubernetes sont limités dans le temps, actualisés automatiquement, limités à un groupe d'utilisateurs spécifique (le pod) et invalidés après la suppression du pod. Pour continuer à communiquer avec le serveur d'API, vous devez concevoir vos applications de manière à lire régulièrement la valeur de jeton actualisée, par exemple toutes les minutes. Pour plus d'informations, consultez la section Tokens de compte de service liés.

Contrôleurs d'admission

Les contrôleurs d'admission sont implémentés pour des fonctions spécifiques dans Kubernetes et IBM Cloud Kubernetes Service. Avec ces contrôleurs, vous pouvez configurer des règles dans votre cluster pour déterminer si une action particulière dans le cluster est autorisée ou non. Dans la politique, vous pouvez spécifier des conditions lorsqu'un utilisateur ne peut pas effectuer une action, même si cette action fait partie des droits généraux que vous avez attribués à l'utilisateur à l'aide de rôles RBAC. Par conséquent, les contrôleurs d'admission peuvent fournir une couche de sécurité supplémentaire pour votre cluster avant le traitement d'une demande d'API par le serveur d'API Kubernetes.

Lorsque vous créez un cluster, IBM Cloud Kubernetes Service installe automatiquement les contrôleurs d'admission Kubernetes par défaut dans un ordre particulier sur le maître Kubernetes, ordre que l'utilisateur ne peut pas modifier. Passez en revue les contrôleurs d'admission par défaut pour chaque version de cluster dans les informations de référence du composant kube-apiserver.

Vous pouvez installer vos propres contrôleurs d'admission dans le cluster ou choisir un contrôleur d'admission optionnel, tel qu' Portieris. Avec Portieris, vous pouvez bloquer les déploiements de conteneur à partir d'images non signées.

Si vous avez installé manuellement des contrôleurs d'admission et que vous ne voulez plus les utiliser, veillez à les supprimer entièrement. Si vous ne les supprimez pas complètement, ils peuvent bloquer toutes les actions que vous souhaitez effectuer sur le cluster.

Que puis-je faire d'autre pour sécuriser mon serveur API?

Vous pouvez restreindre la connectivité réseau à votre maître de cluster de plusieurs façons

Activez uniquement le point de terminaison du service de cloud privé: Le point de terminaison du service public n'est requis que pour les clusters classiques OpenShift. Il peut être désactivé pour tous les clusters VPC. Il peut également être désactivé pour les clusters classiques Kubernetes, à condition que les options VRF et Service Endpoint soient activées dans votre compte. Cela permet de protéger le maître de la grappe contre les attaques sur le réseau public.
Activer les restrictions basées sur le contexte: Vous pouvez sécuriser l'accès réseau aux points d'extrémité des services privés et publics de votre cluster à l'aide de restrictions basées sur le contexte (CBR). Seules les demandes autorisées adressées au maître de la grappe et provenant de sous-réseaux figurant dans les règles CBR sont autorisées. Pour plus d'informations, voir Utilisation des restrictions basées sur le contexte.

Noeud worker

Les noeuds worker contiennent les déploiements et les services constituant votre application. Lorsque vous hébergez des charges de travail sur le cloud public, vous souhaitez vous assurer que votre application est protégée et qu'un utilisateur ou un logiciel non autorisé ne peut pas y accéder, y apporter des modifications ou la contrôler.

À qui appartient le nœud de travail et suis-je responsable de sa sécurité?

La propriété d'un noeud worker dépend du type de cluster que vous créez et du fournisseur d'infrastructure que vous choisissez.

Clusters classiques: les nœuds de travail sont provisionnés dans votre compte IBM Cloud. Les noeuds worker vous sont dédiés et il vous incombe de demander des mises à jour de ces noeuds worker fréquemment pour faire en sorte que le système d'exploitation des noeuds worker et les composants IBM Cloud Kubernetes Service appliquent les mises à jour et les correctifs de sécurité les plus récents.
Clusters VPC: les nœuds de travail sont provisionnés dans un compte IBM Cloud appartenant à IBM afin de permettre la surveillance des activités malveillantes et l'application des mises à jour de sécurité. Vous ne pouvez pas accéder à vos nœuds de travail à l'aide du tableau de bord VPC. En revanche, vous pouvez gérer vos noeuds worker à l'aide de la console, de l'interface de ligne de commande ou de l'API IBM Cloud Kubernetes Service. Les machines virtuelles qui constituent vos noeuds worker vous sont dédiées et il vous incombe de demander des mises à jour fréquemment pour faire en sorte que le système d'exploitation des noeuds worker et les composants IBM Cloud Kubernetes Service appliquent les mises à jour et les correctifs de sécurité les plus récents.

Pour plus d'informations, voir Vos responsabilités liées à l'utilisation d'IBM Cloud Kubernetes Service.

Utilisez la commandeibmcloud ks worker update régulièrement (par exemple tous les mois) pour déployer les mises à jour et les correctifs de sécurité sur le système d'exploitation, ainsi que pour mettre à jour la version d' Kubernetes exécutée par vos nœuds de travail. Lorsque des mises à jour sont disponibles, vous êtes averti lorsque vous affichez des informations sur le master et les nœuds worker dans la console ou l'interface de ligne de commande IBM Cloud, par exemple, avec les commandes ibmcloud ks clusters ls ou ibmcloud ks workers ls --cluster <cluster_name>. Les mises à jour de noeud worker sont fournies par IBM sous forme d'image du noeud worker complet incluant les derniers correctifs de sécurité. Pour appliquer les mises à jour, le noeud worker doit être réimagé et rechargé avec la nouvelle image. Les clés des superutilisateurs (root) font automatiquement l'objet d'une rotation lorsque le noeud est rechargé.

À quoi ressemble la configuration de mon nœud de travail?

L'image suivante présente les composants configurés pour tous les noeuds worker afin de protéger vos noeuds worker contre les attaques malveillantes.

Cette image ne contient pas les composants qui assurent la communication sécurisée de bout en bout en provenance et à destination du noeud worker. Pour plus d'informations, voir Sécurité des réseaux.

Configuration d'un nœud de travail sur IBM Cloud Kubernetes Service(hors sécurité réseau). — Configuration d'un nœud de travail sur IBM Cloud Kubernetes Service (hors sécurité réseau)

CIS-image conforme: Chaque nœud de travail est configuré avec un système d'exploitation qui met en œuvre les tests de performance publiés par le Center of Internet Security ( CIS ). L'utilisateur ou le propriétaire de la machine ne peut pas remplacer ce système d'exploitation par un autre. Pour vérifier la version actuelle du système d'exploitation, exécutez kubectl get nodes -o wide. IBM collabore avec des équipes de conseil en sécurité, internes et externes, pour traiter les vulnérabilités de conformité aux règles de sécurité potentielles. Les mises à jour et les correctifs de sécurité du système d'exploitation sont disponibles via IBM Cloud Kubernetes Service et doivent être installés par l'utilisateur pour assurer que le noeud worker est sécurisé.

IBM Cloud Kubernetes Service utilise un noyau Linux pour les nœuds de travail. Vous pouvez exécuter des conteneurs en fonction de n'importe quelle distribution Linux dans IBM Cloud Kubernetes Service. Vérifiez auprès de votre fournisseur d'images de conteneurs que vos images de conteneurs peuvent s'exécuter sur ce noyau.

Surveillance continue par des ingénieurs SRE (Site Reliability Engineer): L'image installée sur vos noeuds worker est surveillée en permanence par les ingénieurs SRE (IBM Site Reliability Engineers) pour détecter les vulnérabilités et les problèmes de conformité à la sécurité. Pour traiter les vulnérabilités, les ingénieurs SRE créent des correctifs et des groupes de correctifs de sécurité pour vos noeuds worker. Veillez à appliquer ces correctifs dès qu'ils sont disponibles afin de garantir la sécurité de vos nœuds de travail et des applications que vous exécutez sur ceux-ci.
Test de performances de noeud worker Kubernetes CIS: Pour configurer IBM Cloud Kubernetes Service, les ingénieurs d' IBM suivent les bonnes pratiques en matière de cybersécurité issues du benchmark Kubernetes pour les nœuds de travail, publié par le Center of Internet Security(CIS). Vous pouvez vérifier la conformité des noeuds worker aux normes de référence de CIS de Kubernetes.
Isolement du calcul: Les nœuds worker sont dédiés à un cluster et n'hébergent pas les charges de travail des autres clusters. Lorsque vous créez un cluster classique standard, vous pouvez choisir de provisionner vos nœuds de travail sous forme de machines physiques (bare metal) ou de machines virtuelles s'exécutant sur du matériel physique partagé ou dédié. Les nœuds de travail d'un cluster VPC peuvent être provisionnés uniquement sous forme de machines virtuelles sur une infrastructure partagée.
Option pour déploiement bare metal sur des clusters classiques: Si vous créez un cluster classique standard, vous pouvez choisir de mettre à disposition vos noeuds worker sur des serveurs physiques bare metal (au lieu d'instances de serveur virtuel). Avec des machines bare metal, vous bénéficiez d'un contrôle supplémentaire sur l'hôte de calcul, par exemple la mémoire ou l'UC. Cette configuration élimine l'hyperviseur de machine virtuelle qui alloue des ressources physiques aux machines virtuelles qui s'exécutent sur l'hôte. Au lieu de cela, toutes les ressources d'une machine bare metal sont exclusivement réservées au travailleur, de sorte que vous n'avez pas à vous inquiéter des « voisins bruyantes » partageant des ressources ou ralentissant les performances. Les serveurs bare metal vous sont dédiés, avec toutes leurs ressources disponibles pour l'utilisation du cluster.
Disques chiffrés: Par défaut, tous les noeuds worker sont mis à disposition avec deux partitions de données SSD locales chiffrées avec AES 256 bits. La première partition contient l'image du noyau utilisée pour initialiser le noeud worker et n'est pas chiffrée. La deuxième partition renferme le système de fichiers du conteneur. Elle est déverrouillée à l'aide de clés de chiffrement LUKS. Chaque noeud worker dans chaque cluster dispose de sa propre clé de chiffrement LUKS unique, gérée par IBM Cloud Kubernetes Service. Lorsque vous créez un cluster ou ajoutez un noeud worker à un cluster existant, les clés sont extraites de manière sécurisée, puis ignorées une fois le disque chiffré déverrouillé. Le chiffrement peut avoir une incidence sur les performances des entrées-sorties (E-S) de disque. Dans le cas de charges de travail exigeant de hautes performances des E-S de disque, testez un cluster avec et sans chiffrement activé pour déterminer s'il convient de désactiver le chiffrement.
Règles AppArmor spécialisées: Chaque nœud de travail est configuré avec des politiques de sécurité et d’accès qui sont appliquées par des profils AppArmor chargés dans le nœud de travail lors de l’amorçage. Les profils AppArmor ne peuvent pas être modifiés par l'utilisateur ou le propriétaire de la machine.
SSH désactivé: Par défaut, l'accès SSH est désactivé sur le noeud worker pour protéger votre cluster des attaques malveillantes. Lorsque l'accès SSH est désactivé, l'accès au cluster est forcé via le serveur d'API Kubernetes. Ce serveur nécessite que toutes les demandes soient vérifiées par rapport aux règles définies dans le module d'authentification, d'autorisation et de contrôle d'admission avant leur exécution dans le cluster.; Si vous disposez d’un cluster standard et que vous souhaitez installer davantage de fonctionnalités sur votre nœud de travail, vous pouvez choisir parmi les modules complémentaires fournis par IBM Cloud Kubernetes Service ou utiliser les ensembles de démons Kubernetes pour tout ce que vous souhaitez exécuter sur chaque nœud de travail. Pour toute action ponctuelle que vous devez effectuer, utilisez les tâches Kubernetes.

Réseau

L'approche classique pour protéger un réseau d'entreprise consiste à configurer un pare-feu et bloquer tout trafic indésirable vers vos applications. C'est toujours d'actualité car les recherches montrent que les attaques malveillantes proviennent d'utilisateurs internes ou d'utilisateurs autorisés utilisant à mauvais escient les droits qui leur sont conférés.

Segmentation de réseau et confidentialité pour les clusters classiques

Pour protéger votre réseau et limiter l'étendue des dommages pouvant être causés par un utilisateur lorsque l'accès est octroyé, vous devez veiller à ce que vos charges de travail soient aussi isolées que possible et à limiter le nombre d'applications et de noeuds worker exposés publiquement.

Quel trafic réseau est autorisé par défaut pour mon cluster Classic?

Tous les conteneurs sont protégés par des paramètres de règles réseau Calico prédéfinis qui sont configurés sur chaque noeud worker lors de la création du cluster. Par défaut, tout le trafic réseau sortant est autorisé pour tous les noeuds worker. Le trafic réseau entrant est bloqué avec les exceptions suivantes :

NodePort: la plage Kubernetes NodePort est ouverte par défaut afin que vous puissiez exposer des applications avec des services NodePort. Pour bloquer le trafic réseau entrant sur les services NodePort dans votre cluster, voir Contrôle du trafic entrant vers les services d'équilibreur de charge de réseau ou NodePort.
Ports de surveillance IBM : par défaut, IBM ouvre quelques ports sur votre cluster de sorte que le trafic réseau puisse être surveillé par IBM et pour permettre à IBM d'installer automatiquement des mises à jour de sécurité pour le maître Kubernetes.

L'accès depuis le maître de l' Kubernetes e vers le kubelet du nœud de travail est sécurisé par un tunnel Konnectivity. Pour plus d'informations, voir l'architecture d'IBM Cloud Kubernetes Service.

Qu'est-ce que la segmentation du réseau et comment puis-je la configurer pour un cluster Classic?

La segmentation du réseau décrit l'approche utilisée pour diviser un réseau en plusieurs sous-réseaux. Vous pouvez regrouper des applications et les données associées auxquelles accéder au sein d'un groupe particulier dans votre organisation. Les applications qui s'exécutent dans un sous-réseau ne peuvent pas voir ou accéder à des applications dans un autre sous-réseau. La segmentation du réseau limite également l'accès fourni à un utilisateur interne ou à un logiciel tiers et peut restreindre l'éventail d'activités malveillantes.

IBM Cloud Kubernetes Service fournit des VLAN IBM Cloud qui assurent des performances réseau et un isolement du réseau de qualité pour les noeuds worker. Un VLAN configure un groupe de noeuds worker et de pods comme s'ils étaient reliés physiquement au même câble. Les VLAN sont dédiés à votre compte IBM Cloud et ne sont pas partagés avec les clients IBM. Dans des clusters classiques, si vous disposez de plusieurs VLAN pour votre cluster, de plusieurs sous-réseaux sur le même VLAN ou d'un cluster classique multizone, vous devez activer une fonction VRF (Virtual Router Function) pour votre compte d'infrastructure IBM Cloud de sorte que vos noeuds worker puissent communiquer entre eux sur le réseau privé. Pour activer la fonction VRF, voir Activation de VRF. Pour vérifier si la fonction VRF est déjà activée, utilisez la commande ibmcloud account show. Si vous ne pouvez pas ou ne souhaitez pas activer VRF, activez Réseau local virtuel. Pour effectuer cette action, vous devez disposer de l'autorisation Réseau > Gérer l'infrastructure VLAN Spanning, ou vous pouvez demander au propriétaire du compte de l'activer. Pour vérifier si l'extension de VLAN est déjà activée, utilisez la commandeibmcloud ks vlan spanning get --region <region>.

Lorsque vous activez la fonction VRF ou Spanning VLAN pour votre compte, la segmentation du réseau est retirée de vos clusters.

Consultez le tableau suivant pour voir les options permettant d'obtenir une segmentation du réseau lorsque vous activez la fonction VRF ou Spanning VLAN pour votre compte.

Options de segmentation de réseau
Fonction de sécurité	Description
Configurer des règles réseau personnalisées avec Calico	Vous pouvez utiliser l'interface Calico intégrée pour configurer des règles réseau Calico personnalisées pour vos noeuds worker. Par exemple, vous pouvez autoriser ou bloquer le trafic réseau sur certaines interfaces réseau, pour des pods ou des services spécifiques. Pour configurer des règles de réseau personnalisées, vous devez installer l'interface de ligne de commande`calicoctl`.
Support pour les pare-feux réseau IBM Cloud	IBM Cloud Kubernetes Service est compatible avec toutes les offres de pare-feu IBM Cloud. Par exemple, vous pouvez configurer un pare-feu avec des règles réseau personnalisées afin d'assurer une sécurité réseau dédiée pour votre cluster standard et détecter et parer à des intrusions réseau. Par exemple, vous pouvez choisir de configurer un dispositif de routeur virtuel qui fera office de pare-feu et bloquera le trafic indésirable. Lorsque vous configurez un pare-feu, vous devez également ouvrir les adresses IP et les ports requis pour chaque région de manière à permettre au maître et aux noeuds worker de communiquer.

Que puis-je faire d'autre pour réduire la surface d'attaque externe des clusters Classic?

Plus vous exposez d'applications et de noeuds worker au public, plus les étapes pour vous protéger contre les attaques malveillantes provenant de l'extérieur sont nombreuses. Consultez le tableau suivant pour identifier les options permettant de préserver la confidentialité de vos applications et de vos noeuds worker.

Options de services et de noeuds worker privés
Fonction de sécurité	Description
Limiter le nombre d'applications exposées	Par défaut, vos applications et les services qui s'exécutent dans le cluster ne sont pas accessibles sur l'Internet public. Vous pouvez décider d'exposer vos applications au public, ou de faire en sorte que vos applications et services soient accessibles uniquement sur le réseau privé. Dans ce cas, vous pouvez tirer parti des fonctions de sécurité intégrées pour assurer la communication sécurisée entre les noeuds worker et les pods. Pour exposer des services et des applications sur l'Internet public, vous pouvez tirer parti de la prise en charge d'équilibreur de charge de réseau (NLB) et d'équilibreur de charge d'application (ALB) Ingress pour exposer vos services au public de manière sécurisée. Veillez à ce que seuls les services nécessaires soient exposés et consultez régulièrement la liste des applications exposées pour vous assurer qu'elles sont encore valides.
Garder vos noeuds worker privés	Lorsque vous créez un cluster, chaque cluster est automatiquement connecté à un VLAN privé. Ce VLAN privé détermine l'adresse IP privée qui est affectée à un noeud worker. Vous pouvez décider de garder vos noeuds worker privés en les connectant uniquement à un VLAN privé. N'oubliez pas que pour communiquer avec le serveur principal d' Kubernetes depuis votre machine locale et pour que IBM Cloud Kubernetes Service puisse se connecter aux services IBM Cloud qui ne prennent pas en charge de point de terminaison de service cloud privé, vous devez configurer la connectivité publique vers des URL et des adresses IP spécifiques. Si les services IBM Cloud auxquels vous souhaitez vous connecter disposent d'un noeud final de service cloud privé et si votre compte est activé pour VRF, le trafic réseau vers et à partir de ces services est automatiquement acheminé sur le réseau privé et aucune connexion de réseau public n'est requise. Afin de configurer la connectivité publique pour le cluster qui est connecté à un VLAN privé uniquement, vous pouvez configurer un pare-feu, par exemple, un dispositif de routeur virtuel, devant vos noeuds worker et activer le trafic réseau vers ces URL et ces adresses IP.
Limiter la connectivité Internet publique avec les noeuds de périphérie	Si vous ne créez pas de cluster avec une passerelle activée, chaque nœud worker est configuré pour accepter les pods d'application et l'équilibreur de charge associé ou les pods d'entrée. Vous pouvez étiqueter vos noeuds worker en tant que noeuds de périphérie pour forcer le déploiement des pods d'équilibreur de charge et des pods Ingress uniquement sur ces noeuds worker. En outre, vous pouvez appliquer une marque taint à vos nœuds worker pour que les pods d'application ne puissent pas planifier sur les nœuds périphériques. Avec les noeuds de périphérie, vous pouvez isoler la charge de travail du réseau dans votre cluster et garder privés d'autres noeuds dans le cluster.

Que faire si je souhaite connecter mon cluster à un centre de données sur site?

Pour connecter vos nœuds de travail et vos applications à un centre de données sur site, vous pouvez configurer un Virtual Router Appliance ou un Fortigate Security Appliance.

Segmentation de réseau et confidentialité pour les clusters de VPC

Quel trafic réseau est autorisé par défaut pour mon cluster VPC?

Par défaut, les nœuds de travail sont connectés à Sous-réseaux VPC sur le réseau privé uniquement et n'ont pas d'interface réseau publique. L'accès public à vos nœuds worker est bloqué. La sortie publique de vos nœuds worker n'est autorisée que si les travailleurs sont connectés à un sous-réseau VPC doté d'une passerelle publique.

Si vos noeuds worker doivent accéder à un noeud final public en dehors du cluster, vous pouvez activer une passerelle publique sur le sous-réseau VPC sur lequel les noeuds worker sont déployés. Par exemple, votre cluster VPC peut se connecter automatiquement à d'autres services IBM Cloud qui prennent en charge des noeuds finaux de service de cloud privé, par exemple, IBM Cloud Container Registry. Toutefois, si vous devez accéder à des services IBM Cloud qui prennent en charge uniquement les noeuds finaux de service cloud publics, vous pouvez connecter une passerelle publique au sous-réseau afin que vos pods puissent envoyer des demandes via le réseau public. L'ensemble du trafic sortant est autorisé pour les noeuds worker sur un sous-réseau via une passerelle publique connectée, mais tout le trafic entrant est toujours bloqué.

Si vous déployez des applications dans votre cluster qui doivent recevoir des demandes de trafic d'Internet, vous pouvez créer un équilibreur de charge VPC pour exposer vos applications. Pour autoriser le trafic réseau entrant vers vos applications, vous devez configurer votre équilibreur de charge VPC pour le trafic réseau entrant que vous souhaitez recevoir.

Les groupes de sécurité sont appliqués par défaut à votre instance VPC ainsi qu'à vos ALB et NLB VPC. Pour plus d'informations, voir Comprendre la mise en réseau sécurisée par défaut des clusters VPC et Créer et gérer des groupes de sécurité VPC.

Qu'est-ce que la segmentation du réseau et comment puis-je la configurer pour un cluster VPC?

IBM Cloud Kubernetes Service fournit des sous-réseaux IBM Cloud VPC qui assurent des performances réseau et un isolement du réseau de qualité pour les noeuds worker. Un sous-réseau VPC se compose d'une plage d'adresses IP privées spécifiées (bloc de routage CIDR) et configure un groupe de noeuds worker et de pods comme s'ils étaient connectés au même câble physique. Les sous-réseaux VPC sont dédiés à votre compte IBM Cloud et ne sont pas partagés avec les clients IBM.

Les sous-réseaux VPC fournissent un canal pour établir la connectivité entre les noeuds worker au sein du cluster. Tout système connecté à l'un des sous-réseaux privés du même VPC peut communiquer avec les noeuds worker. Par exemple, tous les sous-réseaux d'un VPC peuvent communiquer via un routage de couche 3 privé avec un routeur VPC intégré. Si vos clusters n'ont pas besoin de communiquer, vous pouvez réaliser la meilleure segmentation de réseau en créant les clusters dans des VPC distincts. Si vous possédez plusieurs clusters qui doivent communiquer entre eux, vous pouvez créer les clusters dans le même VPC. Bien que les sous-réseaux d'un VPC puissent être partagés par plusieurs clusters dans ce VPC, vous pouvez obtenir une meilleure segmentation du réseau en utilisant différents sous-réseaux pour les clusters au sein d'un VPC.

Pour réaliser davantage de segmentation de réseau privé entre les sous-réseaux VPC de votre compte, vous pouvez configurer des règles réseau personnalisées avec des listes de contrôle d'accès VPC. Lorsque vous créez un VPC, une liste de contrôle d'accès par défaut est créée au format allow-all-network-acl-<VPC_ID> pour le VPC. Les sous-réseaux que vous créez dans le VPC sont connectés à cette liste de contrôle d'accès par défaut. La liste de contrôle d'accès comprend une règle entrante et une règle sortante qui autorisent l'ensemble du trafic entre vos noeuds worker sur un sous-réseau et n'importe quel système sur les sous-réseaux dans le même VPC. Si vous souhaitez spécifier le trafic réseau privé qui est autorisé vers les noeuds worker présents sur vos sous-réseaux VPC, vous pouvez créer une liste de contrôle d'accès personnalisée pour chaque sous-réseau dans le VPC. Par exemple, vous pouvez créer un ensemble de règles ACL pour bloquer la plupart du trafic réseau entrant et sortant d'un cluster tout en autorisant la communication qui est nécessaire au bon fonctionnement du cluster.

Que puis-je faire d'autre pour réduire la surface d'attaque externe des clusters VPC?

Options de sécurité de réseau VPC
Fonction de sécurité	Description
Limiter le nombre d'applications exposées	Par défaut, vos applications et les services qui s'exécutent dans le cluster ne sont pas accessibles sur l'Internet public. Vous pouvez décider d'exposer vos applications au public, ou de faire en sorte que vos applications et services soient accessibles uniquement sur le réseau privé. Dans ce cas, vous pouvez tirer parti des fonctions de sécurité intégrées pour assurer la communication sécurisée entre les noeuds worker et les pods. Pour exposer des services et des applications sur l'Internet public, vous pouvez tirer parti de la prise en charge d'équilibreur de charge VPC et d'équilibreur de charge d'application (ALB) Ingress pour exposer vos services au public de manière sécurisée. Veillez à ce que seuls les services nécessaires soient exposés et consultez régulièrement la liste des applications exposées pour vous assurer qu'elles sont encore valides.
Limiter le trafic réseau public sortant à un sous-réseau avec une passerelle publique	Si des pods de vos noeuds worker doivent se connecter à un noeud final externe public, vous pouvez connecter une passerelle publique au sous-réseau sur lequel se trouvent ces noeuds worker. Vous pouvez isoler ce trafic réseau dans votre cluster en connectant une passerelle publique à un seul sous-réseau de votre cluster. Ensuite, vous pouvez définir des règles d'affinité pour déployer des pods d'application nécessitant un accès aux noeuds finaux externes uniquement sur le sous-réseau doté d'une passerelle publique connectée.

Selon le réseau auquel vous souhaitez connecter vos noeuds worker, vous pouvez choisir une solution VPN.

Exposition d'applications de manière sécurisée avec des services LoadBalancer et Ingress

Vous pouvez utiliser les services de réseau d'équilibreur de charge de réseau (NLB) et d'équilibreur de charge d'application (ALB) Ingress pour connecter vos applications à l'Internet public ou à des réseaux privés externes. Consultez les paramètres facultatifs suivants pour les équilibreurs de charge de réseau et les équilibreurs de charge d'application que vous pouvez utiliser pour satisfaire les exigences en matière de sécurité des applications de back end ou chiffrer le trafic qui circule dans votre cluster.

Puis-je utiliser des groupes de sécurité pour gérer le trafic réseau de mon cluster?

Clusters classiques : les groupes de sécurité IBM Cloud sont appliqués à l'interface réseau d'un serveur virtuel unique pour filtrer le trafic au niveau de l'hyperviseur. Si vous souhaitez gérer le trafic de chaque noeud worker, vous pouvez utiliser des groupes de sécurité. Lorsque vous créez un groupe de sécurité, vous devez autoriser le protocole VRRP, lequel est utilisé par IBM Cloud Kubernetes Service utilise pour gérer les adresses IP des équilibreurs de charge de réseau. Pour gérer de manière uniforme le trafic de votre cluster sur l'ensemble de vos nœuds de travail, utilisez les politiques Calico et Kubernetes.

Clusters VPC: les groupes de sécurité VPC sont appliqués à l'interface réseau d'un serveur virtuel unique pour filtrer le trafic au niveau de l'hyperviseur. Vous pouvez ajouter des règles entrantes et sortantes au groupe de sécurité par défaut de votre cluster pour gérer le trafic entrant et sortant sur un cluster de VPC. Pour plus d'informations, voir Comprendre la mise en réseau sécurisée par défaut des clusters VPC et Créer et gérer des groupes de sécurité VPC.

Étant donné que les nœuds de travail de votre cluster VPC existent dans un compte de service et ne sont pas répertoriés dans le tableau de bord de l'infrastructure VPC, vous ne pouvez pas créer un groupe de sécurité et l'appliquer à vos instances de noeud de travail. Vous pouvez uniquement modifier des groupes de sécurité existants créés pour vous.

Comment puis-je sécuriser l'adresse IP source au sein du cluster?

Dans les équilibreurs de charge de réseau version 2.0, l'adresse IP source de la demande client est conservée. Toutefois, dans les équilibreurs de charge de réseau version 1.0 et dans tous les équilibreurs de charge d'application Ingress, l'adresse IP source de la demande client n'est pas conservée. Lorsqu'une demande client vers votre application est envoyée à votre cluster, elle est acheminée à un pod pour l'équilibreur de charge de réseau (NLB) 1.0 ou l'équilibreur de charge d'application (ALB). S'il n'existe aucun pod d'application sur le même noeud worker que le pod de service d'équilibreur de charge, l'équilibreur de charge de réseau ou l'équilibreur de charge d'application transmet la demande à un pod d'application sur un autre noeud worker. L'adresse IP source du package est remplacée par l'adresse IP publique du noeud worker sur lequel s'exécute le pod d'application.

Conserver l'adresse IP du client est pratique, notamment lorsque les serveurs d'applications doivent appliquer des règles de sécurité et de contrôle d'accès. Pour conserver l'adresse IP source d'origine de la demande client, vous pouvez activer la conservation de l'adresse IP source pour les équilibreurs de charge de réseau (NLB) version 1.0 ou les équilibreurs de charge d'application (ALB) Ingress.

Comment puis-je effectuer la terminaison TLS avec les services LoadBalancer et Ingress?

Le service Ingress offre des terminaisons TLS à deux points précis dans le flux de trafic :

Décompresser le package à la réception : par défaut, l’ALB Ingress assure l’équilibrage de charge du trafic réseau HTTP vers les applications de votre cluster. Pour équilibrer la charge des connexions HTTPS entrantes, vous pouvez configurer l'équilibreur de charge d'application pour déchiffrer le trafic réseau et transférer la demande déchiffrée aux applications exposées dans votre cluster. Si vous utilisez le sous-domaine Ingress fourni par IBM, vous pouvez utiliser le certificat TLS fourni par IBM. Si vous utilisez un domaine personnalisé, vous pouvez utiliser votre propre certificat TLS pour gérer la terminaison TLS.
Chiffrer à nouveau le package avant de le transférer vers les applications en amont : l'équilibreur de charge d’application déchiffre les demandes HTTPS avant de transférer le trafic dans vos applications. Si vous disposez d'applications nécessitant HTTPS et que vous devez chiffrer le trafic avant son transfert vers ces applications en amont, vous pouvez utiliser l'annotation ssl-services. Si vos applications en amont peuvent traiter TLS, vous pouvez éventuellement fournir un certificat qui est inclus dans un secret TLS pour l'authentification unidirectionnelle ou mutuelle.

Pour sécuriser la communication entre services, vous pouvez utiliser l'authentification mutuelle TLS d' Istio. Istio est un service open source qui fournit aux développeurs un moyen de connecter, sécuriser, gérer et surveiller un réseau de microservices, appelé également maillage de services, sur des plateformes d'orchestration de cloud, telles que Kubernetes.

Stockage de persistance

Passez en revue les options prises en charge pour le chiffrement et la protection de vos données sur le stockage persistant dans IBM Cloud.

Par défaut, toutes les solutions de stockage IBM Cloud chiffrent automatiquement vos données au repos avec une clé de chiffrement gérée par IBM sans coût supplémentaire. Pour plus d'informations, voir les liens suivants.

Selon le type de stockage que vous choisissez, vous pouvez configurer un chiffrement supplémentaire avec IBM Key Protect afin de protéger vos données en transit et au repos avec votre clé de chiffrement.

Vous pouvez également recourir à un service de base de données IBM Cloud, comme IBM Cloudant NoSQL DB, pour conserver les données dans une base de données située hors du cluster. Les données stockées dans un service de base de données Cloud sont accessibles entre les clusters, les zones et les régions. Pour plus d'informations sur la sécurité, consultez la documentation IBM Cloud relative au service de base de données.

Surveillance et journalisation

La clé pour détecter des attaques malveillantes prenant pour cible votre cluster est la surveillance et la journalisation appropriées des métriques et de tous les événements qui se produisent dans le cluster. Cela peut également vous aider à comprendre la capacité du cluster et la disponibilité des ressources de votre application de sorte à prévoir en conséquence la protection de vos applications pour éviter des temps d'indisponibilité.

IBM surveille-t-il mon cluster?

Chaque maître cluster est surveillé en permanence par IBM pour contrôler et résoudre les attaques de déni de service (DOS) au niveau processus. IBM Cloud Kubernetes Service analyse automatiquement chaque nœud sur lequel le maître est déployé pour rechercher les vulnérabilités qui se trouvent dans Kubernetes et les correctifs de sécurité spécifiques au système d'exploitation. Si des vulnérabilités sont détectées, IBM Cloud Kubernetes Service applique automatiquement les correctifs appropriés et résout les vulnérabilités pour l'utilisateur.

Quelles informations sont consignées?

Par défaut, IBM Cloud Kubernetes Service collecte automatiquement les journaux pour les composants de cluster suivants :

Conteneurs : journaux écrits dans STDOUT ou STDERR.
Applications : journaux écrits dans un chemin spécifique dans votre application.
Noeuds worker : journaux du système d'exploitation Ubuntu envoyés vers /var/log/syslog et /var/log/auth.log.
Serveur d'API Kubernetes : toutes les actions liées au cluster envoyées au serveur d'API Kubernetes sont consignées à des fins d'audit, notamment l'heure, l'utilisateur et la ressource concernée. Pour plus d'informations, consultez les journaux d'audit d' Kubernetes. Vous pouvez accéder à ces journaux à l'aide d'IBM Cloud Logs.
Ingress : journaux d'un équilibreur de charge d'application (ALB) Ingress qui gère le trafic réseau entrant.
Composants système Kubernetes : journaux de kubelet, kube-proxy, ainsi que d'autres composants exécutés dans l'espace de noms kube-system.

Pour accéder aux journaux de composant de cluster, vous pouvez choisir d'acheminer vos journaux vers IBM Cloud Logs}}, un serveur externe ou une solution de journalisation tierce. Pour plus d'informations, voir Choix d'une solution de journalisation.

Comment puis-je surveiller l'état et les performances de mon cluster?: Vous pouvez vérifier la santé, la capacité et les performances de vos applications, services et noeuds worker en surveillant les composants du cluster et les ressources de calcul à partir de la console ou de l'interface de ligne de commande IBM Cloud Kubernetes Service, par exemple, l'utilisation de l'UC et de la mémoire. Pour afficher des métriques plus détaillées pour un cluster standard ou vos applications, vous pouvez configurer un agent de surveillance dans votre cluster afin d'envoyer des métriques à IBM Cloud Monitoring. Vous pouvez également installer des solutions de surveillance tierces, telles qu' Prometheus ou utiliser les indicateurs fournis dans le tableau de bord d' Kubernetes. Pour plus d'informations, voir Choix d'une solution de surveillance.

Pour configurer un système de détection d’intrusion basé sur l’hôte (HIDS) et la surveillance des journaux d’événements de sécurité (SELM), installez des outils tiers conçus pour surveiller votre cluster et vos applications conteneurisées afin de détecter toute intrusion ou utilisation abusive, tels que Twistlock ou le projet Falco Sysdig.

Comment puis-je effectuer un audit des événements qui se produisent dans mon cluster?: Vous pouvez configurer IBM Cloud Logs dans votre cluster IBM Cloud Kubernetes Service. Pour plus d'informations, consultez la documentation En savoir plus sur IBM Cloud Logs.
Quelles sont les options dont je dispose pour activer la confiance dans mon cluster?: Par défaut, IBM Cloud Kubernetes Service fournit de nombreuses fonctions pour les composants de votre cluster afin que vous puissiez déployer vos applications conteneurisées dans un environnement très sécurisé. Augmentez le niveau de confiance de votre cluster pour vous assurer que ce qui se passe dans votre cluster correspond bien à ce que vous aviez prévu. Vous pouvez mettre en oeuvre la fonction de confiance dans votre cluster de plusieurs manières, comme illustré dans le diagramme suivant.

Déploiement de conteneurs avec du contenu fiable. — Déploiement de conteneurs avec du contenu fiable

Approbation de contenu pour vos images : garantissez l'intégrité de vos images en activant l'approbation de contenu dans votre registre IBM Cloud Container Registry. Avec un contenu sécurisé, vous pouvez vérifier que les personnes qui peuvent signer les images sont dignes de confiance. Lorsque les signataires de confiance envoient des images par commande push dans votre registre, les utilisateurs peuvent extraire le contenu signé de sorte à pouvoir vérifier la source de l'image. Pour plus d'informations, voir la rubrique sur la signature d'images pour contenu sécurisé.
Mise en application de la sécurité des images de conteneur : utilisez un contrôleur d'admission avec des règles personnalisées de manière à pouvoir vérifier les images de conteneur avant de les déployer. Avec un projet de mise en application de la sécurité des images de conteneur tel que Portieris, vous contrôlez l'origine de déploiement des images et vérifiez si elles respectent les exigences en matière d'approbation de contenu. Si un déploiement n'est pas conforme aux règles que vous avez définies, Security Enforcement empêche les modifications sur votre cluster.
Scanner de vulnérabilité de contenu : par défaut, Vulnerability Advisor scanne les images stockées dans IBM Cloud Container Registry afin de rechercher de potentielles vulnérabilités en matière de sécurité. Pour plus d'informations, voir la rubrique relative à la gestion de la sécurité des images avec l'assistant de détection des vulnérabilités.
IBM Cloud Compliance Manager : Lorsque vous activez IBM Cloud Compliance Manager, vous pouvez afficher des rapports sur le trafic réseau suspect qu'il soit sortant et entrant. Pour plus d'informations, voir la documentation IBM Cloud Compliance Manager.
IBM Cloud® Secrets Manager : Vous pouvez stocker vos secrets entrants et Kubernetes dans IBM Cloud® Secrets Manager. Lorsque vous intégrez Secrets Manager dans votre cluster, vous définissez une instance Secrets Manager par défaut où tous les secrets de sous-domaine entrant sont téléchargés. Pour plus d'informations, voir Configuration de Secrets Manager dans votre cluster Kubernetes Service.

Image et registre

Chaque déploiement repose sur une image qui contient les instructions de lancement du conteneur qui exécute votre application. Ces instructions comprennent le système d'exploitation dans le conteneur et d'autres logiciels que vous souhaitez installer. Pour protéger votre application, vous devez protéger l'image et mettre en place des vérifications pour contrôler l'intégrité de l'image.

Dois-je utiliser un registre public ou privé pour stocker mes images?: Des registres publics, comme Docker Hub, peuvent être utilisés pour vous familiariser avec les images Docker et Kubernetes et créer votre première application conteneurisée dans un cluster. Mais dans le cadre d'applications d'entreprise, évitez les registres que vous ne connaissez pas ou auxquels vous ne faites pas confiance afin de protéger votre cluster contre les images malveillantes. Conservez vos images dans un registre privé, tel que celui qui est fourni dans IBM Cloud Container Registry et veillez à contrôler l'accès au registre et le contenu de l'image à envoyer.
Pourquoi est-il important de vérifier la présence de vulnérabilités dans les images?: Les recherches montrent que les attaques les plus malveillantes tirent parti des vulnérabilités logicielles connues et de configurations système présentant des faiblesses. Lorsque vous déployez un conteneur à partir d'une image, le conteneur se lance avec le système d'exploitation et d'autres fichiers binaires que vous avez décrits dans l'image. Tout comme pour protéger votre machine virtuelle ou physique, vous devez éliminer les vulnérabilités connues liées au système d'exploitation et aux fichiers binaires que vous utilisez dans le conteneur afin d'empêcher les utilisateurs non autorisés d'accéder à votre application.

Pour protéger vos applications, envisagez de traiter les domaines suivant :

Automatiser le processus de génération et limiter les droits d'accès : Automatise le processus pour générer votre image de conteneur à partir de votre code source afin d'éliminer les variations et les défauts du code source. En intégrant le processus de construction dans votre pipeline CI/CD, vous pouvez garantir que votre image est analysée et construite uniquement si elle passe avec succès les contrôles de sécurité que vous avez spécifiés. Pour éviter que les développeurs appliquent des correctifs logiciels à des images sensibles, limitez le nombre de personnes de votre organisation ayant accès au processus de construction.
Analysez les images avant de les déployer en production : Veillez à analyser chacune des images avant de déployer un conteneur à partir de ces dernières. Si vous utilisez, par exemple, IBM Cloud Container Registry, toutes les images sont automatiquement analysées pour détecter d'éventuelles vulnérabilités lorsque vous insérez l'image dans votre espace de noms. Si des vulnérabilités sont détectées, envisagez de les éliminer ou bloquez le déploiement pour ces images. Trouvez une personne ou une équipe de votre organisation chargée de surveiller et de résoudre les vulnérabilités. En fonction de votre structure organisationnelle, cette personne peut faire partie d'une équipe de sécurité, d'exploitation ou de déploiement. Activez l'approbation de contenu pour que les images soient approuvées par un signataire de confiance avant d'être insérées dans le registre de conteneur. Ensuite, installez le contrôleur d'admission du projet open source Portieris afin de bloquer les déploiements de conteneurs à partir d'images non signées.
Analyse régulièrement les conteneurs en cours d'exécution :. Même si vous avez déployé un conteneur à partir d'une image qui a réussi le test de vérification des vulnérabilités, le système d'exploitation ou les fichiers binaires qui s'exécutent dans le conteneur peuvent devenir vulnérables au fil du temps. Pour protéger votre application, vous devez vous assurer que les conteneurs en cours d'exécution font l'objet d'analyses régulières pour pouvoir détecter les vulnérabilités et y remédier. Selon l'application, pour renforcer la sécurité, vous pouvez configurer une tâche qui supprime les conteneurs vulnérables dès qu'ils sont détectés.

Sécurité pour les images et les déploiements
Fonction de sécurité	Description
Référentiel d'images privées de Docker sécurisé dans IBM Cloud Container Registry	Configuration de votre propre Docker Référentiel d'images dans un registre d'images privées multi-locataires, hautement disponible et évolutif hébergé et géré par IBM. En utilisant le registre, vous pouvez créer, stocker en toute sécurité et partager des images Docker entre les utilisateurs du cluster. /n En savoir plus sur Sécurisation de vos renseignements personnels lorsque vous travaillez avec des images de conteneur.
Push images avec contenu de confiance uniquement	Vérifiez l'intégrité de vos images en activitant Confiance de contenu dans votre référentiel d'images. Avec un contenu sécurisé, vous pouvez vérifier que les personnes qui peuvent signer les images sont dignes de confiance et envoyer des images à l'espace de noms d'un registre spécifique. Une fois que les signataires de confiance ont fait insérer une image dans un espace de nom de registre, les utilisateurs peuvent extraire le contenu signé afin qu'ils puissent vérifier l'éditeur et l'intégrité de l'image.
Analyses de vulnérabilité automatiques	Lorsque vous utilisez IBM Cloud Container Registry, vous pouvez utiliser l'analyse de sécurité intégrée fournie par Conseiller en vulnérabilités. Chaque image envoyée par commande push à l'espace de noms de votre registre est automatiquement analysée pour détection de vulnérabilités face à une base de données recensant les problèmes CentOS, Debian, Red Hat et Ubuntu connus. Si des vulnérabilités sont trouvées, l'assistant de vulnérabilité fournit des instructions pour les résoudre afin d'assurer l'intégrité et la sécurité de l'image.
Bloquer les déploiements à partir d'images vulnérables ou d'utilisateurs non sécurisés	Créer un contrôleur d'admission avec des règles personnalisées pour que vous puissiez vérifier les images de conteneur avant de les déployer. Grâce au projet open source Portieris, vous contrôlez l'origine du déploiement des images et vous vous assurez qu'elles répondent aux exigences de fiabilité du contenu. Si un déploiement ne répond pas aux règles définies, le contrôleur d'admission bloque le déploiement dans votre cluster.

De quelles options dispose-je pour analyser les conteneurs en cours d'exécution à la recherche de vulnérabilités?: Vous pouvez installer des solutions tierces dans votre cluster, telles que Twistlock ou StackRox, afin d'analyser les conteneurs en cours d'exécution et de bloquer les activités malveillantes dès leur détection.

Isolement et sécurité des conteneurs

Lorsque vous exécutez plusieurs applications dans votre cluster, vous voulez faire en sorte que vos charges de travail s'exécutent isolément les unes des autres et limiter les droits de vos pods au sein du cluster pour éviter les attaques par déni de service ou de voisins gênants.

Qu'est-ce qu'un espace de noms Kubernetes et pourquoi devrais-je l'utiliser?: Les espaces de noms Kubernetes constituent un moyen de partitionner virtuellement un cluster et permettent d'isoler vos déploiements et les groupes d'utilisateurs qui souhaitent transférer leur charge de travail sur le cluster. Avec les espaces de noms, vous pouvez organiser les ressources sur les noeuds worker, ainsi que sur les zones dans les clusters multizone.; Chaque cluster est configuré avec un ensemble d'espaces de noms Kubernetes par défaut qui incluent les déploiements et les services requis pour qu'IBM Cloud Kubernetes Service s'exécute correctement et gère le cluster. Pour plus d'informations, voir l'architecture de service.; Les administrateurs de cluster ont automatiquement accès à ces espaces de noms et peuvent configurer des espaces de noms supplémentaires dans le cluster.

Pour chaque espace de noms présent dans le cluster, veillez à configurer des politiques RBAC appropriées afin de limiter l'accès à cet espace de noms, de contrôler ce qui y est déployé et de définir des quotas de ressources et des plages de limites adaptés.

Dois-je configurer un cluster à locataire unique ou à locataires multiples?

Dans un cluster à service exclusif, vous créez un cluster pour tous les groupes de personnes qui doivent exécuter des charges de travail dans un cluster. En général, cette équipe est chargée de gérer le cluster en veillant à le configurer et à le sécuriser correctement. Les clusters à service partagé utilisent plusieurs espaces de noms pour isoler les titulaires et leurs charges de travail.

Choisir entre un cluster mono-locataire et un cluster multi-locataires. — Cluster mono-locataire ou cluster multi-locataires

Le choix de l'option Cluster à service exclusif ou cluster à service partagé dépend du nombre d'équipes qui doivent exécuter des charges de travail dans un cluster, de leurs exigences en matière de service, de la taille du service et du niveau d'isolement que vous souhaitez atteindre pour vos charges de travail.

L'option Cluster à service exclusif peut vous convenir si vous disposez de nombreuses équipes avec des services complexes, chaque équipe devant contrôler le cycle de vie du cluster. Ce contrôle comprend la liberté de décider du moment opportun pour mettre à jour un cluster ou de choisir les ressources pouvant être déployées sur le cluster. Vous pouvez également configurer un cluster à service exclusif pour autoriser des pods privilégiés sans faire courir le risque à d'autres locataires d'être compromis. N'oubliez pas que la gestion d'un cluster nécessite une connaissance approfondie de Kubernetes et de l'infrastructure afin de garantir la capacité du cluster et la sécurité de vos déploiements.

Les clusters à service partagé utilisent des espaces de noms Kubernetes pour isoler des locataires et sont habituellement gérés par une équipe distincte qui n'appartient pas à l'un des locataires. Un cluster à service partagé peut être approprié si plusieurs de vos équipes doivent exécuter de petites charges de travail dans un cluster et lorsque la création d'un cluster à service exclusif hautement disponible sur plusieurs zones ne vous permet pas de réaliser les économies souhaitées. Alors que les clusters à service partagé nécessitent en principe moins de personnes pour gérer et administrer le cluster, il se peut qu'ils ne fournissent pas le niveau d'isolement dont vous avez besoin et qu'ils induisent plus de complexité dans les domaines suivants :

Accès : lorsque vous mettez en place plusieurs espaces de noms, vous devez configurer des règles RBAC adéquates pour chaque espace de noms afin d'assurer l'isolement des ressources. Les règles RBAC sont complexes et nécessitent une connaissance approfondie de Kubernetes.
Pods privilégiés : si un locataire dans un cluster à service partagé doit exécuter des pods privilégiés, ces pods peuvent accéder à d'autres espaces de noms dans le cluster ou endommager l'hôte de calcul partagé. Contrôler les pods privilégiés est une tâche complexe qui exige des efforts et des compétences techniques approfondies. Utilisez les politiques de sécurité des pods (PSP) pour contrôler les ressources que vos locataires peuvent déployer dans le cluster.
Règles réseau : étant donné que vos noeuds worker sont connectés au même réseau privé, vous devez faire en sorte de mettre en place des règles réseau strictes afin d'empêcher les pods d'accéder aux pods situés dans d'autres espaces de noms.
Limitation des ressources de calcul : afin de garantir que chaque équipe dispose des ressources nécessaires pour déployer des services et exécuter des applications dans le cluster, vous devez définir des quotas de ressources pour chaque espace de noms. Les quotas de ressources déterminent les contraintes de déploiement, telles que le nombre de ressources Kubernetes que vous pouvez déployer, ainsi que la quantité de CPU et de mémoire pouvant être consommée par ces ressources. Après avoir défini un quota, les utilisateurs doivent inclure des limites et des demandes de ressources dans leurs déploiements.
Ressources de cluster partagées : si vous exécutez plusieurs titulaires dans un cluster, certaines ressources du cluster, comme par exemple l'équilibreur de charge d'application (ALB) Ingress ou les adresses IP portables sont partagées entre les différents titulaires. Des services plus petits peuvent avoir des difficultés à utiliser des ressources partagées s'ils se retrouvent en concurrence avec des services plus importants dans le cluster.
Mises à jour : vous pouvez exécuter une seule version d'API Kubernetes à la fois. Toutes les applications qui s'exécutent dans un cluster doivent se conformer à la version d'API Kubernetes en cours indépendamment de l'équipe propriétaire de l'application. Lorsque vous souhaitez effectuer la mise à jour d'un cluster, vous devez veiller à ce que toutes les équipes soient prêtes à basculer vers une nouvelle version d'API Kubernetes et à ce que les applications soient mises à jour en conséquence. Cela signifie également que les équipes individuelles ont moins de contrôle sur la version d'API Kubernetes qu'elles souhaitent exécuter.
Modifications de la configuration du cluster : si vous envisagez de modifier la configuration du cluster ou de replanifier des charges de travail sur de nouveaux noeuds worker, vous devez transférer les modifications aux différents titulaires. Ce transfert nécessite davantage de synchronisation et de tests par rapport à un cluster à service exclusif.
Processus de communication : lorsque vous gérez plusieurs titulaires, pensez à configurer un processus de communication de sorte que les titulaires sachent à qui s'adresser en cas de problème avec le cluster ou quand ils ont besoin de ressources supplémentaires pour leurs services. Ce processus de communication suppose également d'informer vos titulaires de toutes les modifications effectuées dans la configuration du cluster, ainsi que des mises à jour planifiées.

Bien que le coût des clusters à service exclusif et des clusters à service partagé soit à peu près le même, les clusters à service exclusif fournissent un niveau d'isolement plus élevé que les espaces de noms inclus dans un cluster à service partagé. Pour obtenir un meilleur isolement de charge de travail, utilisez les clusters à service exclusif.

Les règles réseau Kubernetes protègent les pods du trafic réseau interne. Par exemple, si la plupart ou tous les gousses n'ont pas besoin d'accéder à des nacelles ou des services spécifiques, et que vous voulez vous assurer que les gousses par défaut ne peuvent pas accéder à ces gousses ou services, vous pouvez créer une stratégie de réseau Kubernetes pour bloquer le trafic de sortie vers ces gousses ou ces services. Les règles réseau Kubernetes peuvent également vous permettre d'appliquer l'isolement des charges de travail entre les espaces de noms en contrôlant la façon dont les pods et les services présents dans différents espaces de noms peuvent communiquer.

Comment puis-je contrôler les autorisations des pods?: Par défaut, chaque cluster active le contrôleur d'admission de la politique de sécurité des pods Kubernetes, que vous pouvez utiliser pour définir les conditions qu'un pod doit remplir pour être déployé dans un espace de noms. Les règles de sécurité de pod vous aident à contrôler l'utilisation des conteneurs privilégiés, des espaces de noms racine, des réseaux et ports d'hôte, des types de volume, des systèmes de fichiers hôte et des droits Linux, tels que lecture seule ou les ID de groupes.
Que puis-je faire d'autre pour protéger mon conteneur?: Limitez le nombre de conteneurs privilégiés. Les conteneurs s'exécutent sous forme de processus Linux distinct sur l'hôte de calcul qui est isolé des autres processus. Bien que les utilisateurs disposent des droits d'accès de l'utilisateur root dans le conteneur, les droits de cet utilisateur sont limités en dehors du conteneur afin de protéger d'autres processus Linux, le système de fichiers hôte et les unités hôte. Certaines applications nécessitent l'accès au système de fichiers hôte ou des droits avancés pour fonctionner correctement. Vous pouvez exécuter des conteneurs en mode privilégié pour autoriser au conteneur le même accès que les processus qui s'exécutent sur l'hôte de calcul.; Tenez compte du fait que les conteneurs privilégiés peuvent causer des dommages considérables au cluster et à l'hôte de calcul sous-jacent, s'ils deviennent compromis. Essayez de limiter le nombre de conteneurs qui s'exécutent en mode privilégié et pensez à modifier la configuration de votre application pour qu'elle puisse s'exécuter sans droits avancés.

Si vous souhaitez empêcher l'exécution de conteneurs privilégiés dans votre cluster, pensez à configurer des politiques de sécurité personnalisées pour les pods.

Appliquer les paramètres de sécurité du système d'exploitation aux pods: Vous pouvez ajouter la section securityContext à vos pods pour contrôler l'ID utilisateur et l'ID de groupe autorisés à s'exécuter à l'intérieur du conteneur, ou l'ID utilisateur et l'ID de groupe propriétaires du chemin de montage du volume. La définition d'un ID utilisateur spécifique facilite le principe de modèle à moindre privilège. Si le contexte de sécurité ne spécifie pas d'utilisateur, Kubernetes utilise automatiquement l'utilisateur spécifié dans l'image du conteneur.; Si vous souhaitez utiliser securityContext pour définir l'ID utilisateur runAsUser ou l'ID groupe fsGroup, envisagez l'utilisation du stockage par blocs lorsque vous créez du stockage persistant. Le stockage NFS ne prend pas en charge fsGroup, et runAsUser doit être défini au niveau du conteneur et non pas au niveau du pod.
Définir les limites d'UC et de mémoire des conteneurs: Tous les conteneurs nécessitent une quantité spécifique d'UC et de mémoire pour démarrer correctement et poursuivre leur exécution. Vous pouvez définir des demandes de ressources et des limites de ressources d' Kubernetes s pour vos conteneurs ou vos pods afin de limiter la quantité de CPU et de mémoire qu'ils peuvent consommer. Si aucune limite d'UC et de mémoire n'est définie et que le conteneur est occupé, le container utilise la totalité des ressources disponibles. Cette forte consommation de ressources peut affecter d'autres conteneurs sur le nœud worker qui n'ont pas suffisamment de ressources pour démarrer ou s'exécuter correctement et exposer votre nœud worker aux attaques de refus de service.
Imposer l'authentification gérée par des règles: Vous pouvez ajouter une annotation Ingress dans vos déploiements afin de contrôler l'accès à vos services et à vos API. En utilisant App ID et la sécurité déclarative, vous pouvez garantir l'authentification des utilisateurs et la validation de jeton.

Stockage d'informations personnelles

Vous êtes chargé d'assurer la sécurité de vos informations personnelles dans les ressources et les images de conteneur Kubernetes. Ces informations comprennent vos nom, adresse, numéro de téléphone, adresse e-mail ou tout autre information permettant d'identifier, de contacter ou de localiser vous, vos clients ou d'autres personnes.

Utilisez un secret Kubernetes pour stocker vos informations personnelles: Ne stockez les informations personnelles que dans les ressources Kubernetes conçues pour contenir des informations personnelles. Par exemple, n'utilisez pas votre nom dans le nom d'un espace de nom, de déploiement, de service ou de configuration Kubernetes. Pour garantir une protection et un chiffrement adéquats, stockez plutôt vos informations personnelles dans des secrets.; Pour une gestion centralisée de tous les secrets entre les clusters et une injection au moment de l'exécution de l'application, essayez IBM Cloud Secrets Manager.
Utilisez un secret Kubernetes imagePullSecret pour stocker les données d'identification de registre d'images: Ne stockez pas d'informations personnelles dans des images de conteneur ou des espaces de noms de registre. Pour garantir une protection et un chiffrement adéquats, stockez les identifiants du registre dans et Kubernetes imagePullSecrets les autres informations personnelles dans secrets à la place. Notez que si des informations personnelles sont stockées dans une couche précédente d'image, la suppression d'une image ne suffit pas forcément pour supprimer ces informations personnelles.

Pour configurer le chiffrement de vos secrets, voir Chiffrement des secrets Kubernetes à l'aide d'un fournisseur KMS (Key Management Service).

Bulletins de sécurité Kubernetes

En cas de vulnérabilités détectées dans Kubernetes, Kubernetes publie des CVE dans des bulletins de sécurité pour informer les utilisateurs et indiquer les actions que doivent effectuer les utilisateurs pour résoudre ces vulnérabilités. Les bulletins de sécurité qui concernent les utilisateurs IBM Cloud Kubernetes Service ou la plateforme IBM Cloud sont publiés dans les bulletins de sécurité IBM Cloud.

Certaines vulnérabilités (CVE) nécessitent une mise à jour de correctif de dernier niveau pour une version Kubernetes que vous pouvez installer dans le cadre d'un processus de mise à jour de cluster normal dans IBM Cloud Kubernetes Service. Veillez à appliquer les correctifs de sécurité à temps pour protéger votre cluster contre les attaques malveillantes. Pour plus d’informations sur le contenu d’un correctif de sécurité, consultez les informations relatives à la version d’ Kubernetes.