Étant donné la rapidité de développement de Kubernetes, de nouvelles fonctionnalités de sécurité sont souvent introduites. Ce document explique comment renforcer vos clusters Google Distributed Cloud.
Il donne la priorité aux mesures d'atténuation des risques dans les domaines où la sécurité est particulièrement importante et qui nécessitent votre intervention lors de la création de clusters. Les fonctionnalités moins critiques, les paramètres de sécurité par défaut et ceux qui peuvent être activés après la création du cluster sont mentionnés plus loin dans le document. Pour obtenir une présentation générale des sujets concernant la sécurité, consultez la section Sécurité.
Checklist
La checklist de déploiement suivante présente les bonnes pratiques pour renforcer le déploiement de la plate-forme de clusters GKE. Pour en savoir plus sur chaque pratique, consultez les différentes sections de ce document.
| Checklist de déploiement | Description |
|---|---|
| Identité et contrôle des accès | Utiliser les droits du compte vSphere : Sécuriser les comptes de service Google Cloud : Configurer OpenID Connect (OIDC) : Utiliser les espaces de noms Kubernetes et RBAC pour limiter les accès : |
| Protection des données | Chiffrer les machines virtuelles vSphere : Gérer les secrets : |
| Protection du réseau | Restreindre l'accès réseau au plan de contrôle et aux nœuds : Utiliser des règles de réseau pour limiter le trafic : |
| Sécurité déclarative | Utiliser Policy Controller: |
| Maintenance | Mettre à niveau GKE Enterprise: Surveiller les bulletins de sécurité: |
| Surveillance et journalisation | Définir les options pour la journalisation des clusters GKE : |
Identité et contrôle des accès
Cette section fournit des informations sur le contrôle des accès à vos clusters.
Utiliser les privilèges du compte vSphere
Le compte utilisateur vCenter que vous utilisez pour installer Google Distributed Cloud doit disposer de droits suffisants. Par exemple, un compte d'utilisateur auquel est attribué le rôle Administrateur de vCenter dispose de droits d'accès complets à tous les objets vCenter et fournit à un administrateur de cluster Google Distributed Cloud un accès complet.
Le principe du moindre privilège est recommandé, en accordant uniquement les privilèges nécessaires à l'installation de GKE Enterprise. Nous avons prédéfini l'ensemble minimal de privilèges nécessaire à l'installation, ainsi que les commandes nécessaires pour accorder ces autorisations.
Comptes de service Google Cloud sécurisés
Google Distributed Cloud nécessite trois comptes de service Google Cloud :
- Un compte de service prédéfini pour accéder au logiciel Google Distributed Cloud. Vous le créez lorsque vous achetez GKE Enterprise.
- Un compte de service d'enregistrement qui sera utilisé par Connect pour enregistrer des clusters Google Distributed Cloud avec Google Cloud.
- Un compte de service Cloud Logging pour collecter les journaux de cluster et qui sera utilisé par Cloud Logging
Lors de l'installation, vous associez des rôles IAM (Identity and Access Management) à ces comptes de service. Ces rôles accordent des droits spécifiques aux comptes de service au sein de votre projet et peuvent être générés pour vous au cours de l'installation.
Configurer l'authentification pour les utilisateurs de cluster
Pour configurer l'authentification des utilisateurs pour votre cluster, vous pouvez utiliser OpenID Connect (OIDC) ou le protocole LDAP (Lightweight Directory Access Protocol).
Pour en savoir plus, consultez Service d'identité GKE.
Utiliser les espaces de noms Kubernetes et RBAC pour restreindre l'accès
Pour accorder aux équipes un accès à Kubernetes suivant le principe du moindre privilège, créez des espaces de noms Kubernetes ou des clusters spécifiques à l'environnement. Affectez des centres de coûts et les libellés appropriés à chaque espace de noms pour renforcer la responsabilisation et permettre le rejet de débit. N'accordez aux développeurs que le niveau d'accès aux espaces de noms dont ils ont besoin pour déployer et gérer leurs applications, en particulier en production.
Mappez les tâches que vos utilisateurs doivent terminer sur le cluster et définissez les autorisations requises pour effectuer chaque tâche. Pour accorder des autorisations au niveau du cluster et de l'espace de noms, utilisez Kubernetes RBAC.
Au-delà des autorisations accordées aux comptes de service Google Cloud pour installer Google Distributed Cloud, IAM ne s'applique pas aux clusters Google Distributed Cloud.
Pour en savoir plus, consultez la documentation suivante :
Protection des données
Cette section fournit des informations sur la protection de vos données.
Chiffrer des machines virtuelles vSphere
Les nœuds de cluster Google Distributed Cloud s'exécutent sur des machines virtuelles (VM) dans votre cluster vSphere. Nous vous recommandons vivement de chiffrer toutes les données au repos. Pour le faire dans vSphere, suivez les instructions du guide de configuration et de renforcement de la sécurité VMware vSphere 7 et des bonnes pratiques de chiffrement des VM.
Cette opération doit être effectuée avant l'installation de GKE Enterprise.
Gérer les secrets
Pour fournir un niveau de protection supplémentaire aux données sensibles, telles que les secrets Kubernetes stockés dans etcd, configurez un gestionnaire de secrets intégré aux clusters Google Distributed Cloud.
Si vous exécutez des charges de travail dans plusieurs environnements, il peut être préférable d'utiliser une solution qui fonctionne à la fois pour Google Kubernetes Engine et Google Distributed Cloud. Si vous choisissez d'utiliser un gestionnaire de secrets externe, tel que HashiCorp Vault, configurez-le avant d'intégrer vos clusters Google Distributed Cloud.
Vous disposez de plusieurs options pour la gestion des secrets :
- Vous pouvez utiliser les secrets Kubernetes en mode natif dans Google Distributed Cloud. Les clusters doivent utiliser le chiffrement vSphere pour les VM comme décrit précédemment, qui fournit une protection de base pour le chiffrement au repos des secrets. Les secrets ne sont pas davantage chiffrés par défaut.
- Vous pouvez utiliser un gestionnaire de secrets externes, tel que HashiCorp Vault. Vous pouvez vous authentifier auprès de HashiCorp à l'aide d'un compte de service Kubernetes ou d'un compte de service Google Cloud.
Pour en savoir plus, consultez la documentation suivante :
Protection du réseau
Cette section fournit des informations sur la protection de votre réseau.
Limiter l'accès réseau au plan de contrôle et aux nœuds
Limitez l'exposition à Internet du plan de contrôle et des nœuds du cluster. Ces choix ne peuvent pas être modifiés après la création du cluster. Par défaut, les nœuds de cluster Google Distributed Cloud sont créés à l'aide d'adresses RFC 1918. Il est recommandé de ne pas modifier ce paramètre. Mettez en œuvre des règles de pare-feu dans votre réseau sur site afin de restreindre l'accès au plan de contrôle.
Utiliser des règles de réseau pour limiter le trafic
Par défaut, tous les services d'un cluster Google Distributed Cloud peuvent communiquer entre eux. Pour en savoir plus sur le contrôle de la communication de service à service selon vos charges de travail, consultez les sections suivantes.
Lorsque vous limitez l'accès réseau des services, il est beaucoup plus difficile pour les pirates informatiques de se déplacer latéralement au sein du cluster. Cela présente également l'avantage de doter les services d'une protection contre les dénis de service accidentels ou provoqués délibérément. Il existe deux méthodes recommandées pour contrôler le trafic :
- Pour contrôler le trafic L7 vers les points de terminaison de vos applications, utilisez Istio. Choisissez cette option si vous êtes intéressé par l'équilibrage de charge, l'autorisation de service, la limitation, les quotas et les métriques.
- Pour contrôler le trafic L4 entre les pods, utilisez des règles de réseau Kubernetes. Choisissez cette option si vous recherchez les fonctionnalités de contrôle d'accès de base gérées par Kubernetes.
Une fois que vous avez créé vos clusters Google Distributed Cloud, vous pouvez activer les règles de réseau Istio et Kubernetes. Vous pouvez les utiliser ensemble en cas de besoin.
Pour en savoir plus, consultez la documentation suivante :
Sécurité déclarative
Cette section fournit des recommandations pour sécuriser vos clusters.
Utiliser Policy Controller
Les contrôleurs d'admission Kubernetes sont des plug-ins qui régissent et appliquent la façon dont un cluster Kubernetes est utilisé. Les contrôleurs d'admission jouent un rôle important pour un renforcement de votre cluster axé sur la défense.
Il est recommandé d'utiliser Policy Controller. Policy Controller utilise le service OPA Contraint Framework pour décrire et appliquer des stratégies en tant que CRD. Les contraintes que vous souhaitez appliquer à votre cluster sont définies dans des modèles de contraintes déployés dans vos clusters.
Pour savoir comment utiliser les contraintes du service Policy Controller afin d'obtenir un grand nombre des protections de la propriété PodSecurityPolicies, avec la possibilité supplémentaire de tester vos stratégies avant de les appliquer, consultez la page Utiliser des contraintes pour appliquer les règles de sécurité des pods.
Pour en savoir plus, consultez la documentation suivante :
Restreindre les capacités d'automodification des charges de travail
Certaines charges de travail Kubernetes, en particulier les charges de travail système, sont autorisées à s'automodifier. Par exemple, certaines charges de travail effectuent des autoscaling verticaux sur elle-mêmes. Bien que cette capacité soit pratique, elle peut permettre à un pirate informatique ayant déjà compromis un nœud de passer au niveau supérieur dans le cluster. Par exemple, un pirate informatique peut faire en sorte qu'une charge de travail sur le nœud se modifie pour s'exécuter en tant que compte de service plus privilégié qui existe dans le même espace de noms.
Idéalement, les charges de travail ne doivent pas être autorisées à se modifier elles-mêmes. Lorsque l'automodification est nécessaire, vous pouvez limiter les autorisations en appliquant des contraintes Gatekeeper ou Policy Controller, telles que NoUpdateServiceAccount de la bibliothèque Open Source Gatekeeper, qui offre plusieurs règles de sécurité utiles.
Lorsque vous déployez des règles, il est généralement nécessaire de permettre aux contrôleurs qui gèrent le cycle de vie du cluster de les contourner, ainsi que les pipelines de journalisation et de surveillance. Cela est nécessaire pour que les contrôleurs puissent apporter des modifications au cluster, telles que l'application de mises à niveau de cluster. Par exemple, si vous déployez la règle NoUpdateServiceAccount sur Google Distributed Cloud, vous devez définir les paramètres suivants dans Constraint :
parameters:
allowedGroups:
- system:masters
allowedUsers:
- system:serviceaccount:kube-system:monitoring-operator
- system:serviceaccount:kube-system:stackdriver-operator
- system:serviceaccount:kube-system:metrics-server-operator
- system:serviceaccount:kube-system:logmon-operator
Maintenance
Cette section fournit des informations sur la maintenance de vos clusters.
Mettre à niveau GKE Enterprise
Kubernetes introduit régulièrement de nouvelles fonctionnalités de sécurité et fournit des correctifs de sécurité.
Vous êtes responsable du maintien à jour de vos clusters Google Distributed Cloud. Pour chaque version, consultez les notes de version. En outre, prévoyez de passer à de nouvelles versions de correctif tous les mois et de versions mineures tous les trois mois. Découvrez comment mettre à jour vos clusters.
Vous êtes également responsable de la mise à niveau et de la sécurisation de l'infrastructure vSphere :
- Établissez un processus pour appliquer les correctifs et les mises à jour en temps opportun pour vos VM.
- Tenez-vous informé des derniers conseils de sécurité VMware.
- Suivez les conseils concernant l'application de correctifs aux hôtes.
Surveiller les bulletins de sécurité
L'équipe de sécurité GKE Enterprise publie des bulletins de sécurité pour les failles de gravité élevée et critique.
Ces bulletins suivent un schéma commun de numérotation des failles Google Cloud, et sont accessibles à partir de la page principale des bulletins Google Cloud et des notes de version de Google Distributed Cloud. Chaque page de bulletins de sécurité comporte un flux RSS sur lequel les utilisateurs peuvent s'abonner aux mises à jour.
Lorsque la réaction du client est requise pour remédier à ces failles critiques, Google contacte les clients par e-mail. Google peut également contacter les clients par le biais de contrats d'assistance via des canaux d'assistance.
Pour en savoir plus, consultez la documentation suivante :
Surveillance et journalisation
Google Distributed Cloud inclut plusieurs options de journalisation et de surveillance des clusters, y compris des services gérés basés dans le cloud et des outils Open Source, mais aussi une compatibilité validée avec des solutions commerciales tierces.
- Cloud Logging et Cloud Monitoring, activés par les agents déployés avec Google Distributed Cloud
- Configurations validées avec des solutions tierces
Quelle que soit la solution de journalisation que vous choisissez en fonction des exigences de l'entreprise, nous vous recommandons vivement de journaliser les événements et alertes pertinents vers un service de gestion des informations et des événements liés à la sécurité (SIEM) centralisé conçu pour la gestion des incidents de sécurité.
Pour en savoir plus, consultez la documentation suivante :
- Journalisation et surveillance
- Utiliser la journalisation et la surveillance
- Journalisation et surveillance des applications
- Surveiller Google Distributed Cloud avec Elastic Stack
- Collecter des journaux sur GKE Enterprise avec Splunk Connect