Étant donné la rapidité de développement de Kubernetes, de nouvelles fonctionnalités de sécurité sont souvent introduites. Cette page vous guide dans la mise en œuvre de nos directives actuelles pour le renforcement de vos clusters GKE On-Prem.
Ce guide 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 du cluster. 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. Pour obtenir une présentation générale des sujets concernant la sécurité, consultez la section Sécurité.
Chiffrer des VM vSphere
Les nœuds de cluster GKE On-Prem s'exécutent sur les machines virtuelles (VM) de votre cluster vSphere. Suivez les consignes de sécurité VMware vSphere et les bonnes pratiques concernant le chiffrement des VM.
Mettre à niveau son infrastructure en temps opportun
Kubernetes introduit fréquemment de nouvelles fonctionnalités de sécurité et fournit des correctifs de sécurité. Pour en savoir plus sur les correctifs de sécurité, reportez-vous aux bulletins de sécurité GKE On-Prem.
Vous êtes responsable de la mise à jour de vos clusters GKE On-Prem. Pour chaque version, consultez les notes de version. Prévoyez une mise à jour vers de nouvelles versions de correctifs tous les mois et 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 machines virtuelles.
- Tenez-vous informé des derniers conseils de sécurité VMware.
- Suivez les conseils pour appliquer des correctifs aux hôtes.
Configurer OpenID Connect
Si vous souhaitez configurer l'authentification des utilisateurs pour vos clusters, utilisez OpenID Connect (OIDC).
Vous devez également utiliser les groupes OIDC lorsque vous accordez l'accès via un contrôle des accès basé sur les rôles (RBAC). Ainsi, vous n'aurez plus besoin de mettre à jour manuellement votre configuration RBAC lorsque les utilisateurs changent de rôle.
Utiliser le principe du moindre privilège pour les comptes de service Google Cloud
GKE On-Prem requiert quatre comptes de service Google Cloud :
- Un compte de service sur liste blanche 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. Vous devez configurer ces comptes de service selon le principe du moindre privilège : n'accordez que les droits nécessaires pour remplir les rôles respectifs des comptes de service.
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 des 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 leur application, en particulier en production.
Mappez les tâches que vos utilisateurs doivent effectuer 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.
Limiter les autorisations RBAC de découverte dans un cluster
Par défaut, Kubernetes démarre les clusters avec un ensemble permissif d'objets ClusterRoleBinding de découverte, qui fournissent un large accès aux informations sur les API d'un cluster, y compris celles des objets CustomResourceDefinition (CRD). Ces autorisations sont réduites dans Kubernetes 1.14, qui sera disponible à partir de la version 1.2 de GKE On-Prem. S'il est nécessaire de restreindre l'accès, envisagez de configurer votre pare-feu sur site de manière appropriée.
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, vous devez le configurer avant de créer 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. Pour chiffrer ces secrets au niveau de la couche d'application, vous pouvez modifier EncryptionConfig et utiliser un plug-in de service de gestion des clés.
- 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.
Limiter l'accès réseau au plan de contrôle et aux nœuds
Vous devez limiter l'exposition du plan de contrôle et des nœuds des clusters à Internet. 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. Vous ne devez pas modifier ce paramètre. Vous devez mettre en œuvre des règles de pare-feu sur votre réseau sur site pour limiter l'accès au plan de contrôle.
Utiliser des règles de réseau pour restreindre le trafic entre les pods
Par défaut, tous les services d'un cluster GKE On-Prem peuvent communiquer entre eux. Vous devez contrôler la communication de service à service en fonction de vos charges de travail.
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, qu'ils soient accidentels ou intentionnels. Voici 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 exposé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.
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é. Vous devez activer les contrôleurs d'admission pour utiliser les fonctionnalités de sécurité avancées de Kubernetes. 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 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.
Surveiller la configuration du cluster
Vous devez vérifier les configurations de votre cluster pour repérer d'éventuels écarts par rapport aux paramètres que vous avez définis. Pour vérifier automatiquement ces configurations, vous devez utiliser une solution compatible avec vos clusters GKE On-Prem, où qu'ils soient déployés. Consultez la page des partenaires Anthos.
Conserver les anciennes méthodes d'authentification client en mode inactif (par défaut)
Il existe plusieurs méthodes d'authentification auprès du serveur d'API Kubernetes. OIDC est le mécanisme d'authentification recommandé. L'authentification de base est désactivée par défaut. N'utilisez pas de certificat x509 pour l'authentification.
Laisser Cloud Logging activé (configuration par défaut)
Pour réduire la charge opérationnelle et conserver une vue consolidée de vos journaux, mettez en œuvre une stratégie de journalisation cohérente partout où vos clusters sont déployés. GKE On-Prem est intégré par défaut à la suite Google Cloud Operations. Vous devez activer la suite Google Cloud Operations lors de l'installation en insérant la spécification stackdriver dans le fichier de configuration GKE On-Prem.
La journalisation d'audit Kubernetes est activée par défaut pour tous les clusters GKE On-Prem. Les journaux d'audit conservent un enregistrement chronologique des appels passés au serveur d'API Kubernetes. Les entrées des journaux d'audit sont utiles pour analyser les requêtes API suspectes, collecter des statistiques et créer des alertes de surveillance pour les appels d'API indésirables.
Les clusters GKE On-Prem intègrent la journalisation d'audit Kubernetes aux journaux d'audit Google Cloud et à Cloud Logging. GKE On-Prem peut également acheminer des journaux depuis Logging vers votre propre système de journalisation.
La suite Google Cloud Operations collecte et regroupe les journaux de vos clusters. En activant la suite Google Cloud Operations, vous pouvez bénéficier d'une meilleure assistance de la part de Google. Pour en savoir plus, consultez la page Journalisation et surveillance.
Laisser le tableau de bord Kubernetes désactivé (par défaut)
Le tableau de bord Kubernetes s'appuie sur un compte de service Kubernetes à privilèges élevés et a été exploité dans plusieurs attaques importantes subies par Kubernetes. La console Google Cloud est l'interface Web recommandée pour GKE On-Prem. Elle dispose essentiellement des mêmes fonctionnalités, est compatible avec IAM et Kubernetes RBAC sans privilèges élevés, et propose des fonctionnalités Anthos telles que la gestion multicluster.
Le tableau de bord Kubernetes n'est pas inclus dans GKE On-Prem.
Laisser le contrôle des accès basé sur les attributs désactivé (par défaut)
Dans Kubernetes, vous utilisez RBAC pour accorder des autorisations aux ressources au niveau du cluster et de l'espace de noms. Le contrôle d'accès RBAC permet de définir des rôles avec des règles contenant un ensemble d'autorisations.
Par défaut, le contrôle des accès basé sur les attributs (ABAC) est désactivé dans les clusters GKE On-Prem, et il n'est pas conseillé de l'activer.