Cette rubrique fournit une présentation descriptive de haut niveau de la sécurité Tanzu Kubernetes Grid.
Tanzu Kubernetes Grid (TKG) propose une expérience cohérente et native avec Kubernetes dans n'importe quel cloud. Les contrôles de sécurité peuvent donc être appliqués de manière cohérente dans les environnements à l'aide de plusieurs composants préconditionnés dans TKG, qui aident à obtenir une meilleure sécurité pour les clusters de charge de travail et leur environnement sous-jacent. Le modèle de responsabilité partagée s'applique également pour la sécurisation des environnements qui exécutent des clusters provisionnés par Tanzu Kubernetes Grid pour toutes les couches de la pile cloud native : Code, Conteneur, Cluster et Cloud.
Ce document est une tentative de partage de l’état actuel de la sécurité TKG. À chaque nouvelle version, VMware poursuit son engagement envers l'amélioration de la sécurité de TKG, de sorte que celle-ci devienne indissociable du produit, tout en maintenant une expérience transparente pour les développeurs. Toutes les recommandations de ce document doivent être prises en compte en fonction de la posture de sécurité et de la propension au risque de l'organisation.
Les détails de sécurité diffèrent entre TKG déployé avec un superviseur vSphere with Tanzu et TKG déployé avec un cluster de gestion autonome. L'histoire de la sécurité des déploiements basés sur un superviseur est couverte dans la documentation vSphere with Tanzu liée ci-dessous. Le reste de cette rubrique décrit les déploiements TKG avec des clusters de gestion autonomes.
Tanzu Kubernetes Grid v2.0 sur vSphere 8 avec superviseur est un module complémentaire à vSphere. Il exploite de nombreuses fonctionnalités vSphere, notamment la sécurité vSphere et vCenter SSO. Pour plus d'informations sur la sécurité de Tanzu Kubernetes Grid v2.0, reportez-vous à la section vSphere with Tanzu Security dans la documentation de vSphere 8.
Ce document concerne uniquement l'offre multicloud Tanzu Kubernetes Grid. La documentation officielle du produit et ses différences avec les autres offres sont décrites ici.
Pour obtenir des conseils de sécurité sur d'autres offres VMware Tanzu, reportez-vous aux sections suivantes :
Tanzu Kubernetes Grid Integrated Edition : Reportez-vous à la section Sécurité de Tanzu Kubernetes Grid Integrated Edition dans la documentation de TKGI.
Tanzu Mission Control : Reportez-vous à la section Mesures de sécurité dans VMware Tanzu Mission Control.
Politiques et pratiques VMware pour le développement logiciel sécurisé : Reportez-vous à la section Sécurité des produits VMware.
Les sections ci-dessous décrivent la sécurité dans et autour de TKG déployé avec un cluster de gestion autonome. Elles couvrent notamment les contrôles de sécurité utilisables intégrés au produit et les meilleures pratiques pour implémenter des contrôles de sécurité complémentaires qui protègent les environnements dans lesquels les clusters Tanzu Kubernetes Grid sont déployés.
Tanzu Kubernetes Grid exécute un code écrit par les développeurs d'applications, déployé en tant qu'espaces Kubernetes. Tanzu Kubernetes Grid est constitué de différents composants, dont un grand nombre sont open source et certains sont propriétaires VMware. Si le code de tous ces composants et applications est sécurisé, il améliore la sécurité de l'environnement exécutant les clusters provisionnés Tanzu Kubernetes Grid.
Tanzu Kubernetes Grid est développé conformément au processus de cycle de vie de développement de la sécurité VMware. En particulier, les meilleures pratiques suivantes sont mises en œuvre pour garantir la sécurité du produit Tanzu Kubernetes Grid :
Mettre à jour le modèle de risque pour chaque modification majeure de conception du produit.
Travailler sur des correctifs de haute priorité pour les observations résultant de l'exercice de modélisation des menaces.
Builds automatisés pour tous les composants principaux de Tanzu Kubernetes Grid afin de les compiler à partir du code source.
Participer au processus en amont pour les correctifs de sécurité, la gestion des versions et le tri des vulnérabilités.
Pour le code propriétaire VMware, avant de fusionner avec la branche main :
Implémenter des révisions du code homologue pour assurer une relecture.
Exécuter une analyse automatisée du code statique à l'aide d'outils tels que golint, gosec et govet.
Signer les fichiers binaires tels que kubectl ou tanzu-cli avec des clés de signature VMware.
Pour sécuriser le code des applications en conteneur exécutées sur Tanzu Kubernetes Grid, les ressources suivantes peuvent servir de référence utile :
Les conteneurs sont instanciés en tant que processus isolés d'espace de noms Linux, à l'aide d'images préconditionnées qui sont essentiellement des tarballs de toutes les dépendances d'exécution et du fichier binaire d'application pour exécuter l'application en conteneur. Tanzu Kubernetes Grid exécute ces conteneurs dans le cadre des espaces Kubernetes. De nombreux composants Tanzu Kubernetes Grid sont également conditionnés sous forme d'images de conteneur et sont configurés pour s'exécuter en tant qu'espaces (parfois en tant que DaemonSets Kubernetes ou espaces statiques). Les meilleures pratiques suivantes sont implémentées pour sécuriser les conteneurs des composants Tanzu Kubernetes Grid :
Analysez toutes les images de conteneur avec le scanneur de vulnérabilités pour les vulnérabilités CVE (Common Vulnerability and Exposures) lors d'une opération push vers le registre de conteneur de préparation.
Limitez l'accès push au registre de conteneur externe à l'équipe de publication de Tanzu Kubernetes Grid en suivant le principe du moindre privilège.
Utilisez un service géré de manière centralisée (LDAP) ou un compte robot qui automatise l'opération push des images de conteneur de la préparation à la production une fois les critères de publication respectés et les tests appropriés terminés.
Effectuez une évaluation de l'impact interne en documentant toutes les vulnérabilités non corrigées critiques dans les images de conteneur.
Corrigez les vulnérabilités ayant un impact majeur sur le produit [1][2] sans attendre la prochaine version mineure.
Mettez régulièrement à jour les composants Tanzu Kubernetes Grid vers des images de base plus récentes afin d'obtenir des correctifs pour les vulnérabilités récemment identifiées.
Dans la mesure du possible, préférez et effectuez la transition vers des images minimales pour tous les composants Tanzu Kubernetes Grid, et limitez les distributions d'images de base à un petit nombre, afin de réduire la surface d'application de correctifs pour toutes les images.
D'une manière générale, pour créer, exécuter et consommer des images de conteneur en toute sécurité, les ressources suivantes sont un guide utile :
Meilleures pratiques pour la sécurisation et le renforcement de la sécurité des images de conteneur
Déployer Harbor dans une charge de travail ou un cluster de services partagés
VMware conditionne des images du système d'exploitation de la machine de base avec leur version dans les versions de Tanzu Kubernetes (TKr), ainsi que les versions compatibles de Kubernetes et les composants connexes. Tanzu Kubernetes Grid utilise ensuite ces versions conditionnées du système d'exploitation, de Kubernetes et des composants pour créer des nœuds de cluster et de plan de contrôle. Pour plus d'informations, reportez-vous à la section Versions de Tanzu Kubernetes et images de nœuds personnalisées.
Chaque TKr publié utilise la dernière mise à jour stable et généralement disponible de la version du système d'exploitation qu'il conditionne, contenant tous les correctifs CVE et USN actuels à compter de la création de l'image. VMware recrée ces images de nœud (images OVA vSphere, AMI AWS et images de machine virtuelle Azure) avec chaque version de Tanzu Kubernetes Grid, et plus fréquemment lorsque cela est possible. Les fichiers image sont signés par VMware et ont des noms de fichier qui contiennent un identifiant de code de hachage unique.
Lorsqu'une CVE critique ou haute priorité est signalée, VMware collabore sur un correctif et, lorsque le correctif est publié, recrée toutes les images de nœud affectées, ainsi que les images de base de conteneur, afin d'inclure la mise à jour.
Les images de machine Ubuntu 20.04 pour les nœuds de cluster pour vSphere, AWS et Azure sont renforcées selon les normes CIS (Center for Internet Security) par défaut, avec AppArmor activé. Les images de machine Photon OS 3 sont renforcées par défaut selon les normes STIG (Security Technical Implementation Guides).
Vous pouvez installer et exécuter une version compatible FIPS de Tanzu Kubernetes Grid v1.5, dans laquelle les composants principaux utilisent des primitives de chiffrement fournies par une bibliothèque compatible FIPS basée sur le module BoringCrypto/BoringSSL. Ces composants principaux incluent les composants de Kubernetes, Containerd et CRI, les plug-ins CNI, CoreDNS et etcd.
Pour savoir comment installer une version compatible FIPS de Tanzu Kubernetes Grid, reportez-vous à la rubrique Version compatible FIPS de la section Préparer le déploiement des clusters de gestion dans la documentation TKG v1.5.
Un cluster Kubernetes est constitué de plusieurs composants qui font office de plan de contrôle du cluster et d'un ensemble de composants connexes et de nœuds worker qui aident à exécuter des charges de travail déployées. Il existe deux types de clusters dans la configuration de Tanzu Kubernetes Grid : le cluster de gestion et le cluster de charge de travail. Le cluster de gestion Tanzu Kubernetes Grid héberge tous les composants Tanzu Kubernetes Grid utilisés pour gérer les clusters de charge de travail. Les clusters de charge de travail qui sont déployés par les administrateurs Tanzu Kubernetes Grid sont ensuite utilisés pour exécuter les applications en conteneur. La sécurité du cluster est une responsabilité partagée entre les administrateurs du cluster Tanzu Kubernetes Grid, les développeurs et les opérateurs qui exécutent des applications sur des clusters provisionnés par Tanzu Kubernetes Grid. Cette section énumère les composants inclus avec Tanzu Kubernetes Grid par défaut qui peuvent aider à implémenter des meilleures pratiques de sécurité pour les clusters de gestion et de charge de travail.
Tanzu Kubernetes Grid dispose d'un module Pinniped qui permet un accès sécurisé aux clusters Kubernetes, comme décrit dans la section Gestion des identités et des accès.
Les opérateurs Tanzu Kubernetes Grid sont toujours responsables de l'octroi de l'accès aux ressources du cluster à d'autres utilisateurs de Kubernetes via le contrôle d'accès basé sur les rôles intégré. Les meilleures pratiques recommandées pour la gestion des identités dans les clusters provisionnés par Tanzu Kubernetes Grid sont les suivantes :
Limiter l'accès aux ressources du cluster en suivant le principe du moindre privilège.
Limitez l’accès aux clusters de gestion à l’ensemble approprié d’utilisateurs. Par exemple, fournissez l'accès uniquement aux utilisateurs responsables de la gestion de l'infrastructure et des ressources de cloud, mais pas aux développeurs d'applications. Cela est particulièrement important, car l'accès au cluster de gestion fournit par nature l'accès à tous les clusters de charge de travail.
Limiter l'accès d'administrateur du cluster pour les clusters de charge de travail à un ensemble approprié d'utilisateurs. Par exemple, les utilisateurs responsables de la gestion des ressources d'infrastructure et de plate-forme de votre organisation, mais pas les développeurs d'applications.
Avec Pinniped, connectez-vous à un fournisseur d'identité centralisé pour gérer les identités d'utilisateur autorisées à accéder aux ressources du cluster au lieu de se baser sur des fichiers kubeconfig générés par l'administrateur.
L'un des principaux avantages de Tanzu Kubernetes Grid est la capacité à gérer le cycle de vie complet de plusieurs clusters via un plan de gestion unique. Cela est important, car du point de vue de l'architecture mutualisée, la forme la plus élevée d'isolation entre des charges de travail non approuvées est possible lorsqu'elles s'exécutent dans des clusters Kubernetes distincts. Voici quelques-unes des valeurs par défaut configurées pour prendre en charge les charges de travail à locataires multiples dans Tanzu Kubernetes Grid :
Les nœuds ne sont pas partagés entre les clusters.
Les nœuds sont configurés pour héberger uniquement des charges de travail de conteneur.
Le plan de gestion s'exécute dans son propre cluster dédié pour permettre la séparation des problèmes avec les clusters de charge de travail.
Les composants de gestion Kubernetes (tels que api-server, scheduler, controller-manager, etc.) s'exécutent sur des nœuds dédiés. En outre, envisagez d'appliquer une règle d'audit pour détecter le déploiement d'espaces de charge de travail sur des nœuds de plan de contrôle.
La planification de l'espace d'application sur des nœuds dédiés pour les composants de gestion (mentionnés ci-dessus) est désactivée via les rejets de nœuds et les règles d'affinité.
Pour améliorer la sécurité dans un environnement à locataires multiples AWS, déployez les clusters de charge de travail sur un compte AWS différent de celui utilisé pour déployer le cluster de gestion. Pour déployer des clusters de charge de travail sur plusieurs comptes AWS, reportez-vous à la section Clusters sur différents comptes AWS.
Pour plus d'informations sur les éléments à prendre en compte pour la conception lors du déploiement d'environnements à locataires multiples, reportez-vous à la section Locataire de charge de travail.
Les exigences en matière d'isolation de charge de travail sont uniques pour chaque client. Par conséquent, pour isoler raisonnablement les charges de travail les unes des autres avec une tolérance de risque acceptable, vous devez déployer des efforts supplémentaires conformément au modèle de responsabilité partagée. Cela inclut la limitation du nombre de conteneurs qui doivent s'exécuter avec des privilèges plus élevés à quelques espaces de noms et l'implémentation de mécanismes approfondis de défense tels qu'AppArmor et SELinux au niveau de l'exécution, de l'espace et du nœud. Dans Tanzu Kubernetes Grid versions 1.6 et ultérieures, AppArmor est activé par défaut dans les images Ubuntu 20.04.
Ces configurations peuvent être appliquées de manière centralisée sur les espaces via les Stratégies de sécurité d'espace, particulièrement de la migration vers son remplacement : Contrôle d'admission de sécurité de l'espace.
Pour les cas d'utilisation avancés et la gestion des stratégies personnalisées, les ressources suivantes servent généralement de point de départ : OPA, Contrôle d'admission et Normes de sécurité d'espace
L'un des aspects essentiels d'une architecture de microservices consiste à créer des services qui n'ont qu'une seule fonction. Cela permet la séparation des problèmes et permet aux équipes d'avancer plus rapidement. Toutefois, cela augmente également le besoin de communiquer avec plusieurs microservices différents qui s'exécutent souvent dans le même cluster dans leurs propres espaces. Par conséquent, les meilleures pratiques suivantes doivent être prises en compte pour sécuriser ces communications au moment de l'exécution :
Stratégies réseau du moindre privilège (Least privilege network policies) : Antrea est le plug-in CNI par défaut activé dans Tanzu Kubernetes Grid. Pour en savoir plus sur son utilisation afin d'implémenter des stratégies réseau pouvant être appliquées en fonction de la tolérance de risque, reportez-vous à la documentation officielle Antrea. Pour utiliser un autre plug-in CNI de votre choix, suivez ce guide : Mise en réseau d'espaces et de conteneurs
TLS mutuel par défaut (Mutual TLS by default) : la responsabilité de l'implémentation de cette option incombe aux clients de Tanzu Kubernetes Grid. Elle peut être implémentée dans le cadre du manifeste de l'application ou à l'aide d'un maillage de services qui permet à un conteneur complémentaire de gérer la communication TLS pour le conteneur d'applications.
Protéger les secrets (Protect Secrets) : il existe plusieurs options différentes à choisir lors de la gestion des secrets dans un cluster Kubernetes. Pour une exécution rapide des options, reportez-vous à la section Gestion des secrets.
Pour garantir l'observabilité et la répudiation des ressources du cluster, y compris les espaces d'application, il est important d'activer l'audit et la surveillance des clusters provisionnés par Tanzu Kubernetes Grid. Tanzu Kubernetes Grid est fourni avec un ensemble d'extensions qui permettent aux administrateurs d'activer cette option en mode natif. Les guides suivants expliquent cela en détail :
Journalisation d'audit du serveur d'API et du système : comment activer la journalisation d'audit du serveur d'API ainsi que l'audit de niveau système (nœud) pour empêcher la répudiation de l'utilisation du cluster ? Tanzu Kubernetes Grid inclut une stratégie par défaut pour l'audit du serveur d'API. Il est recommandé de définir une stratégie appropriée pour le démon d'audit au niveau du nœud afin de garantir que la falsification des fichiers binaires d'exécution et de la configuration du conteneur puisse être détectée.
Transfert de journaux avec Fluent Bit : comment activer la collecte centralisée de journaux afin d'empêcher une perte de répudiation en raison de la falsification locale des journaux ?
Surveillance avec Prometheus et Grafana : comment activer l'observabilité des mesures du cluster et du système pour l'alerte et la visualisation afin de détecter des pics soudains de consommation de ressources en raison d'attaques par déni de service ?
En fonction de la menace pertinente décrite, certains ou tous les contrôles ci-dessus peuvent être appliqués à un cluster Tanzu Kubernetes Grid.
Les fournisseurs de cloud sont utilisés comme une ressource de sous-couche pour tous les clusters Kubernetes provisionnés par Tanzu Kubernetes Grid, qu'il s'agisse d'un déploiement sur site (par exemple, vSphere) ou sur un cloud public (par exemple, AWS, Azure ou Google Cloud). La sécurisation de l'infrastructure sous-jacente est généralement une responsabilité partagée entre les clients de Tanzu Kubernetes Grid et les fournisseurs de cloud. Voici quelques recommandations pour améliorer la sécurité du cloud sous-jacent dans les clusters provisionnés par Tanzu Kubernetes Grid :
Effectuez une rotation ou une mise à jour régulière de vos informations d'identification cloud à l'aide de ce guide (vSphere uniquement) : secrets de cluster Tanzu (En cas d'automatisation de la rotation, envisagez de la tester dans des environnements hors production pour observer et planifier toute interruption qu'elle peut entraîner).
Appliquez les autorisations de moindre privilège pour les informations d'identification du cloud, comme décrit dans la documentation des fournisseurs AWS, Azure et vSphere. Dans la mesure du possible, exécutez des clusters de gestion et de charge de travail dans des zones distinctes (VPC) et de pare-feu. Il s'agit du paramètre par défaut pour les clusters provisionnés par Tanzu Kubernetes Grid.
L'accès au nœud SSH, en particulier aux nœuds de plan de contrôle, doit être limité à un petit ensemble d'utilisateurs qui jouent le rôle d'administrateur d'infrastructure.
L'accès SSH doit être rarement utilisé, principalement en tant que procédure de contrôle telle que la perte des informations d'identification du cluster de gestion.
Confirmez que les ressources du cluster ne sont pas accessibles aux utilisateurs non authentifiés sur Internet. Les clients avec une tolérance de risque faible doivent déployer des clusters sans exposer le port du serveur d'API à Internet avec une configuration d'équilibrage de charge appropriée.
Isolez l'environnement Tanzu Kubernetes Grid (clusters de gestion et de charge de travail) dans des VPC dédiés ou derrière un pare-feu des autres charges de travail cloud non-Tanzu, afin de limiter le déplacement latéral et de réduire la surface d'attaque si un cluster est compromis.
Appliquez, testez et validez les scénarios de récupération d'urgence pour la redondance et la disponibilité multirégion entre les clusters.
Implémentez un plan de récupération après une perte de données causée par une corruption des données, des attaques par rançongiciel ou des catastrophes naturelles entraînant des dommages matériels physiques.
Envisagez d'utiliser la sauvegarde et la restauration natives des ressources du cluster avec Velero pour vous aider dans les scénarios de planification de récupération d'urgence et de récupération de données.
Ces recommandations s'ajoutent aux instructions générales sur la sécurité de n'importe quel fournisseur de cloud. Pour obtenir des instructions générales sur la sécurité cloud, reportez-vous à la documentation de sécurité officielle du fournisseur de cloud concerné.
En conclusion, ce document fournit une vue d'ensemble sur l'état actuel de la technologie et les contrôles de sécurité recommandés pouvant être appliqués à Tanzu Kubernetes Grid. Nous nous engageons à publier un logiciel Tanzu Kubernetes Grid toujours plus sécurisé, en gardant à l'esprit le besoin de bénéficier d'une expérience développeur transparente à chaque version.
Si vous avez des commentaires sur le document ou si vous avez des demandes de fonctionnalités liées à la sécurité, contactez votre représentant VMware.
Voici quelques ressources axées sur la sécurité et proposées par la communauté (CNCF/Kubernetes) en amont :
Kubernetes SIG Security 2020 Annual Report: mise à jour en cours pour 2021.
Cloud native security whitepaper (2020): mise à jour en cours pour 2021.
Cloud Native Security for your Clusters: section spécifique à Kubernetes en (2).
4 Cs model for Kubernetes Security : cette page emprunte sa structure de haut niveau à ce document.
Voici une liste de documents publiés sans ordre de préférence particulier par le gouvernement et les organismes de normalisation :
NSA/CISA Kubernetes Hardening Guide : publié en août 2022, il s'agit d'un document normatif qui englobe de nombreuses zones liées à la sécurité Kubernetes.
NIST Application Container Security Guide : publié en 2017.
NIST Kubernetes STIG Checklist : publié en avril 2021, ce document fournit une liste normative des exigences techniques de sécurisation d'une plate-forme Kubernetes de base.
CIS Kubernetes Benchmark : largement utilisé comme guide sur la configuration sécurisée, dernière mise à jour en juin 2021.
Container Platform Security Requirements Guide : le Département de la Défense des États-Unis a publié ce guide pour sécuriser une plate-forme Kubernetes de base en décembre 2020.
Pilier Sécurité - Cadre AWS Well Architected : document de haut niveau qui décrit la conception d'architectures cloud en tenant compte de la sécurité d'AWS.
Azure well-architected- Security Pillar : document de haut niveau qui décrit la conception d'architectures cloud en tenant compte de la sécurité d'Azure.
Framework d'architecture Google Cloud : sécurité, confidentialité et conformité : document de haut niveau qui décrit la conception d'architectures cloud en tenant compte de la sécurité de Google Cloud.
Sécurisation renforcée et conformité pour vSphere : présentation générale des éléments de sécurité et de conformité qui nécessitent une attention particulière pour vous aider à planifier la stratégie de sécurité et de conformité.
