Renforcer la sécurité d'un cluster

É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 conseils actuels sur le renforcement de votre cluster Google Kubernetes Engine (GKE).

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 l'intervention du client 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 d'un cluster sont mentionnés plus loin dans le document. Pour obtenir des informations générales sur les sujets relatifs à la sécurité, consultez la page Présentation des fonctionnalités de sécurité.

La plupart des recommandations de cette page, ainsi que d'autres erreurs de configuration courantes, peuvent être vérifiées automatiquement à l'aide de l'analyse de l'état de la sécurité.

Lorsque les recommandations ci-dessous concernent une recommandation de benchmark CIS GKE, celle-ci est spécifiée.

Mettre à niveau son infrastructure GKE en temps opportun

Recommandation de benchmark CIS GKE : 6.5.3. Assurez-vous que la mise à niveau automatique des nœuds est activée pour les nœuds GKE

Maintenir à jour la version de Kubernetes est l'une des choses les plus simples que vous puissiez faire pour améliorer la sécurité de votre cluster. Kubernetes introduit fréquemment de nouvelles fonctionnalités de sécurité et fournit des correctifs de sécurité.

Consultez les bulletins de sécurité GKE pour plus d'informations sur les correctifs de sécurité.

Dans Google Kubernetes Engine, les plans de contrôle sont corrigés et mis à niveau automatiquement. La mise à niveau automatique des nœuds met également à niveau automatiquement les nœuds de votre cluster.

Si vous décidez de désactiver la mise à niveau automatique des nœuds, nous vous recommandons de procéder à une mise à niveau mensuelle selon votre propre calendrier. Pour les clusters les plus anciens, vous devez activer la mise à niveau automatique des nœuds et suivre de près les bulletins de sécurité GKE pour les correctifs critiques.

Pour en savoir plus, consultez la page Mettre à niveau automatiquement des nœuds.

Limiter l'accès réseau au plan de contrôle et aux nœuds

Recommandations de benchmark CIS GKE : 6.6.2. Préférez les clusters VPC natifs (6.6.3). Assurez-vous que les réseaux autorisés maîtres sont activés, (6.6.4). Assurez-vous que les clusters sont créés avec le point de terminaison privé activé et l'accès public désactivé, et en version 6.6.5. Assurez-vous que les clusters sont créés avec des nœuds privés

Vous devez limiter l'exposition du plan de contrôle et des nœuds des clusters à Internet. Ces paramètres ne peuvent être définis qu'au moment de la création du cluster.

Par défaut, le plan de contrôle et les nœuds des clusters GKE disposent d'adresses Internet routables auxquelles il est possible d'accéder depuis n'importe quelle adresse IP.

Pour le plan de contrôle des clusters GKE, consultez la page Configurer un cluster privé. Il existe trois types de clusters privés pouvant fournir une protection au niveau du réseau :

  • Accès public aux points de terminaison désactivé : cette option est la plus sécurisée, car elle empêche tout accès Internet à la fois aux plans de contrôle et aux nœuds. C'est un bon choix si vous avez configuré votre réseau sur site pour une connexion à Google Cloud via Cloud Interconnect et Cloud VPN. Ces technologies relient efficacement le réseau de votre entreprise à votre VPC.
  • Accès public aux points de terminaison activé, réseaux autorisés activés (recommandé) : cette option permet un accès restreint au plan de contrôle à partir des adresses IP sources que vous définissez. Cette option est idéale si vous ne disposez pas d'une infrastructure VPN existante, ou si vous avez des utilisateurs distants ou des filiales qui se connectent via l'Internet public plutôt qu'avec le VPN d'entreprise et Cloud Interconnect ou Cloud VPN.
  • Accès public aux points de terminaison activé, réseaux autorisés désactivés : cette option est activée par défaut et permet à tous les internautes de se connecter au plan de contrôle.

Pour désactiver l'accès Internet direct aux nœuds, spécifiez l'option "--enable-private-nodes" dans gcloud CLI au moment de la création du cluster.

Cela indique à GKE de provisionner des nœuds avec des adresses IP internes, ce qui signifie que les nœuds ne sont pas directement accessibles via l'Internet public.

Nous recommandons que les clusters utilisent au moins des réseaux autorisés et des nœuds privés. Ainsi, le plan de contrôle est accessible par :

  • les CIDR autorisés au sein des réseaux autorisés ;
  • les nœuds au sein du VPC de votre cluster ;
  • les tâches de production internes de Google qui gèrent votre plan de contrôle.

Cela correspond aux options gcloud suivantes lors de la création du cluster :

  • --enable-ip-alias
  • --enable-private-nodes
  • --enable-master-authorized-networks

Utiliser les règles de pare-feu selon le principe du moindre privilège

Minimiser le risque d'accès inattendu en utilisant le principe du moindre privilège pour les règles de pare-feu

GKE crée des règles de pare-feu VPC par défaut pour activer les fonctionnalités du système et appliquer les bonnes pratiques de sécurité. Pour obtenir la liste complète des règles de pare-feu créées automatiquement, consultez la section Règles de pare-feu créées automatiquement.

GKE crée ces règles de pare-feu par défaut avec une priorité de 1 000. Si vous créez des règles de pare-feu permissives avec une priorité plus élevée, par exemple une règle de pare-feu allow-all pour le débogage, votre cluster présente un risque d'accès inattendu.

Authentification de groupe

Recommandation de benchmark CIS GKE : 6.8.3. Envisagez de gérer les utilisateurs de Kubernetes RBAC à l'aide de Google Groupes pour RBAC

Vous devez utiliser des groupes pour gérer vos utilisateurs. L'utilisation de groupes permet de contrôler les identités à l'aide de votre système de gestion des identités et de vos administrateurs d'identité. Si vous ajustez l'appartenance au groupe, vous n'avez pas besoin de mettre à jour votre configuration RBAC chaque fois qu'un utilisateur est ajouté ou supprimé du groupe.

Pour gérer les autorisations des utilisateurs à l'aide des groupes Google, vous devez activer la fonction Google Groupes pour RBAC sur votre cluster. Cela vous permet de gérer facilement les utilisateurs disposant des mêmes autorisations, tout en permettant à vos administrateurs d'identité de gérer les utilisateurs de manière centralisée et cohérente.

Pour savoir comment activer Google Groupes pour RBAC, consultez la page Google Groupes pour RBAC.

Choix du nœud du conteneur

Les sections suivantes décrivent les choix de configuration sécurisée des nœuds.

Activer les nœuds GKE protégés

Recommandation de benchmark CIS GKE : 6.5.5. Assurez-vous que les nœuds GKE protégés sont activés

Les nœuds GKE protégés offrent une identité et une intégrité de nœud solides et vérifiables pour renforcer la sécurité des nœuds GKE. Ils doivent être activés sur tous les clusters GKE.

Vous pouvez activer les nœuds GKE protégés lors de la création ou de la mise à jour du cluster. Les nœuds GKE protégés doivent être activés avec le démarrage sécurisé. Le démarrage sécurisé ne doit pas être utilisé si vous avez besoin de modules de noyau non signés tiers. Pour savoir comment activer les nœuds GKE protégés et comment activer le démarrage sécurisé à l'aide des nœuds GKE protégés, consultez la section Utiliser des nœuds GKE protégés.

Choisir une image de nœud renforcée avec l'environnement d'exécution containerd

L'image Container-Optimized OS avec containerd (cos_containerd) est une variante de l'image Container-Optimized OS où containerd est l'environnement d'exécution principal des conteneurs et est directement intégré à Kubernetes.

Containerd est le composant d'exécution principal de Docker et a été conçu pour fournir la fonctionnalité principale du conteneur pour la spécification Container Runtime Interface (CRI, Interface de l'environnement d'exécution de conteneurs) Kubernetes. Il est nettement moins complexe que le daemon Docker complet et présente donc une surface d'attaque plus petite.

Pour utiliser l'image cos_containerd dans votre cluster, consultez la page Images Containerd.

L'image cos_containerd est l'image à privilégier pour GKE, car elle a été personnalisée, optimisée et renforcée spécialement pour l'exécution de conteneurs.

Activer la fédération d'identité de charge de travail pour GKE

Recommandation de benchmark CIS GKE : 6.2.2. Préférez l'utilisation de comptes de service Google Cloud dédiés et la fonctionnalité Workload Identity

La fédération d'identité de charge de travail pour GKE est la méthode recommandée pour s'authentifier auprès des API Google Cloud.

La fédération d'identité de charge de travail pour GKE se substitue à la nécessité d'utiliser la dissimulation de métadonnées et les deux approches sont incompatibles. Les métadonnées sensibles protégées par la dissimulation de métadonnées sont également protégées par la fédération d'identité de charge de travail pour GKE.

Renforcer l'isolation d'une charge de travail avec GKE Sandbox

Recommandation de benchmark CIS GKE : 6.10.4. Envisagez d'utiliser GKE Sandbox pour renforcer l'isolation des charges de travail, en particulier pour les charges de travail non approuvées.

GKE Sandbox offre un niveau de sécurité supplémentaire pour empêcher un code malveillant d'affecter le noyau hôte sur vos nœuds de cluster.

Vous pouvez exécuter des conteneurs dans un environnement de bac à sable pour limiter la plupart des attaques de fuite de conteneur, également appelées attaques par élévation des privilèges locaux. Pour connaître les failles de fuite des conteneurs, consultez les bulletins de sécurité. Ce type d'attaque permet à un pirate informatique d'accéder à la VM hôte du conteneur et, par conséquent, à d'autres conteneurs sur la même VM. Un bac à sable tel que GKE Sandbox peut vous aider à limiter l'impact de ces attaques.

Envisagez d'utiliser une charge de travail en bac à sable dans les situations suivantes :

  • La charge de travail exécute du code non approuvé
  • Vous souhaitez limiter l'impact si un pirate informatique compromet un conteneur dans la charge de travail.

Découvrez comment utiliser GKE Sandbox dans l'article Renforcer l'isolation d'une charge de travail avec GKE Sandbox.

Activer les notifications concernant les bulletins de sécurité

Lorsque des bulletins de sécurité sont disponibles et concernent votre cluster, GKE publie des notifications sur ces événements sous forme de messages dans les sujets Pub/Sub que vous configurez. Vous pouvez recevoir ces notifications sur un abonnement Pub/Sub, les intégrer à des services tiers et filtrer les types de notifications que vous souhaitez recevoir.

Pour en savoir plus sur la réception des bulletins de sécurité à l'aide des notifications de cluster GKE, consultez la page Notifications de cluster.

Autorisations

Utiliser le principe du moindre privilège pour les comptes de service IAM

Recommandation de benchmark CIS GKE : 6.2.1. Évitez d'exécuter les clusters GKE à l'aide du compte de service Compute Engine par défaut.

Chaque nœud GKE est assorti d'un compte de service Identity and Access Management (IAM). Par défaut, les nœuds se voient affecter le compte de service par défaut de Compute Engine, que vous trouverez dans la section "IAM" de la console Google Cloud. Ce compte dispose d'un accès étendu par défaut, ce qui le rend utile pour une grande variété d'applications. Cependant, il dispose de plus d'autorisations que nécessaire pour exécuter votre cluster Kubernetes Engine. Vous devez créer et utiliser un compte de service associé à des privilèges minimaux pour vos nœuds, plutôt que le compte de service par défaut de Compute Engine.

Avec le lancement de la fédération d'identité de charge de travail pour GKE, nous suggérons une utilisation plus limitée du compte de service de nœud. Nous pensons que le compte de service de nœud sera utilisé par les daemons système chargés de la journalisation, de la surveillance et d'autres tâches similaires. À la place, les charges de travail hébergées dans les pods doivent être des identités provisionnées avec la fédération d'identité de charge de travail pour GKE.

GKE exige, au minimum, que le compte de service dispose des rôles monitoring.viewer, monitoring.metricWriter, logging.logWriter, stackdriver.resourceMetadata.writer et autoscaling.metricsWriter. Pour en savoir plus, consultez les informations sur les rôles Monitoring et Logging.

Les commandes suivantes permettent de créer un compte de service IAM avec les autorisations minimales requises pour exécuter GKE. Vous pouvez également utiliser le compte de service pour les ressources d'autres projets. Pour obtenir les instructions nécessaires, consultez la page Activer l'emprunt d'identité des comptes de service entre les projets.

gcloud

gcloud iam service-accounts create SA_NAME \
    --display-name=DISPLAY_NAME

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
    --role roles/logging.logWriter

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
    --role roles/monitoring.metricWriter

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
    --role roles/monitoring.viewer

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
    --role roles/stackdriver.resourceMetadata.writer

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
    --role roles/autoscaling.metricsWriter

Remplacez les éléments suivants :

  • SA_NAME : nom du nouveau compte de service.
  • DISPLAY_NAME : nom à afficher du nouveau compte de service, ce qui facilite l'identification du compte.
  • PROJECT_ID : ID du projet dans lequel vous souhaitez créer le compte de service.

Config Connector

Remarque : Cette étape nécessite Config Connector. Suivez les instructions d'installation pour l'installer sur votre cluster.

  1. Pour créer le compte de service, téléchargez la ressource suivante en tant que service-account.yaml. 

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMServiceAccount
metadata:
  name: [SA_NAME]
spec:
  displayName: [DISPLAY_NAME]

    Remplacez les éléments suivants :

    • SA_NAME : nom du nouveau compte de service.
    • DISPLAY_NAME : nom à afficher du nouveau compte de service, ce qui facilite l'identification du compte.

    Exécutez ensuite la commande ci-dessous : 

    kubectl apply -f service-account.yaml

  2. Appliquez le rôle logging.logWriter au compte de service. Téléchargez la ressource suivante en tant que policy-logging.yaml. Remplacez [SA_NAME] et [PROJECT_ID] par vos propres informations. 

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-logging
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/logging.logWriter
  resourceRef:
    kind: Project
    name: [PROJECT_ID]
    kubectl apply -f policy-logging.yaml

  3. Appliquez le rôle monitoring.metricWriter. Téléchargez la ressource suivante en tant que policy-metrics-writer.yaml. Remplacez [SA_NAME] et [PROJECT_ID] par vos propres informations. 

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-metrics-writer
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/monitoring.metricWriter
  resourceRef:
    kind: Project
    name: [PROJECT_ID]
    kubectl apply -f policy-metrics-writer.yaml

  4. Appliquez le rôle monitoring.viewer. Téléchargez la ressource suivante en tant que policy-monitoring.yaml. Remplacez [SA_NAME] et [PROJECT_ID] par vos propres informations. 

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-monitoring
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/monitoring.viewer
  resourceRef:
    kind: Project
    name: [PROJECT_ID]
    kubectl apply -f policy-monitoring.yaml

  5. Appliquez le rôle autoscaling.metricsWriter. Téléchargez la ressource suivante en tant que policy-autoscaling-metrics-writer.yaml. Remplacez [SA_NAME] et [PROJECT_ID] par vos propres informations. 

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-autoscaling-metrics-writer
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/autoscaling.metricsWriter
  resourceRef:
    kind: Project
    name: [PROJECT_ID]
    kubectl apply -f policy-autoscaling-metrics-writer.yaml

Accorder l'accès aux dépôts d'images privées

Pour utiliser des images privées dans Artifact Registry, accordez le rôle Lecteur Artifact Registry (roles/artifactregistry.reader) au compte de service.

gcloud

gcloud artifacts repositories add-iam-policy-binding REPOSITORY_NAME \
    --member=serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/artifactregistry.reader

Remplacez REPOSITORY_NAME par le nom de votre dépôt Artifact Registry.

Config Connector

Remarque : Cette étape nécessite Config Connector. Suivez les instructions d'installation pour l'installer sur votre cluster.

  1. Enregistrez le manifeste suivant sous le nom policy-artifact-registry-reader.yaml :

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-artifact-registry-reader
spec:
  member: serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com
  role: roles/artifactregistry.reader
  resourceRef:
    apiVersion: artifactregistry.cnrm.cloud.google.com/v1beta1
    kind: ArtifactRegistryRepository
    name: REPOSITORY_NAME

    Remplacez les éléments suivants :

    • SA_NAME : nom de votre compte de service IAM.
    • PROJECT_ID : ID de votre projet Google Cloud.
    • REPOSITORY_NAME : nom de votre dépôt Artifact Registry

  2. Attribuez le rôle de lecteur Artifact Registry au compte de service :

    kubectl apply -f policy-artifact-registry-reader.yaml

Si vous utilisez des images privées dans Google Container Registry, vous devez également autoriser l'accès à ces éléments :

gsutil

gsutil iam ch \
  serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com:objectViewer \
  gs://BUCKET_NAME

Le bucket qui stocke vos images porte le nom BUCKET_NAME au format suivant :

  • artifacts.PROJECT_ID.appspot.com pour les images stockées dans un registre de l'hôte gcr.io, ou
  • STORAGE_REGION.artifacts.PROJECT_ID.appspot.com

Remplacez les éléments suivants :

  • PROJECT_ID : l'ID de votre projet Google Cloud Console.
  • STORAGE_REGION : l'emplacement du bucket de stockage :
    • us pour les registres de l'hôte us.gcr.io
    • eu pour les registres de l'hôte eu.gcr.io
    • asia pour les registres de l'hôte asia.gcr.io

Pour en savoir plus sur la commande, consultez la documentation sur gsutil iam.

Config Connector

Remarque : Cette étape nécessite Config Connector. Suivez les instructions d'installation pour l'installer sur votre cluster.

Appliquez le rôle storage.objectViewer à votre compte de service. Téléchargez la ressource suivante en tant que policy-object-viewer.yaml. Remplacez [SA_NAME] et [PROJECT_ID] par vos propres informations. 

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-object-viewer
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/storage.objectViewer
  resourceRef:
    kind: Project
    name: [PROJECT_ID]
kubectl apply -f policy-object-viewer.yaml

Si vous souhaitez qu'un autre utilisateur puisse créer des clusters ou des pools de nœuds avec ce compte de service, vous devez lui accorder le rôle d'utilisateur du compte de service sur ce compte de service :

gcloud

gcloud iam service-accounts add-iam-policy-binding \
    SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --member=user:USER \
    --role=roles/iam.serviceAccountUser

Config Connector

Remarque : Cette étape nécessite Config Connector. Suivez les instructions d'installation pour l'installer sur votre cluster.

Appliquez le rôle iam.serviceAccountUser à votre compte de service. Téléchargez la ressource suivante en tant que policy-service-account-user.yaml. Remplacez [SA_NAME] et [PROJECT_ID] par vos propres informations. 

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-service-account-user
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/iam.serviceAccountUser
  resourceRef:
    kind: Project
    name: [PROJECT_ID]
kubectl apply -f policy-service-account-user.yaml

Pour les clusters standards existants, vous pouvez désormais créer un pool de nœuds avec ce nouveau compte de service. Pour les clusters Autopilot, vous devez créer un nouveau cluster avec le compte de service. Pour obtenir des instructions, consultez la section Créer un cluster Autopilot.

  • Créez un pool de nœuds utilisant le nouveau compte de service :

    gcloud container node-pools create NODE_POOL_NAME \
--service-account=SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
--cluster=CLUSTER_NAME

Si vous souhaitez que votre cluster GKE ait accès à d'autres services Google Cloud, vous devez utiliser la fédération d'identité de charge de travail pour GKE.

Restreindre l'accès à la détection des API d'un cluster

Par défaut, Kubernetes amorce les clusters avec un ensemble de ClusterRoleBindings de découverte qui donnent un large accès aux informations sur les API d'un cluster, y compris celles des CustomResourceDefinitions.

Les utilisateurs doivent savoir que le groupe system:authenticated inclus dans les sujets des ClusterRoleBindings system:discovery et system:basic-user peut inclure tout utilisateur authentifié, y compris tout utilisateur disposant d'un compte Google, et ne représente pas un niveau de sécurité significatif pour les clusters sur GKE. Pour en savoir plus, consultez la section Éviter les rôles et les groupes par défaut.

Les personnes souhaitant renforcer la sécurité des API de découverte de leur cluster doivent envisager de procéder à l'une ou plusieurs des opérations suivantes :

Si aucune de ces options ne convient à votre cas d'utilisation GKE, vous devez traiter toutes les informations de découverte d'API (à savoir le schéma des CustomResources, les définitions de services d'API et les informations de détection hébergées par des serveurs d'API d'extension) comme étant divulguées publiquement.

Ces deux options permettent d'accéder à l'adresse IP du serveur d'API depuis Cloud Run et Cloud Functions. Cet accès est en cours de suppression. Vous ne devez donc pas compter sur ces services pour communiquer avec votre serveur d'API. Pour en savoir plus, consultez l'article de blog Google Cloud.

Utiliser les espaces de noms et les autorisations RBAC pour limiter l'accès aux ressources du cluster

Recommandation de benchmark CIS GKE : 5.6.1. Créez des limites administratives entre les ressources à l'aide d'espaces de noms

Lorsque vous définissez les accès de vos équipes à Kubernetes, appliquez le principe du moindre privilège en créant des espaces de noms ou des clusters distincts pour chaque équipe et chaque 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 à l'espace de noms dont ils ont besoin pour déployer et gérer leur application, en particulier en production. Planifiez les tâches que vos utilisateurs doivent effectuer sur le cluster et définissez les autorisations dont ils ont besoin pour chaque tâche.

Pour en savoir plus sur la création d'espaces de noms, consultez la documentation Kubernetes. Pour connaître les bonnes pratiques à appliquer lorsque vous planifiez votre configuration RBAC, consultez la page Bonnes pratiques pour GKE RBAC.

IAM et le contrôle des accès basé sur les rôles (RBAC) fonctionnent conjointement, et une entité doit disposer des autorisations nécessaires, dans les deux cadres, pour travailler avec les ressources de votre cluster.

Attribuez les rôles IAM appropriés pour GKE aux groupes et aux utilisateurs afin de leur fournir des autorisations au niveau du projet et utilisez le contrôle d'accès RBAC pour accorder des autorisations au niveau d'un cluster et d'un espace de noms. Pour en savoir plus, consultez la page sur le contrôle des accès.

Vous pouvez utiliser des autorisations IAM et RBAC avec des espaces de noms pour limiter les interactions des utilisateurs avec les ressources du cluster sur la console Google Cloud. Pour en savoir plus, consultez Activer l'accès et afficher les ressources de cluster par espace de noms.

Limiter le trafic entre les pods avec une règle de réseau

Recommandation de benchmark CIS GKE : 6.6.7. Assurez-vous que la règle de réseau est activée et définie de manière appropriée

Par défaut, tous les pods d'un cluster peuvent communiquer entre eux. Vous devez contrôler les communications entre les pods 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 accidentels ou provoqués délibérément. Voici deux méthodes recommandées pour contrôler le trafic :

  1. Utilisez Istio. Consultez la page Installer Istio sur Google Kubernetes Engine si vous êtes intéressé par l'équilibrage de charge, l'autorisation de service, la limitation de bande passante, les quotas, les métriques, etc.
  2. Utilisez les règles de réseau Kubernetes. Consultez la section Créer une règle de réseau de cluster. Choisissez cette option si vous recherchez la fonctionnalité de contrôle d'accès de base exposée par Kubernetes. Pour mettre en œuvre des approches courantes pour restreindre le trafic à l'aide de règles de réseau, suivez le guide de mise en œuvre inclus dans les plans de sécurité GKE Enterprise. En outre, la documentation Kubernetes propose un excellent tutoriel pour un déploiement nginx simple. Pensez à utiliser la journalisation des règles de réseau pour vérifier que vos règles de réseau fonctionnent comme prévu.

Istio et les règles de réseau peuvent être utilisés conjointement si besoin est.

Gérer les secrets

Recommandation de benchmark CIS GKE : 6.3.1. Envisagez de chiffrer les secrets Kubernetes à l'aide des clés gérées dans Cloud KMS

Vous devez fournir une couche de protection supplémentaire pour les données sensibles (par exemple, les secrets) stockées dans etcd. Pour ce faire, vous devez configurer un gestionnaire de secrets intégré aux clusters GKE. Certaines solutions fonctionnent à la fois dans GKE et dans GKE sur VMware. Elles peuvent donc être plus utiles si vous exécutez des charges de travail dans plusieurs environnements. Si vous choisissez d'utiliser un gestionnaire de secrets externe (par exemple, HashiCorp Vault), vous devez configurer ce gestionnaire avant de créer votre cluster.

Vous disposez de plusieurs options pour la gestion des secrets.

  • Vous pouvez utiliser les secrets Kubernetes en mode natif dans GKE. Vous pouvez éventuellement les chiffrer au niveau de l'application avec une clé que vous gérez, en utilisant le chiffrement des secrets au niveau de la couche d'application.
  • Vous pouvez utiliser un gestionnaire de secrets tel que HashiCorp Vault. L'utilisation d'un mode renforcé à haute disponibilité permet une gestion des secrets cohérente et prête pour la production. Vous pouvez vous authentifier auprès de HashiCorp Vault à l'aide d'un compte de service Kubernetes ou d'un compte de service Google Cloud. Pour en savoir plus sur l'utilisation de GKE avec Vault, consultez la page indiquant comment exécuter et connecter HashiCorp Vault sur Kubernetes.

Les VM GKE sont chiffrées au niveau de la couche de stockage par défaut, ce qui inclut etcd.

Utiliser des contrôleurs d'admission pour appliquer les règles

Les contrôleurs d'admission sont des plug-ins qui régissent et appliquent la façon dont le cluster est utilisé. Ils doivent être activés pour utiliser certaines des fonctionnalités de sécurité les plus avancées de Kubernetes et constituent un élément important de l'approche de défense en profondeur pour renforcer votre cluster.

Par défaut, les pods de Kubernetes peuvent fonctionner avec des fonctionnalités allant au-delà de leurs besoins. Vous devez limiter les capacités des pods à celles requises pour la charge de travail.

Kubernetes permet de nombreux contrôles de l'exécution des pods afin qu'elle se limite aux fonctionnalités explicitement autorisées. Par exemple, Policy Controller est disponible pour les clusters dans les parcs. Kubernetes dispose également du contrôleur d'admission PodSecurity intégré qui vous permet d'appliquer les normes de sécurité des pods dans des clusters individuels.

Policy Controller est une fonctionnalité de GKE Enterprise qui vous permet d'appliquer et de valider la sécurité sur des clusters GKE à grande échelle à l'aide de stratégies déclaratives. Pour savoir comment utiliser Policy Controller pour appliquer des contrôles déclaratifs sur votre cluster GKE, consultez la page Installer Policy Controller.

Le contrôleur d'admission PodSecurity vous permet d'appliquer des règles prédéfinies dans des espaces de noms spécifiques ou dans l'ensemble du cluster. Ces règles correspondent aux différentes normes de sécurité des pods.

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 contourner les règles. 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 GKE, vous devez définir les paramètres suivants dans Constraint :

parameters:
  allowedGroups:
  - system:masters
  allowedUsers:
  - system:addon-manager

Restreindre l'utilisation du type de volume obsolète gcePersistentDisk

Le type de volume obsolète gcePersistentDisk vous permet d'installer un disque persistant Compute Engine sur des pods. Nous vous recommandons de limiter l'utilisation du type de volume gcePersistentDisk dans vos charges de travail. GKE n'applique aucun contrôle des autorisations IAM sur le pod lors de l'installation de ce type de volume, bien que Google Cloud applique des contrôles d'autorisation lors de l'association du disque à la VM sous-jacente. Un pirate informatique déjà autorisé à créer des pods dans un espace de noms peut donc accéder au contenu des disques persistants Compute Engine de votre projet Google Cloud.

Pour accéder aux disques persistants Compute Engine et les utiliser, utilisez plutôt PersistentVolumes et PersistentVolumeClaims. Appliquez des règles de sécurité dans votre cluster afin d'empêcher l'utilisation du type de volume gcePersistentDisk.

Pour empêcher l'utilisation du type de volume gcePersistentDisk, appliquez une règle Baseline ou Restricted avec le Contrôleur d'admission PodSecurity. Vous pouvez également définir une contrainte personnalisée dans Policy Controller ou dans le contrôleur d'admission Gatekeeper.

Pour définir une contrainte personnalisée afin de restreindre ce type de volume, procédez comme suit :

  1. Installer un contrôleur d'admission basé sur des règles, tel que Policy Controller ou OPA Gatekeeper.

    Policy Controller

    Installez Policy Controller dans votre cluster.

    Policy Controller est une fonctionnalité payante pour les utilisateurs de GKE. Policy Controller est basé sur la bibliothèque Open Source Gatekeeper, mais vous avez également accès à la bibliothèque complète de modèles de contraintes, aux groupes de règles et à l'intégration aux tableaux de bord de la console Google Cloud, pour vous aider à observer et gérer vos clusters. Les groupes de règles constituent des bonnes pratiques avisées, que vous pouvez appliquer à vos clusters, y compris des groupes basés sur des recommandations telles que le benchmark CIS de Kubernetes.

    Gatekeeper

    Installez Gatekeeper dans votre cluster.

    Pour les clusters Autopilot, ouvrez le fichier manifeste Gatekeeper gatekeeper.yaml dans un éditeur de texte. Modifiez le champ rules dans la spécification MutatingWebhookConfiguration pour remplacer les caractères génériques (*) par des groupes d'API et des noms de ressources spécifiques, comme dans l'exemple suivant :

    apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
...
webhooks:
- admissionReviewVersions:
  - v1
  - v1beta1
  ...
  rules:
  - apiGroups:
    - core
    - batch
    - apps
    apiVersions:
    - '*'
    operations:
    - CREATE
    - UPDATE
    resources:
    - Pod
    - Deployment
    - Job
    - Volume
    - Container
    - StatefulSet
    - StorageClass
    - Secret
    - ConfigMap
  sideEffects: None
  timeoutSeconds: 1

    Appliquez le fichier manifeste gatekeeper.yaml mis à jour à votre cluster Autopilot pour installer Gatekeeper. Cela est nécessaire, car, par mesure de sécurité intégrée, Autopilot interdit les caractères génériques dans les webhooks d'admission avec mutation.

  2. Déployez le modèle de contrainte (ConstraintTemplate) de type de volume de la règle de sécurité des pods intégrée :

    kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper-library/master/library/pod-security-policy/volumes/template.yaml

  3. Enregistrez la contrainte suivante avec une liste de types de volumes autorisés sous le nom constraint.yaml :

    apiVersion: constraints.gatekeeper.sh/v1beta1
kind: k8sPSPVolumeTypes
metadata:
  name: nogcepersistentdisk
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pods"]
  parameters:
    volumes: ["configMap", "csi", "projected", "secret", "downwardAPI", "persistentVolumeClaim", "emptyDir", "nfs", "hostPath"]

    Cette contrainte restreint les volumes à la liste associée au champ spec.parameters.volumes.

  4. Déployez la contrainte :

    kubectl apply -f constraint.yaml

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.

La plupart des recommandations présentées dans ce guide de renforcement, ainsi que d'autres erreurs de configuration courantes, peuvent être vérifiées automatiquement à l'aide de Security Health Analytics.

Configuration par défaut sécurisée

Les sections suivantes décrivent les options qui sont configurées de manière sécurisée par défaut dans les nouveaux clusters. Vous devez vérifier que les clusters préexistants sont configurés de manière sécurisée.

Protéger les métadonnées d'un nœud

Recommandations de benchmark CIS GKE : 6.4.1. Assurez-vous que les anciennes API de métadonnées de l'instance Compute Engine sont désactivées et en version 6.4.2. Vérifiez que le serveur de métadonnées GKE est activé

Les points de terminaison du serveur de métadonnées Compute Engine v0.1 et v1beta1 sont obsolètes et ont été arrêtés le 30 septembre 2020. Ces points de terminaison n'appliquent pas les en-têtes de requêtes de métadonnées. Pour connaître le calendrier d'arrêt, consultez la page Abandon des points de terminaison du serveur de métadonnées v0.1 et v1beta1.

Certaines attaques menées contre Kubernetes reposent sur un accès au serveur de métadonnées de la VM visant à extraire les identifiants. Ces attaques sont bloquées si vous utilisez la fédération d'identité de charge de travail pour GKE ou la dissimulation de métadonnées.

Conserver les anciennes méthodes d'authentification client en mode inactif

Recommandations de benchmark CIS GKE : 6.8.1. Assurez-vous que l'authentification de base à l'aide de mots de passe statiques est désactivée et en version 6.8.2. Vérifiez que l'authentification à l'aide de certificats clients est désactivée

Il existe plusieurs méthodes d'authentification auprès du serveur d'API Kubernetes. Dans GKE, les méthodes acceptées sont les jetons de support de compte de service, les jetons OAuth et les certificats client x509. GKE gère l'authentification avec gcloud en utilisant la méthode du jeton OAuth, en gérant la configuration de Kubernetes, ainsi qu'en obtenant un jeton d'accès et en le maintenant à jour.

Avant l'intégration de GKE à OAuth, les seules méthodes d'authentification disponibles étaient les certificats x509 générés pour un usage unique et les mots de passe statiques. Aujourd'hui, ces méthodes ne sont plus recommandées et il est préférable de les désactiver. Ces méthodes présentent une surface d'attaque plus étendue pouvant compromettre la sécurité du cluster. Elles sont désactivées par défaut depuis la version 1.12 de GKE. Si vous utilisez d'anciennes méthodes d'authentification, nous vous recommandons de les désactiver. L'authentification avec un mot de passe statique est obsolète et a été supprimée depuis la version 1.19 de GKE.

Les clusters existants doivent désormais utiliser la méthode OAuth. Si un système externe au cluster requiert des identifiants de longue durée, nous vous recommandons de créer un compte de service Google ou un compte de service Kubernetes avec les privilèges nécessaires, puis d'exporter la clé.

Pour mettre à jour un cluster existant et supprimer le mot de passe statique, consultez la page Désactiver l'authentification avec un mot de passe statique.

Il n'existe actuellement aucun moyen de supprimer le certificat client pré-émis d'un cluster existant, mais il ne dispose d'aucune autorisation si le contrôle d'accès RBAC est activé et si ABAC est désactivé.

Laisser Cloud Logging activé

Recommandation de benchmark CIS GKE : 6.7.1. Assurez-vous que Stackdriver Kubernetes Logging et Stackdriver Kubernetes Monitoring sont activés

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. Par défaut, les clusters GKE Enterprise sont intégrés à Cloud Logging et doivent rester configurés.

Par défaut, tous les clusters GKE ont la fonctionnalité de journalisation d'audit Kubernetes activée. Elle conserve un enregistrement chronologique des appels envoyés au serveur d'API Kubernetes. Les entrées du journal d'audit Kubernetes sont utiles pour enquêter sur les requêtes API suspectes, pour collecter des statistiques ou pour créer des alertes de surveillance pour les appels d'API indésirables.

Les clusters GKE intègrent la journalisation d'audit Kubernetes avec Cloud Audit Logging et Cloud Logging. Les journaux peuvent être acheminés de Cloud Logging vers vos propres systèmes de journalisation.

Conserver l'UI Web de Kubernetes (tableau de bord) en mode inactif

Recommandation de benchmark CIS GKE : 6.10.1. Vérifiez que l'interface utilisateur Web de Kubernetes est désactivée

Vous ne devez pas activer l'UI Web de Kubernetes (tableau de bord) lorsque vous utilisez GKE.

L'UI Web de Kubernetes (tableau de bord) est protégée par un compte de service Kubernetes à privilèges élevés. La console Google Cloud offre presque les mêmes fonctionnalités. Vous n'avez donc pas besoin de ces autorisations.

Pour désactiver l'UI Web de Kubernetes, exécutez cette commande :

gcloud container clusters update CLUSTER_NAME \
    --update-addons=KubernetesDashboard=DISABLED

Conserver ABAC en mode inactif

Recommandation de benchmark CIS GKE : 6.8.4. Assurez-vous que l'ancienne autorisation (ABAC) est désactivée

Vous devez désactiver le contrôle des accès basé sur les attributs (ABAC, Attribute-Based Access Control) et utiliser à la place le contrôle des accès basé sur les rôles (RBAC, Role-Based Access Control) dans GKE.

Par défaut, ABAC est désactivé pour les clusters créés avec GKE version 1.8 ou ultérieure. Dans Kubernetes, RBAC permet d'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. Le contrôle d'accès RBAC présente des avantages significatifs par rapport à la sécurité.

Si vous utilisez toujours le contrôle d'accès ABAC, lisez d'abord les conditions préalables correspondantes. Si vous avez mis à niveau votre cluster à partir d'une version antérieure et que vous utilisez le contrôle d'accès ABAC, vous devez mettre à jour la configuration des contrôles d'accès :

gcloud container clusters update CLUSTER_NAME \
    --no-enable-legacy-authorization

Pour créer un cluster avec la recommandation ci-dessus, exécutez cette commande :

gcloud container clusters create CLUSTER_NAME \
    --no-enable-legacy-authorization

Laissez le contrôleur d'admission DenyServiceExternalIPs activé

Ne désactivez pas le contrôleur d'admission DenyServiceExternalIPs.

Le contrôleur d'admission DenyServiceExternalIPs empêche les services d'utiliser des adresses IP externes et limite une faille de sécurité connue.

Le contrôleur d'admission DenyServiceExternalIPs est activé par défaut sur les nouveaux clusters créés sur GKE 1.21 et versions ultérieures. Pour les clusters qui sont mis à jour vers GKE 1.21 ou versions ultérieures, vous pouvez activer le contrôleur d'admission à l'aide de la commande suivante :

gcloud beta container clusters update CLUSTER_NAME \
    --no-enable-service-externalips

Étape suivante