Présentation des fonctionnalités de sécurité

Google Kubernetes Engine propose de nombreuses méthodes pour sécuriser vos charges de travail. La protection des charges de travail dans Google Kubernetes Engine implique de nombreuses couches de la pile, y compris le contenu de votre image de conteneur, son environnement d'exécution, 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 Google Kubernetes Engine, 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 Cloud Identity and Access Management (Cloud IAM). 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 et rationaliser davantage votre stratégie d'authentification et d'autorisation pour Google Kubernetes Engine, vous devez vous assurer que le contrôle d'accès basé sur les attributs anciens est désactivé de sorte que Kubernetes RBAC et Cloud IAM soient la source d'informations.

Pour en savoir plus :

Sécurité du plan de contrôle

Dans Google Kubernetes Engine, les composants principaux de Kubernetes sont gérés et entretenus par Google. Les composants maîtres 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 maîtres utilisent une adresse IP publique. Vous pouvez protéger le serveur d'API Kubernetes à l'aide des réseaux autorisés principaux et des clusters privés, qui vous permettent d'attribuer une adresse IP privée au maître 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 Cloud IAM en tant que fournisseur d'identité. Cependant, l'authentification basée sur le nom d'utilisateur et le mot de passe héritée est activée par défaut dans Google Kubernetes Engine. Pour améliorer la sécurité de l'authentification, vous devez vous assurer d'avoir désactivé l'authentification de base en définissant un nom d'utilisateur et un mot de passe vides pour la configuration MasterAuth. Dans la même configuration, vous pouvez également désactiver le certificat client, ce qui garantit que vous avez une clé de moins à prendre en compte lors du verrouillage de l'accès à votre cluster.

Un autre moyen de sécuriser votre maître Kubernetes est de vous assurer que vous effectuez régulièrement une rotation 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 Google Kubernetes Engine et garantit également la rotation de votre adresse IP principale.

Pour en savoir plus :

Sécurité des nœuds

Google Kubernetes Engine déploie vos charges de travail sur des instances Compute Engine s'exécutant dans votre projet Google Cloud. Ces instances sont rattachées à votre cluster Google Kubernetes Engine 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 Google Kubernetes Engine utilisent Google Container-Optimized OS 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 Google Kubernetes Engine, 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

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.

Vous pouvez mettre à niveau manuellement les nœuds de votre cluster, mais Google Kubernetes Engine vous permet également d'activer des mises à niveau automatiques.

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

Les nœuds Google Kubernetes Engine s'exécutent en tant qu'instances Compute Engine et ont donc accès aux métadonnées de l'instance par défaut. Les métadonnées d'instance sont utilisées pour fournir aux nœuds des identifiants et des configurations utilisées lors de l'amorçage et de la connexion aux nœuds maîtres Kubernetes. Toutefois, un pod exécuté sur un nœud n'a pas nécessairement besoin de ces informations, qui incluent des données sensibles, 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 en désactivant les API anciennes et en utilisant la dissimulation de métadonnées. La dissimulation des métadonnées garantit que les pods exécutés dans votre cluster ne peuvent pas accéder aux données sensibles en filtrant les requêtes dans des champs tels que kube-env.

Sécurité du réseau

La plupart des charges de travail exécutées dans Google Kubernetes Engine 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 ajouter à la liste blanche pour 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 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 en savoir plus :

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. Google Kubernetes Engine vous permet 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

Afin de modifier ces paramètres au niveau du cluster plutôt que du pod ou du conteneur, vous devez implémenter une règle PodSecurityPolicy. Les administrateurs de cluster peuvent utiliser PodSecurityPolicies pour s'assurer que tous les pods d'un cluster respectent une règle de référence minimale que vous définissez.

Les systèmes d'exploitation du nœud Google Kubernetes Engine, Container-Optimized OS et Ubuntu, appliquent les règles de sécurité par défaut de Docker AppArmor à tous les conteneurs lancé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 :

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 simple et le plus sécurisé d'autoriser les pods à accéder aux ressources Google Cloud consiste à utiliser Workload Identity. Cette fonctionnalité permet à un compte de service Kubernetes de s'exécuter en tant que compte de service Google Cloud. Les pods qui s'exécutent en tant que compte de service Kubernetes disposent des autorisations du compte de service Google Cloud.

Workload Identity peut être utilisé avec GKE Sandbox.

Compte de service de nœud

Vos pods peuvent également s'authentifier auprès de Google Cloud en utilisant les identifiants de compte de service des clusters Kubernetes issus des métadonnées. Toutefois, ces identifiants peuvent être obtenus par n'importe quel pod s'exécutant dans le cluster. Créez et configurez un compte de service personnalisé qui dispose des rôles Cloud IAM minimaux requis par tous les pods qui s'exécutent dans le cluster.

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

Clé JSON de compte de service

La troisième méthode consiste à utiliser manuellement la clé de compte de service pour attribuer des identifiants aux applications afin d'accéder aux ressources Google Cloud. 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.

Vous devez utiliser des comptes de service GCP spécifiques à l'application pour fournir les identifiants afin que les applications disposent des autorisations minimales nécessaires. Chaque compte de service se voit uniquement attribuer les rôles Cloud IAM nécessaires au bon fonctionnement de son application couplée. Gardez un compte de service spécifique à l'application facilite la révocation de son accès en cas de compromis sans affecter les autres applications. Une fois que vous avez attribué les rôles Cloud IAM corrects à 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 code 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 de Container Registry ou d'un autre registre d'images de conteneurs. Avec 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.

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 Google Kubernetes Engine. Les administrateurs peuvent utiliser les informations consignées pour effectuer des analyses judiciaires, des alertes en temps réel ou pour cataloguer comment et par qui une flotte de clusters Google Kubernetes Engine est utilisée.

Par défaut, Google Kubernetes Engine enregistre les journaux 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 :

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Documentation Kubernetes Engine