Plan de sécurité Anthos : appliquer des restrictions de localité pour les clusters sur Google Cloud

Ce document explique comment gérer les ressources afin qu'elles ne soient disponibles que dans des régions spécifiques. Il décrit comment et pourquoi vous devez respecter les restrictions d'emplacement, ainsi que les contrôles Google Cloud à utiliser.

Ce document fait partie d'une série de plans de sécurité réunissant des conseils normatifs pour travailler avec Anthos. Pour plus d'informations sur ces plans, consultez la section Plans de sécurité Anthos : questions fréquentes.

Présentation

De nombreuses entreprises doivent répondre aux exigences de résidence spécifiques à leur emplacement. En d'autres termes, leurs services (et dans de nombreux cas, les clusters sur lesquels ils s'exécutent) ne doivent être déployés ou accessibles qu'à partir d'emplacements spécifiques. Différentes raisons peuvent justifier cela : les exigences réglementaires, les exigences de latence ou les exigences commerciales afin de ne proposer le service que dans certains pays.

Pour répondre aux exigences de résidence spécifiques à un emplacement, vous devez tenir compte des éléments suivants :

  • L'emplacement requis pour les services.
  • S'il vous faut restreindre ou non l'accès à vos services depuis des régions spécifiques.
  • Les services Google Cloud qui dépendent de vos services
  • Si vous utilisez GKE sur Google Cloud ou GKE On-Prem.
  • Les flux et les opérations autorisés qui se trouvent dans, depuis et vers votre application.

En tenant compte de ces problèmes, vous pouvez déterminer comment configurer chacun des contrôles de sécurité applicables pour répondre aux exigences de résidence spécifiques à l'emplacement.

Le contenu du répertoire enforcing-locality du dépôt GitHub associé à ce plan contient des instructions sur la configuration des contrôles de sécurité dont vous avez besoin pour répondre à vos exigences de restriction de localité.

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

Cette section décrit les contrôles permettant d'atteindre le niveau de restriction de localité qui répond à vos besoins.

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.

Règles d'administration

Restreindre les emplacements dans lesquels vous pouvez déployer vos clusters

Le service de règles d'administration permet de configurer des restrictions sur les ressources compatibles au sein de votre organisation Google. Vous configurez des contraintes sur les ressources compatibles.

Lorsque vous limitez des services à une localité, vous utilisez la contrainte de restriction d'emplacement des ressources. Cette contrainte définit l'ensemble des emplacements dans lesquels les ressources Google Cloud basées sur l'emplacement peuvent être créées. Les règles de cette contrainte peuvent spécifier différents emplacements autorisés ou refusés. Par exemple, elles peuvent spécifier des régions multiples telles que l'Asie et l'Europe, des régions telles que us-east1 ou europe-west1, ou des zones individuelles telles que europe-west1-b. Chaque emplacement à autoriser ou à refuser doit être explicitement répertorié.

Anthos Config Management

Appliquer des configurations à vos clusters Anthos

Une bonne pratique de gestion des clusters Anthos consiste à utiliser Anthos Config Management, qui synchronise les clusters enregistrés avec les configurations. Une configuration est un fichier YAML ou JSON stocké dans votre dépôt et contenant les mêmes types de détails de configuration que ceux que vous pouvez appliquer manuellement à un cluster à l'aide de la commande kubectl apply. Anthos Config Management vous permet de gérer vos règles et vos déploiements d'infrastructure de la même manière que vos applications : en adoptant une approche déclarative.

Vous utilisez Anthos Config Management conjointement avec un dépôt Git qui sert de source unique de vérité pour vos règles déclarées. Anthos Config Management peut gérer des règles de contrôle d'accès, telles que les règles RBAC, les quotas de ressources, les espaces de noms et les déploiements d'infrastructure au niveau de la plate-forme. Anthos Config Management est déclaratif. Il vérifie en permanence l'état du cluster et applique l'état déclaré dans la configuration afin d'appliquer les stratégies.

Réseaux autorisés pour l'accès au cluster maître

Restreindre les emplacements autorisés à accéder au serveur d'API Kubernetes

Les réseaux autorisés vous donnent la possibilité d'autoriser des plages CIDR spécifiques et permettent aux adresses IP de ces plages d'accéder au point de terminaison du maître du cluster à l'aide du protocole HTTPS. Les clusters privés n'exposent pas les adresses IP externes et exécutent éventuellement leur maître de cluster sans point de terminaison accessible publiquement.

Une bonne pratique consiste à suivre les instructions du guide de renforcement GKE, qui recommande d'utiliser des clusters privés en plus d'activer les réseaux autorisés.

Sélectionner un type de cluster

Pour comprendre le type de cluster adapté à votre cas d'utilisation, vous devez connaître les régions et zones, ainsi que les emplacements dans lesquels les ressources peuvent être déployées. Les régions correspondent à des espaces géographiques indépendants qui sont constitués de zones. Par exemple, Londres (europe-west2) est une région située en Europe et l'Oregon (us-west1) est une région d'Amérique.

Les zones servent au déploiement des ressources Google Cloud dans une région. Elles doivent être considérées comme un domaine de défaillance unique au sein d'une région. Pour déployer des applications tolérantes aux pannes et à haute disponibilité, vous pouvez déployer vos applications sur plusieurs zones d'une région.

Les emplacements au sein des régions présentent généralement des latences réseau aller-retour inférieures à un milliseconde au 95e centile. Voici un exemple d'emplacement : Tokyo, au Japon, qui comporte trois zones et se trouve dans la région asia-northeast1.

GKE propose trois types de clusters :

  • Cluster à zone unique. Un cluster à zone unique possède un seul plan de contrôle (maître) s'exécutant dans une zone. Ce plan de contrôle gère les charges de travail sur les nœuds exécutés dans la même zone.
  • Cluster multizone. Un cluster multizones comporte une seule instance dupliquée du plan de contrôle s'exécutant dans une seule zone et plusieurs nœuds s'exécutant dans plusieurs zones.
  • Cluster régional Les clusters régionaux répliquent les maîtres et les nœuds de cluster dans plusieurs zones d'une même région. Par exemple, un cluster régional dans la région us-east1 crée des instances dupliquées du plan de contrôle et des nœuds dans trois zones us-east1 : us-east1-b, us-east1-c et us-east1-d.

Vous devez sélectionner le cluster qui répond à vos besoins de disponibilité. Par exemple, si vous avez besoin que vos charges de travail aient une disponibilité élevée, utilisez un cluster régional.

Conclusion

Pour intégrer les contrôles, déterminez vos exigences de restriction de localité. Déterminez ensuite le champ d'application des contrôles décrits dans ce guide et l'étape à laquelle ils doivent être configurés, comme suit :

  1. Définissez vos exigences régionales.
  2. Identifiez l'emplacement approprié pour votre cluster.
  3. Créez une règle d'administration concernant l'emplacement des ressource pour limiter la création de vos clusters GKE aux emplacements répondant à vos besoins.
  4. Créez vos clusters privés en suivant les instructions du guide de renforcement du cluster GKE. Lors de la création de votre cluster, assurez-vous de suivre le guide de renforcement et d'utiliser l'option --enable-network-policy. Les règles de réseau sont obligatoires. Cette étape vous permet de mettre en œuvre ultérieurement des règles de pare-feu qui limitent le trafic circulant entre les pods d'un cluster.
  5. Ajoutez des réseaux autorisés à vos clusters privés.

Si vous souhaitez restreindre l'accès des clients à vos services, procédez comme suit :

  • Pour les clusters GKE sur Google Cloud, définissez une stratégie de sécurité de Google Cloud Armor pour appliquer le contrôle des accès en fonction de l'emplacement géographique du trafic entrant. Associez la stratégie de sécurité à chacun des backends liés à la ressource Ingress.
  • Définissez des stratégies limitant l'accès à vos clusters à l'aide d'Anthos Config Management.