Préparer un cluster GKE pour des locataires tiers

Ce document suggère des contrôles qui vous permettent de configurer et de sécuriser les clusters Google Kubernetes Engine (GKE) qui hébergent des applications personnalisées distribuées par des locataires tiers. Il fait partie d'une solution de plans composée des éléments suivants :

  • Un guide des contrôles que vous mettez en œuvre (ce document).
  • Un dépôt GitHub contenant les répertoires suivants :
    • terraform : contient le code Terraform que vous utilisez pour créer l'infrastructure et les ressources au niveau du projet. Ce code installe également les composants Anthos dans le cluster.
    • configsync : contient les ressources et les configurations au niveau du cluster qui sont appliquées à votre cluster GKE.
    • tenant-config-pkg : package kpt que vous pouvez utiliser comme modèle pour configurer de nouveaux locataires dans le cluster GKE.

Ce document est destiné aux équipes qui gèrent les clusters GKE. Nous partons du principe que vous connaissez bien GKE et Kubernetes.

Dans ce document, nous partons du principe que vous avez déjà configuré un ensemble fondamental de contrôles de sécurité pour protéger votre infrastructure cloud, tels que ceux décrits dans le guide sur les principes de base de la sécurité dans Google Cloud. Le plan permet de superposer des contrôles supplémentaires sur les contrôles de sécurité existants pour protéger vos clusters GKE.

Architecture

Le schéma suivant décrit l'architecture que vous allez créer avec ce plan:

Composants d'infrastructure du plan.

Comme indiqué dans le schéma précédent, le plan permet de créer et de configurer les composants d'infrastructure suivants :

  • Un réseau cloud privé virtuel (VPC) et un sous-réseau.
  • Un cluster GKE privé. Les nœuds de cluster sont isolés d'Internet.
  • Deux pools de nœuds GKE. Vous créez un pool de nœuds dédié pour héberger exclusivement les applications et les ressources des locataires. Les autres ressources de cluster sont hébergées dans le pool de nœuds par défaut.
  • Règles de pare-feu VPC. Vous créez des règles de référence qui s'appliquent à tous les nœuds du cluster. Vous créez des règles supplémentaires qui ne s'appliquent qu'aux nœuds du pool de nœuds locataires. Ces règles de pare-feu limitent le trafic sortant des nœuds locataires.
  • Cloud NAT pour autoriser la sortie des nœuds de cluster vers Internet.
  • Des règles Cloud DNS configurées pour activer l'accès privé à Google afin que les applications du cluster puissent accéder aux API Google sans passer par Internet.
  • Comptes de service utilisés par les nœuds et les applications du cluster.

Applications

Le schéma suivant montre les ressources au niveau du cluster que vous créez et configurez avec le plan.

Ressources au niveau du cluster.

Comme illustré dans le schéma précédent, dans le plan, vous utilisez les éléments suivants pour créer et configurer les ressources au niveau du cluster :

  • Anthos Config Management Config Sync pour synchroniser la configuration et les règles du cluster à partir d'un dépôt Git.
  • Anthos Config Management Policy Controller pour appliquer des règles aux ressources du cluster.
  • Anthos Service Mesh pour contrôler et sécuriser le trafic réseau.
  • Un espace de noms dédié aux applications et aux ressources des locataires.
  • Règles et contrôles appliqués à l'espace de noms du locataire, y compris les règles de réseau et les règles de maillage de services.

Comprendre les contrôles de sécurité nécessaires

Cette section décrit les contrôles que vous appliquez avec le plan pour vous aider à sécuriser votre cluster GKE.

Sécurité renforcée des clusters GKE

Créer des clusters conformément aux bonnes pratiques de sécurité.

Le plan permet de créer un cluster GKE qui implémente les paramètres de sécurité suivants :

Pour plus d'informations sur les paramètres de sécurité GKE, consultez la page Renforcer la sécurité du cluster.

Règles de pare-feu VPC

Restreindre le trafic entre plusieurs machines virtuelles

Les Règles de pare-feu de cloud privé virtuel (VPC) décident quel trafic est autorisé depuis ou vers des VM Compute Engine. Les règles vous permettent de filtrer le trafic au niveau de la VM, en fonction des attributs de couche 4.

Vous créez un cluster GKE avec les règles de pare-feu de cluster GKE par défaut. Ces règles de pare-feu permettent la communication entre les nœuds du cluster et le plan de contrôle GKE, ainsi qu'entre les nœuds et les pods du cluster.

Vous appliquez des règles de pare-feu supplémentaires aux nœuds du pool de nœuds locataires. Ces règles de pare-feu limitent le trafic de sortie provenant des nœuds locataires. Cette approche vous permet d'augmenter l'isolation des nœuds locataires. Par défaut, l'ensemble du trafic sortant des nœuds locataires est refusé. Toute sortie requise doit être explicitement configurée. Vous pouvez par exemple utiliser ce plan pour créer des règles de pare-feu autorisant le trafic sortant des nœuds locataires vers le plan de contrôle GKE et les API Google à l'aide de l'accès privé à Google. Les règles de pare-feu sont ciblées sur les nœuds locataires à l'aide du compte de service du pool de nœuds locataires.

Namespaces

Attribuer des libellés à des ressources qui doivent utiliser les mêmes règles

Les espaces de noms vous permettent de définir un champ d'application pour les ressources associées au sein d'un cluster, telles que les pods, les services et les contrôleurs de réplication. Ils vous permettent également de déléguer la responsabilité de l'administration des ressources associées en tant qu'unité. Par conséquent, les espaces de noms font partie intégrante de la plupart des modèles de sécurité.

Les espaces de noms constituent une fonctionnalité importante de l'isolation du plan de contrôle. Cependant, ils ne permettent pas l'isolation des nœuds, des plans de données ou des réseaux.

Une approche courante consiste à créer des espaces de noms pour des applications individuelles. Par exemple, vous pouvez créer l'espace de noms myapp-frontend pour le composant de l'interface utilisateur d'une application.

Le plan permet de créer un espace de noms dédié pour héberger les applications d'apprentissage fédéré. L'espace de noms et ses ressources sont traités comme un locataire au sein de votre cluster. Vous appliquez des règles et des contrôles à l'espace de noms pour limiter le champ d'application des ressources qu'il contient.

Règles de réseau

Appliquer le flux de trafic réseau dans les clusters

Les règles de réseau appliquent les flux de trafic réseau de couche 4 en se basant sur les règles de pare-feu au niveau du pod. Les règles de réseau sont appliquées à un espace de noms.

Dans le plan, vous appliquez des règles de réseau à l'espace de noms du locataire qui héberge les applications tierces. Par défaut, la règle de réseau refuse tout trafic vers et depuis les pods de l'espace de noms. Tout trafic requis doit être explicitement ajouté à la liste d'autorisation. Par exemple, les règles de réseau dans le plan autorisent explicitement le trafic vers les services de cluster requis, tels que le DNS interne du cluster et le plan de contrôle d'Anthos Service Mesh.

Config Sync

Appliquer des configurations à vos clusters GKE

Config Sync synchronise vos clusters GKE avec les configurations stockées dans un dépôt Git. Le dépôt Git sert de source unique d'informations pour la configuration et les règles de votre cluster. Config Sync est déclaratif. Il vérifie en permanence l'état du cluster et applique l'état déclaré dans le fichier de configuration afin d'appliquer les règles, ce qui permet d'éviter les écarts de configuration.

Vous devez installer Config Sync dans votre cluster GKE. Vous configurez Config Sync pour synchroniser les configurations et les règles de cluster à partir du dépôt GitHub associé au plan. Les ressources synchronisées incluent les éléments suivants :

  • Configuration d'Anthos Service Mesh au niveau du cluster
  • Règles de sécurité au niveau du cluster
  • Configuration et règles au niveau de l'espace de noms locataire, y compris les règles de réseau, les comptes de service, les règles RBAC et la configuration d'Anthos Service Mesh

Policy Controller

Faire respecter les règles

Anthos Policy Controller est un contrôleur d'admission dynamique pour Kubernetes qui applique des règles basées sur l'objet CustomResourceDefinition (CRD), qui sont exécutées par le service OPA (Open Policy Agent).

Les contrôleurs d'admission sont des plug-ins Kubernetes qui interceptent les requêtes adressées au serveur d'API Kubernetes avant la persistance d'un objet, mais après l'authentification et l'autorisation de la requête. Les contrôleurs d'admission peuvent vous servir à limiter l'utilisation d'un cluster.

Vous devez installer Policy Controller dans votre cluster GKE. Le plan inclut des exemples de règles permettant de sécuriser votre cluster. Vous appliquez automatiquement les règles à votre cluster à l'aide de Config Sync. Vous appliquez les règles suivantes :

Anthos Service Mesh

Gérer les communications sécurisées entre les services

Anthos Service Mesh vous permet de surveiller et de gérer un maillage de services basé sur Istio. Un maillage de services est une couche d'infrastructure qui permet de créer une communication gérée, observable et sécurisée sur l'ensemble de vos services.

Anthos Service Mesh simplifie la gestion des communications sécurisées entre les services de différentes manières :

  • Il gère l'authentification et le chiffrement du trafic (protocoles compatibles au sein du cluster à l'aide de la communication mutuelle par couche de transport (mTLS)). Anthos Service Mesh gère le provisionnement et la rotation des clés et des certificats mTLS pour les charges de travail Anthos sans perturber les communications. La rotation régulière des clés mTLS est une bonne pratique de sécurité qui permet de réduire l'exposition en cas d'attaque.
  • Il vous permet de configurer des règles de sécurité réseau basées sur l'identité du service plutôt que sur l'adresse IP d'un pair sur le réseau. Anthos Service Mesh sert à configurer des règles de contrôle d'accès (pare-feu) basées sur l'identité, qui vous permettent de créer des règles indépendantes de l'emplacement réseau de la charge de travail. Cette approche simplifie le processus de configuration des règles de communication de service à service.
  • Elle vous permet de configurer des règles autorisant l'accès à partir de certains clients.

Le plan vous guide pour installer Anthos Service Mesh dans votre cluster. Vous configurez l'espace de noms du locataire pour l'injection automatique du proxy side-car. Cette approche garantit que les applications de l'espace de noms du locataire font partie du réseau maillé. Vous configurez automatiquement Anthos Service Mesh à l'aide de Config Sync. Vous configurez le réseau maillé pour qu'il effectue les opérations suivantes :

  • Appliquer la communication mTLS entre les services du réseau maillé.
  • Limitez le trafic sortant du maillage aux hôtes connus uniquement.
  • Limiter la communication autorisée entre les services du réseau maillé. Par exemple, les applications de l'espace de noms du locataire ne sont autorisées à communiquer qu'avec les applications du même espace de noms, ou avec un ensemble d'hôtes externes connus.
  • Acheminer tout le trafic sortant via une passerelle de réseau maillé où vous pouvez appliquer d'autres contrôles du trafic.

Rejets et affinités de nœuds

Contrôler la planification des charges de travail

Les rejets de nœuds et l'affinité de nœud sont des mécanismes de Kubernetes qui vous permettent d'influencer la planification des pods sur les nœuds de cluster.

Les nœuds rejetés suppriment les pods. Kubernetes ne programme pas un pod sur un nœud rejeté, sauf si celui-ci dispose d'une tolérance pour ce rejet. Vous pouvez utiliser des rejets de nœuds pour réserver l'utilisation des nœuds à certaines charges de travail ou locataires. Les rejets et les tolérances sont souvent utilisés dans les clusters mutualisés. Pour en savoir plus, consultez la documentation sur les nœuds dédiés avec rejets et tolérances.

L'affinité de nœuds vous permet de limiter les pods aux nœuds portant des libellés spécifiques. Si un pod a une exigence d'affinité de nœud, Kubernetes ne le planifie pas, sauf si le nœud possède un libellé qui correspond à cette affinité. Vous pouvez utiliser l'affinité de nœuds pour vous assurer que les pods sont programmés sur les nœuds appropriés.

Vous pouvez utiliser des rejets de nœuds et l'affinité de nœuds ensemble pour vous assurer que les pods de charge de travail locataires sont exclusivement programmés sur des nœuds réservés au locataire.

Le plan permet de contrôler la planification des applications locataires de différentes manières :

  • Créer un pool de nœuds GKE dédié au locataire. Chaque nœud du pool possède un rejet associé au nom du locataire.
  • Application automatique de la tolérance et de l'affinité de nœuds appropriées à tout pod ciblant l'espace de noms du locataire. Vous appliquez la tolérance et l'affinité à l'aide des mutations PolicyContrôller.

Moindre privilège

Limiter l'accès aux ressources de cluster et de projet

Une bonne pratique de sécurité consiste à adopter un principe de moindre privilège pour vos projets et ressources Google Cloud tels que les clusters GKE. Ainsi, les applications qui s'exécutent dans votre cluster, ainsi que les développeurs et les opérateurs qui l'utilisent, ne disposent que de l'ensemble minimal d'autorisations requis.

Le plan vous aide à utiliser des comptes de service de moindre privilège de différentes manières:

  • Chaque pool de nœuds GKE reçoit son propre compte de service. Par exemple, les nœuds du pool de nœuds locataires utilisent un compte de service dédié à ces nœuds. Les comptes de service de nœud sont configurés avec les autorisations minimales requises.
  • Le cluster utilise Workload Identity pour associer les comptes de service Kubernetes aux comptes de service Google. De cette manière, les applications locataires peuvent disposer d'un accès limité à toutes les API Google requises sans télécharger ni stocker de clé de compte de service. Par exemple, vous pouvez autoriser le compte de service à lire les données d'un bucket Cloud Storage.

Le plan permet de restreindre l'accès aux ressources du cluster des manières suivantes :

  • Vous créez un exemple de rôle Kubernetes RBAC doté d'autorisations limitées pour gérer les applications. Vous pouvez attribuer ce rôle aux utilisateurs et aux groupes qui gèrent les applications dans l'espace de noms du locataire. De cette façon, ces utilisateurs ne disposent que des autorisations nécessaires pour modifier les ressources d'application dans l'espace de noms du locataire. Ils ne disposent pas des autorisations nécessaires pour modifier les ressources au niveau du cluster ou les paramètres de sécurité sensibles tels que les règles Anthos Service Mesh.

Conclusion

To implement the architecture described in this document, do the following:

  1. Déterminez si vous allez déployer le plan avec le plan de sécurité de base ou seul. Si vous choisissez de ne pas déployer le plan de sécurité de base, assurez-vous que votre environnement dispose d'une référence de sécurité similaire.
  2. Consultez le fichier README du plan et assurez-vous que vous remplissez toutes les conditions requises.
  3. Déployez une instance de cette architecture dans votre environnement de test. Dans le cadre de votre processus de test, procédez comme suit :
    1. Déployez un exemple de service locataire et vérifiez la configuration du cluster.
    2. Ajoutez un autre locataire au cluster.
  4. Déployez le plan dans votre environnement de production.
  5. Ajoutez plus de locataires au cluster.

Étape suivante