Présentation de la sécurité

Google Kubernetes Engine (GKE) propose de nombreuses méthodes pour vous aider à sécuriser vos charges de travail. La protection des charges de travail dans GKE implique de nombreuses couches de la pile, y compris le contenu de votre image de conteneur, l'environnement d'exécution du conteneur, le réseau du cluster et l'accès au serveur d'API du cluster.

Il est préférable d'adopter une approche multicouche pour protéger vos clusters et vos charges de travail. Vous pouvez appliquer le principe de moindre privilège au niveau d'accès fourni à vos utilisateurs et à votre application. Dans chaque couche, différents compromis peuvent être nécessaires pour permettre à votre organisation de déployer et de gérer de manière sécurisée ses charges de travail, avec le niveau de flexibilité et de sécurité approprié. Par exemple, certains paramètres de sécurité peuvent être trop contraignants pour que certains types d'applications ou certains cas d'utilisation puissent fonctionner sans refactorisation importante.

Ce document fournit une vue d'ensemble de chaque couche de votre infrastructure et montre comment vous pouvez configurer ses fonctionnalités de sécurité pour répondre au mieux à vos besoins.

Authentification et autorisation

Kubernetes accepte deux types d'authentification :

  1. Les comptes utilisateur sont des comptes connus de Kubernetes, mais qui ne sont pas gérés par Kubernetes. Par exemple, vous ne pouvez pas les créer, ni les supprimer à l'aide de la commande kubectl.
  2. Les comptes de service sont des comptes créés et gérés par Kubernetes, mais qui ne peuvent être utilisés que par des entités créées par Kubernetes, telles que des pods.

Dans un cluster GKE, les comptes utilisateur Kubernetes sont gérés par Google Cloud et peuvent appartenir à l'un des deux types suivants :

  1. Compte Google
  2. Compte de service Google Cloud

Une fois authentifié, vous devez autoriser ces identités à créer, lire, mettre à jour ou supprimer des ressources Kubernetes.

Malgré une appellation similaire, les comptes de service Kubernetes et les comptes de service Google Cloud sont des entités différentes. Les comptes de service Kubernetes font partie du cluster dans lequel ils sont définis et sont généralement utilisés au sein de ce cluster. En revanche, les comptes de service Google Cloud font partie d'un projet Google Cloud et peuvent facilement recevoir des autorisations au sein des clusters et pour des clusters de projets Google Cloud eux-mêmes, ainsi que pour toute ressource Google Cloud utilisant IAM (Identity and Access Management). Ainsi, les comptes de service Google Cloud sont plus puissants que les comptes de service Kubernetes. Afin de respecter le principe de sécurité du moindre privilège, vous devez envisager de n'utiliser des comptes de service Google Cloud que lorsque leurs fonctionnalités sont requises.

Pour configurer un accès plus granulaire aux ressources Kubernetes au niveau du cluster ou dans les espaces de noms Kubernetes, utilisez le contrôle d'accès basé sur les rôles (RBAC). Le contrôle RBAC vous permet de créer des stratégies détaillées qui définissent les opérations et les ressources auxquelles les utilisateurs et les comptes de service peuvent accéder. Avec RBAC, vous pouvez contrôler l'accès aux comptes Google, aux comptes de service Google Cloud et aux comptes de service Kubernetes. Pour simplifier davantage votre stratégie d'authentification et d'autorisation pour GKE, vous devez vous assurer que l'ancien contrôle des accès basé sur les attributs est désactivé de sorte que Kubernetes RBAC et IAM soient les sources de vérité.

Pour en savoir plus, consultez les pages suivantes :

Sécurité du plan de contrôle

Dans GKE, les composants du plan de contrôle Kubernetes sont gérés et entretenus par Google. Les composants du plan de contrôle hébergent le logiciel qui exécute le plan de contrôle Kubernetes, y compris le serveur d'API, le programmeur, le gestionnaire du contrôleur et la base de données etcd où la configuration de Kubernetes est conservée.

Par défaut, les composants du plan de contrôle utilisent une adresse IP publique. Vous pouvez protéger le serveur d'API Kubernetes à l'aide des réseaux autorisés et des clusters privés, qui vous permettent d'attribuer une adresse IP privée au plan de contrôle et de désactiver l'accès à l'adresse IP publique.

Vous pouvez gérer l'authentification du cluster dans Google Kubernetes Engine en utilisant IAM en tant que fournisseur d'identité. Pour en savoir plus sur l'authentification, consultez la page S'authentifier auprès du serveur d'API Kubernetes.

Un autre moyen de sécuriser votre plan de contrôle est de vous assurer que vous effectuez régulièrement une turnover des identifiants. Lorsque la rotation des identifiants est lancée, les certificats SSL et l'autorité de certification du cluster font l'objet d'une rotation. Ce processus est automatisé par GKE et garantit également la rotation de l'adresse IP de votre plan de contrôle.

Pour en savoir plus, consultez les pages suivantes :

Sécurité des nœuds

GKE déploie vos charges de travail sur des instances Compute Engine s'exécutant dans votre projet Google Cloud. Ces instances sont associées à votre cluster GKE en tant que nœuds. Les sections suivantes vous montrent comment exploiter des fonctionnalités de sécurité au niveau du nœud disponibles dans Google Cloud.

Container-Optimized OS

Par défaut, les nœuds GKE utilisent Container-Optimized OS de Google en tant que système d'exploitation sur lequel exécuter Kubernetes et ses composants. Container-Optimized OS met en œuvre plusieurs fonctionnalités avancées destinées à améliorer la sécurité des clusters GKE, y compris :

  • Un pare-feu verrouillé
  • Un système de fichiers en lecture seule si possible
  • Des comptes utilisateur limités et une connexion racine désactivée

Les nœuds GKE Autopilot utilisent toujours Container-Optimized OS comme système d'exploitation.

Mises à niveau de nœuds

Une bonne pratique consiste à appliquer des correctifs réguliers à votre OS de façon régulière. De temps en temps, des problèmes de sécurité liés à l'exécution du conteneur, à Kubernetes lui-même ou au système d'exploitation du nœud peuvent vous obliger à mettre à niveau vos nœuds plus rapidement. Lorsque vous mettez à niveau votre nœud, le logiciel du nœud est mis à niveau vers sa dernière version.

Les clusters GKE sont compatibles avec les mises à niveau automatiques. Dans les clusters Autopilot, les mises à niveau automatiques sont toujours activées. Vous pouvez également mettre à niveau manuellement les nœuds d'un cluster standard.

Protéger les nœuds contre les charges de travail non approuvées

Pour les clusters qui exécutent des charges de travail inconnues ou non approuvées, il est recommandé de protéger le système d'exploitation sur le nœud de la charge de travail non approuvée exécutée dans un pod.

Par exemple, les clusters mutualisés, tels que les fournisseurs d'applications SaaS (Software as a service), exécutent souvent du code inconnu transmis par leurs utilisateurs. Pour d'autres applications comme les recherches sur la sécurité, les charges de travail peuvent nécessiter une isolation plus importante que celle fournie par les nœuds par défaut.

Pour isoler les charges de travail non approuvées, vous pouvez activer GKE Sandbox dans des bacs à sable sur le nœud. GKE Sandbox est conçu à l'aide de gVisor, un projet Open Source.

Sécuriser des métadonnées d'instance

GKE utilise les métadonnées de l'instance des instances Compute Engine sous-jacentes pour fournir aux nœuds des identifiants et des configurations permettant d'amorcer les nœuds et de se connecter au plan de contrôle. Ces métadonnées contiennent des informations sensibles auxquelles les pods du nœud n'ont pas besoin d'accéder, telles que la clé du compte de service du nœud.

Vous pouvez verrouiller les chemins d'accès aux métadonnées d'instances sensibles à l'aide de la fédération d'identité de charge de travail pour GKE. La fédération d'identité de charge de travail pour GKE active le serveur de métadonnées GKE dans votre cluster, qui filtre les requêtes envoyées à des champs sensibles tels que kube-env.

La fédération d'identité de charge de travail pour GKE est toujours activée dans les clusters Autopilot. Dans les clusters Standard, les pods ont accès aux métadonnées d'instance, sauf si vous activez manuellement la fédération d'identité de charge de travail pour GKE.

La sécurité du réseau

La plupart des charges de travail exécutées dans GKE doivent communiquer avec d'autres services susceptibles de s'exécuter à l'intérieur ou à l'extérieur du cluster. Vous pouvez utiliser différentes méthodes pour contrôler le trafic autorisé dans vos clusters et leurs pods.

Limiter la communication entre pods

Par défaut, tous les pods d'un cluster sont accessibles sur le réseau par l'intermédiaire de l'adresse IP de leur pod. De même, par défaut, le trafic de sortie autorise les connexions sortantes à toute adresse accessible dans le VPC dans lequel le cluster a été déployé.

Les administrateurs et les utilisateurs du cluster peuvent verrouiller les connexions d'entrée et de sortie créées vers et depuis les pods d'un espace de noms à l'aide de règles de réseau. Par défaut, en l'absence de règle de réseau définie, tout le trafic entrant et sortant est autorisé à circuler dans l'ensemble des pods. Les stratégies réseau vous permettent d’utiliser des balises pour définir le trafic qui traverse vos pods.

Une fois qu'une règle de réseau est appliquée dans un espace de noms, tout le trafic est supprimé des pods ne correspondant pas aux libellés configurés. Lors de la création de clusters et/ou d'espaces de noms, vous pouvez appliquer le refus de trafic par défaut à l'entrée et à la sortie de chaque pod afin de garantir que toutes les nouvelles charges de travail ajoutées au cluster doivent autoriser explicitement le trafic dont elles ont besoin.

Pour en savoir plus :

Filtrer le trafic à équilibrage de charge

Pour équilibrer la charge de vos pods Kubernetes avec un équilibreur de charge réseau, vous devez créer un service de type LoadBalancer, correspondant aux libellés de votre pod. Une fois le service créé, vous disposerez d’une adresse IP externe qui mappera les ports de vos pods Kubernetes. Le filtrage du trafic autorisé est réalisé au niveau du nœud par kube-proxy, qui filtre en fonction de l'adresse IP.

Pour configurer ce filtrage, vous pouvez utiliser la configuration loadBalancerSourceRanges de l'objet de service. Avec ce paramètre de configuration, vous pouvez fournir une liste des plages CIDR que vous souhaitez autoriser à accéder au service. Si vous ne configurez pas loadBalancerSourceRanges, toutes les adresses sont autorisées à accéder au service via son adresse IP externe.

Dans les cas où l'accès externe au service n'est pas requis, envisagez d'utiliser un équilibreur de charge interne. L'équilibreur de charge interne respecte également les plages loadBalancerSourceRanges lorsqu'il est nécessaire de filtrer le trafic de l'intérieur du VPC.

Pour plus d'informations, suivez le tutoriel d'équilibrage de charge interne.

Sécuriser vos charges de travail

Kubernetes permet aux utilisateurs de provisionner, mettre à l'échelle et mettre à jour rapidement des charges de travail basées sur des conteneurs. Cette section décrit les tactiques que les administrateurs et les utilisateurs peuvent utiliser pour limiter les effets potentiels d'un conteneur en cours d'exécution sur d'autres conteneurs du même cluster. Elle décrit également les nœuds sur lesquels les conteneurs peuvent s'exécuter et les services Google Cloud activés dans les projets des utilisateurs.

Limiter les droits de processus en conteneur du pod

Limiter les droits des processus en conteneur est important pour la sécurité globale de votre cluster. Les clusters GKE Autopilot limitent toujours des droits spécifiques, comme décrit sur la page Fonctionnalités de sécurité Autopilot.

GKE vous permet aussi de définir des options relatives à la sécurité via le contexte de sécurité sur les pods et les conteneurs. Ces paramètres vous permettent de modifier les paramètres de sécurité de vos processus, tels que :

  • Utilisateur et groupe exécutant
  • Capacités Linux disponibles
  • Capacité à transmettre les droits

Pour appliquer ces restrictions au niveau du cluster plutôt qu'au niveau du pod ou du conteneur, utilisez le contrôleur PodSecurityAdmission. Les administrateurs de cluster peuvent utiliser PodSecurityAdmission pour s'assurer que tous les pods d'un cluster ou d'un espace de noms respectent une règle prédéfinie dans les normes de sécurité des pods. Vous pouvez également définir des règles de sécurité de pod personnalisées au niveau du cluster à l'aide de Gatekeeper.

Les systèmes d'exploitation du nœud GKE, Container-Optimized OS et Ubuntu, appliquent les règles de sécurité par défaut de Docker AppArmor à tous les conteneurs démarrés par Kubernetes. Vous pouvez consulter le modèle du profil sur GitHub. Entre autres choses, le profil refuse les capacités suivantes aux conteneurs :

  • Écrire des fichiers directement dans /proc/
  • Écrire dans des fichiers qui ne se trouvent pas dans un annuaire d'ID de processus /proc/<number>
  • Écrire dans des fichiers dans /proc/sys autres que /proc/sys/kernel/shm*
  • Monter des systèmes de fichiers

Pour en savoir plus, consultez ce document :

Donner aux pods l'accès aux ressources Google Cloud

Vos conteneurs et pods peuvent nécessiter un accès à d'autres ressources dans Google Cloud. Il existe trois façons de procéder.

Le moyen le plus sécurisé d'autoriser les pods à accéder aux ressources Google Cloud consiste à utiliser la fédération d'identité de charge de travail pour GKE. La fédération d'identité de charge de travail pour GKE permet à un compte de service Kubernetes de s'exécuter en tant que compte de service IAM. Les pods qui s'exécutent en tant que compte de service Kubernetes disposent des autorisations du compte de service IAM.

La fédération d'identité de charge de travail pour GKE peut être utilisée avec GKE Sandbox.

Compte de service de nœud

Dans les clusters standards, vos pods peuvent également s'authentifier auprès de Google Cloud à l'aide des identifiants du compte de service utilisé par la machine virtuelle (VM) Compute Engine du nœud.

Cette approche n'est pas compatible avec GKE Sandbox, car celui-ci bloque l'accès au serveur de métadonnées Compute Engine.

Vous pouvez attribuer des identifiants pour les ressources Google Cloud aux applications à l'aide de la clé de compte de service. Cette approche est fortement déconseillée en raison de la difficulté à gérer les clés de compte de manière sécurisée.

Si vous choisissez cette méthode, utilisez des comptes de service IAM personnalisés pour chaque application afin que celles-ci disposent des autorisations minimales nécessaires. Attribuez à chaque compte de service les rôles IAM minimaux nécessaires au bon fonctionnement de son application couplée. Gardez des comptes de service spécifiques à l'application facilite la révocation de l'accès en cas de compromis sans affecter les autres applications. Une fois que vous avez attribué les rôles IAM appropriés à votre compte de service, vous pouvez créer une clé de compte de service JSON, puis la monter dans votre pod à l'aide d'un secret Kubernetes.

Utiliser l'autorisation binaire

L'autorisation binaire est un service Google Cloud qui fournit une sécurité sur la chaîne d'approvisionnement logicielle pour les applications exécutées dans le cloud. L'autorisation binaire fonctionne avec les images que vous déployez dans GKE à partir d'Artifact Registry ou d'un autre registre d'images de conteneurs.

En appliquant l'autorisation binaire, vous pouvez vous assurer que les processus internes protégeant la qualité et l'intégrité de vos logiciels se sont bien terminés avant de déployer une application dans votre environnement de production. Pour obtenir des instructions sur la création d'un cluster avec l'autorisation binaire activée, consultez la page Créer un cluster dans la documentation sur l'autorisation binaire.

La validation continue (CV) de l'autorisation binaire vous permet de vous assurer que les images de conteneurs associées aux pods sont régulièrement surveillées pour s'assurer qu'elles sont conformes à vos processus internes en constante évolution.

Journaux d'audit

La journalisation d'audit offre aux administrateurs un moyen de conserver, d'interroger, de traiter et de notifier les événements qui se produisent dans vos environnements GKE. Les administrateurs peuvent utiliser les informations consignées pour effectuer des analyses forensiques ou des alertes en temps réel, ou pour cataloguer la manière dont une flotte de clusters GKE est utilisée et par qui.

Par défaut, GKE enregistre les journaux des activités d'administration. Vous pouvez également enregistrer les événements Accès aux données, en fonction des types d'opérations que vous souhaitez inspecter.

Pour en savoir plus, consultez les pages suivantes :

Mesures de sécurité intégrées

GKE applique des restrictions spécifiques sur ce que vous pouvez faire à des objets système dans vos clusters. Lorsque vous effectuez une opération telle que l'application d'un correctif à une charge de travail, un webhook d'admission nommé GKE Warden valide votre requête par rapport à un ensemble d'opérations restreintes, et décide d'autoriser ou non la requête.

Mesures de sécurité des clusters Autopilot

Les clusters Autopilot appliquent plusieurs paramètres de sécurité en fonction de notre expertise et des bonnes pratiques du secteur. Pour en savoir plus, consultez la section Mesures de sécurité dans Autopilot.

Mesures de sécurité des clusters standards

Les clusters standards sont plus permissifs par défaut que les clusters Autopilot. Les clusters GKE Standard disposent des paramètres de sécurité suivants :

  • Vous ne pouvez pas mettre à jour le compte de service utilisé par les charges de travail du système gérées par GKE, telles que les charges de travail de l'espace de noms kube-system.
  • Vous ne pouvez pas lier l'objet ClusterRole cluster-admin par défaut aux groupes system:anonymous, system:unauthenticated ou system:authenticated.