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 Platform (GCP) et peuvent appartenir à l'un des deux types suivants :

  1. Compte Google
  2. Compte de service Google Cloud Platform (GCP)

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 GCP 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 GCP font partie d’un projet GCP et peuvent facilement recevoir des autorisations au sein des clusters et pour des clusters de projets Google Cloud Platform eux-mêmes, ainsi que pour toute ressource GCP utilisant Cloud Identity and Access Management (Cloud IAM). Ainsi, les comptes de service GCP 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 GCP que lorsque leurs fonctionnalités sont requises.

Pour configurer un accès plus précis 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 (role-based access control ou 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 GCP 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 que vous avez 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 GCP. Ces instances sont rattachées à votre cluster Google Kubernetes Engine en tant que nœuds. Les sections suivantes vous montrent comment tirer parti des fonctionnalités de sécurité au niveau du nœud disponibles dans GCP.

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 implémente 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 .

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 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 GCP 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 voir 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/)
  • É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 GCP

Vos conteneurs et pods peuvent nécessiter un accès à d'autres ressources dans GCP. Un moyen permettant aux applications d'accéder aux identifiants pour les ressources GCP consiste à utiliser les informations d'identification du compte de service des clusters Kubernetes à partir de métadonnées. Cependant, ces identifiants sont accessibles par tous les pods exécutés sur le cluster. Vous devez créer et configurer un compte de service personnalisé pour vos clusters comportant au minimum les rôles IAM devant s'appliquer à tous les pods exécutés dans le cluster.

Une autre façon de fournir des identifiants est d'utiliser une clé JSON de compte de service. 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.

Pour en savoir plus :

Utiliser l'autorisation binaire

L'autorisation binaire est un service de GCP 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 relative à 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…