É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 GKE On-Prem.
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 Anthos. 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 le contrôleur de stratégie Anthos Config Management : |
| Maintenance | Mettre à niveau Anthos : Surveiller les bulletins de sécurité : |
| Surveillance et journalisation | Définir les options pour la journalisation des clusters Anthos : |
Identité et contrôle des accès
Utiliser les privilèges du compte vSphere
Le compte d'utilisateur vCenter que vous utilisez pour installer GKE On-Prem 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 GKE On-Prem un accès complet.
Le principe du moindre privilège est recommandé, en accordant uniquement les privilèges nécessaires à l'installation d'Anthos. 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
GKE On-Prem requiert quatre comptes de service Google Cloud :
- Un compte de service prédéfini pour accéder au logiciel GKE On-Prem. Vous le créez lorsque vous achetez Anthos.
- Un compte de service d'enregistrement qui sera utilisé par Connect pour enregistrer des clusters GKE On-Prem avec Google Cloud.
- Un compte de service de connexion qui sera utilisé par Connect pour établir une connexion entre les clusters GKE On-Prem et 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 OpenID Connect
Vous ne pouvez configurer l'authentification qu'au moment de la création du cluster. Pour configurer l'authentification des utilisateurs pour vos clusters, utilisez OpenID Connect (OIDC).
GKE On-Prem est compatible avec OIDC en tant que mécanisme d'authentification pour interagir avec le serveur d'API Kubernetes d'un cluster d'utilisateur. OIDC vous permet de gérer l'accès aux clusters Kubernetes en utilisant les procédures standards de votre organisation pour créer, activer et désactiver des comptes utilisateur.
Pour la compatibilité spécifique d'OIDC, consultez la documentation suivante :
- S'authentifier avec OIDC
- Procéder à l'authentification à l'aide d'OIDC et d'AD FS
- Procéder à l'authentification à l'aide d'OIDC et de Google
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 GKE On-Prem, IAM ne s'applique pas aux clusters GKE On-Prem.
Pour en savoir plus, consultez la documentation suivante :
- Comptes de service et clés
- Consultez la page Présentation des sujets avancés concernant l'installation.
- Droits de compte d'utilisateur vCenter
Protection des données
Chiffrer des machines virtuelles vSphere
Les nœuds de cluster GKE On-Prem 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 ce faire, dans vSphere, suivez les instructions du fichier PDF de sécurité VMware vSphere et les bonnes pratiques de chiffrement des VM.
Cette opération doit être effectuée avant l'installation d'Anthos.
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 GKE On-Prem.
Si vous exécutez des charges de travail dans plusieurs environnements, une solution qui fonctionne à la fois pour Google Kubernetes Engine et GKE On-Prem peut être préférable. Si vous choisissez d'utiliser un gestionnaire de secrets externe, tel que HashiCorp Vault, configurez-le avant d'intégrer vos clusters GKE On-Prem.
Vous disposez de plusieurs options pour la gestion des secrets :
- Vous pouvez utiliser les secrets Kubernetes en natif dans GKE On-Prem. 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
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 GKE On-prem 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 GKE On-Prem 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 statistiques.
- Pour contrôler le trafic L4 entre les pods, utilisez des règles de réseau Kubernetes. Choisissez cette option si vous recherchez une fonctionnalité de contrôle d'accès de base gérée par Kubernetes.
Une fois que vous avez créé vos clusters GKE On-Prem, 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
Utiliser le contrôleur de stratégie Anthos Config Management
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 le contrôleur de stratégie d'Anthos Config Management. 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 :
Maintenance
Mettre à niveau Anthos
Kubernetes introduit régulièrement de nouvelles fonctionnalités de sécurité et fournit des correctifs de sécurité.
Vous êtes responsable de la mise à jour de vos clusters GKE On-Prem. 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 instructions sur l'application des correctifs aux hôtes.
Surveiller les bulletins de sécurité
L'équipe de sécurité Anthos 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 GKE On-Prem. 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
Définir les options de journalisation des clusters Anthos
Anthos GKE On-Prem 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 de cluster déployés avec GKE On-Prem
- Prometheus et Grafana, désactivés par défaut
- 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 Anthos clusters on VMware avec Elastic Stack
- Collecter des journaux sur Anthos avec Splunk Connect