Contrôler la communication à l'échelle du cluster à l'aide de règles de réseau

Cette page explique comment configurer des règles de réseau à l'échelle du cluster pour Google Kubernetes Engine (GKE).

Les règles de réseau et les règles de réseau FQDN vous aident à définir des règles de trafic de communication entre les pods. Les règles de réseau contrôlent la manière dont les pods communiquent entre eux au sein de leurs applications et avec les points de terminaison externes.

En tant qu'administrateur de cluster, vous pouvez configurer des règles de réseau à l'échelle du cluster Cilium (CCNP) qui dépassent les limites des règles de réseau pour la gestion du trafic administrateur à l'échelle du cluster. Les règles de réseau à l'échelle du cluster Cilium appliquent des règles de réseau strictes pour toutes les charges de travail de l'ensemble du cluster, dans tous les espaces de noms, ignorant ainsi les règles spécifiques à l'application.

La règle de réseau à l'échelle du cluster Cilium pour GKE est une définition de ressource personnalisée (CRD) à l'échelle d'un cluster qui spécifie les règles appliquées par GKE. En activant la règle de réseau à l'échelle du cluster Cilium dans GKE, vous pouvez gérer les règles de réseau de manière centralisée pour l'ensemble de votre cluster. Vous pouvez contrôler l'accès de couche 3 (niveau IP) et de couche 4 (niveau du port) de base pour le trafic entrant et sortant du cluster.

Avantages

Grâce à la règle de réseau à l'échelle du cluster Cilium, vous pouvez :

• Appliquer la sécurité centralisée : avec CCNP, vous pouvez définir des règles d'accès au réseau qui s'appliquent à l'ensemble de votre réseau. Ces règles CCNP agissent en tant que couche de sécurité de premier niveau, en remplaçant les règles potentiellement conflictuelles au niveau de l'espace de noms.
• Protégez l'architecture mutualisée : si votre cluster héberge plusieurs équipes ou locataires, vous pouvez sécuriser l'isolation au sein d'un cluster partagé en mettant en œuvre des règles CCNP, axées sur le contrôle du trafic réseau. Vous pouvez appliquer une séparation au niveau du réseau en attribuant des espaces de noms ou des groupes d'espaces de noms à des équipes spécifiques.
• Définir des règles par défaut flexibles : avec CCNP, vous pouvez définir des règles de réseau par défaut pour l'ensemble du cluster. Vous pouvez personnaliser ces règles si nécessaire sans compromettre la sécurité globale de votre cluster.

Pour mettre en œuvre CCNP, activez GKE Dataplane V2 sur votre cluster. Assurez-vous que l'objet CRD CCNP est activé, puis créez des règles qui définissent les règles d'accès au réseau de votre cluster.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

• Activez l'API Google Kubernetes Engine.
Activer l'API Google Kubernetes Engine
• Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande gcloud components update.

Conditions requises

Les règles de réseau à l'échelle du cluster Cilium présentent les exigences suivantes :

• Google Cloud CLI version 465.0.0 ou ultérieure.
• Un cluster GKE doit exécuter l'une des versions suivantes :
  • 1.28.6-gke.1095000 ou versions ultérieures
  • 1.29.1-gke.1016000 ou versions ultérieures
• Votre cluster doit utiliser GKE Dataplane V2.
• Vous devez activer l'objet CRD de règle de réseau à l'échelle du cluster Cilium.

Limites

Les règles de réseau à l'échelle du cluster Cilium présentent les limites suivantes :

• Les règles de couche 7 ne sont pas compatibles.
• Les sélecteurs de nœuds ne sont pas compatibles.
• Le nombre maximal de CiliumClusterwideNetworkPolicy par cluster est de 1 000.

Activer la règle de réseau à l'échelle du cluster Cilium dans un nouveau cluster

Vous pouvez activer la règle de réseau à l'échelle du cluster Cilium dans un nouveau cluster à l'aide de Google Cloud CLI ou de l'API Google Kubernetes Engine.

gcloud container clusters create-auto CLUSTER_NAME \
    --location COMPUTE_LOCATION \
    --enable-cilium-clusterwide-network-policy

gcloud container clusters create CLUSTER_NAME \
    --location COMPUTE_LOCATION \
    --enable-cilium-clusterwide-network-policy \
    --enable-dataplane-v2

{
  "cluster": {
    ...
    "networkConfig": {
      "datapathProvider": "ADVANCED_DATAPATH",
      "enableCiliumClusterwideNetworkPolicy": true
    }
  }
}

Vérifiez que ciliumclusterwidenetworkpolicies.cilium.io est présent dans le résultat de la commande suivante :

kubectl get crds ciliumclusterwidenetworkpolicies.cilium.io

La sortie devrait ressembler à ce qui suit :

ciliumclusterwidenetworkpolicies.cilium.io     2023-09-19T16:54:48Z

Activer la règle de réseau à l'échelle du cluster Cilium dans un cluster existant

Vous pouvez activer la règle de réseau à l'échelle du cluster Cilium dans un cluster existant à l'aide de Google Cloud CLI ou de l'API Google Kubernetes Engine.

{
  "update": {
    "desiredEnableCiliumClusterwideNetworkPolicy": true
  },
  "name": "cluster"
}
To update an existing cluster, run the following update cluster command:
{
  "update": {
    "desiredEnableCiliumClusterwideNetworkPolicy": true
  }
  "name": "cluster"
}

Vérifiez que ciliumclusterwidenetworkpolicies.cilium.io est présent dans le résultat de la commande suivante :

kubectl get crds ciliumclusterwidenetworkpolicies.cilium.io

La sortie devrait ressembler à ce qui suit :

ciliumclusterwidenetworkpolicies.cilium.io     2023-09-19T16:54:48Z

Utiliser la règle de réseau à l'échelle du cluster Cilium

Cette section répertorie des exemples de configuration de règle de réseau à l'échelle du cluster Cilium.

Exemple 1 : Contrôler le trafic entrant vers une charge de travail

L'exemple suivant permet à tous les points de terminaison portant le libellé role=backend d'accepter les connexions d'entrée sur le port 80 à partir des points de terminaison portant le libellé role=frontend. Les points de terminaison portant le libellé role=backend rejettent toutes les connexions d'entrée non autorisées par cette règle.

1. Enregistrez le manifeste suivant sous le nom l4-rule-ingress.yaml :

   apiVersion: "cilium.io/v2"
   kind: CiliumClusterwideNetworkPolicy
   metadata:
     name: "l4-rule-ingress"
   spec:
     endpointSelector:
       matchLabels:
         role: backend
     ingress:
       - fromEndpoints:
           - matchLabels:
               role: frontend
         toPorts:
           - ports:
               - port: "80"
                 protocol: TCP
   

2. Appliquez le fichier manifeste :

   kubectl apply -f l4-rule-ingress.yaml
   

Exemple 2 : Limiter le trafic sortant d'une charge de travail sur un port donné

La règle suivante limite tous les points de terminaison portant l'étiquette app=myService de sorte qu'ils ne puissent émettre que des paquets via TCP sur le port 80, vers n'importe quelle destination de couche 3 :

1. Enregistrez le manifeste suivant sous le nom l4-rule-egress.yaml :

   apiVersion: "cilium.io/v2"
   kind: CiliumClusterwideNetworkPolicy
   metadata:
     name: "l4-rule-egress"
   spec:
     endpointSelector:
       matchLabels:
         app: myService
     egress:
       - toPorts:
           - ports:
               - port: "80"
                 protocol: TCP
   

2. Appliquez le fichier manifeste :

   kubectl apply -f l4-rule-egress.yaml
   

Exemple 3 : Limiter le trafic sortant d'une charge de travail sur un port et un CIDR donnés

L'exemple suivant limite tous les points de terminaison portant l'étiquette role=crawler de sorte qu'ils ne puissent envoyer des paquets que sur le port 80, protocoles TCP, à un CIDR de destination 192.10.2.0/24.

1. Enregistrez le manifeste suivant sous le nom cidr-l4-rule.yaml :

    apiVersion: "cilium.io/v2"
    kind: CiliumClusterwideNetworkPolicy
    metadata:
      name: "cidr-l4-rule"
    spec:
      endpointSelector:
        matchLabels:
          role: crawler
      egress:
        - toCIDR:
            - 192.0.2.0/24
          toPorts:
            - ports:
                - port: "80"
                  protocol: TCP
   

2. Appliquez le fichier manifeste :

   kubectl apply -f cidr-l4-rule.yaml
   

Surveiller et dépanner le trafic réseau

Vous pouvez surveiller et dépanner le trafic réseau affecté par les règles de réseau à l'échelle du cluster Cilium avec la journalisation des règles de réseau et l'observabilité de GKE Dataplane V2.

Tentative d'utilisation de règles de couche 7 ou de sélecteurs de nœuds

Symptôme

Si vous utilisez GKE avec GKE Dataplane V2 et que vous essayez de définir des règles CCNP qui incluent des règles de couche 7 (par exemple : filtrage HTTP) et des sélecteurs de nœuds, un message d'erreur semblable à celui-ci peut s'afficher :

Erreur

Error from server (GKE Warden constraints violations): error when creating
"ccnp.yaml": admission webhook
"warden-validating.common-webhooks.networking.gke.io" denied the request: GKE
Warden rejected the request because it violates one or more constraints.
Violations details: {"[denied by gke-cilium-network-policy-limitation]":["L7
rules are not allowed in CiliumClusterwideNetworkPolicy"]} Requested by user:
'[email protected]', groups: 'system:authenticated'.

Cause potentielle

GKE impose des limites spécifiques sur les CCNP. Les règles de couche 7, qui permettent un filtrage en fonction des données au niveau de l'application (telles que les en-têtes HTTP), et les sélecteurs de nœuds ne sont pas compatibles avec l'intégration Cilium de GKE.

Solution

Si vous avez besoin de fonctionnalités avancées de filtrage de couche 7 dans votre cluster GKE, envisagez d'utiliser Anthos Service Mesh. Cette solution offre un contrôle du trafic plus précis au niveau de l'application.

La règle de réseau à l'échelle du cluster Cilium n'est pas activée

Symptôme

Lorsque vous essayez de configurer des règles de réseau à l'échelle du cluster Cilium (CCNP) dans un cluster où la fonctionnalité n'a pas été explicitement activée, vous ne pouvez pas la configurer et un message d'erreur semblable à celui-ci peut s'afficher :

Erreur

error: resource mapping not found for name: "l4-rule" namespace: "" from
"ccnp.yaml": no matches for kind "CiliumClusterwideNetworkPolicy" in version
"cilium.io/v2" ensure CRDs are installed first

Cause potentielle

Les règles de réseau à l'échelle du cluster Cilium reposent sur une définition de ressource personnalisée (CRD). Le message d'erreur indique que l'objet CRD est manquant dans le cluster.

Solution

Activez l'objet CRD de règle de réseau à l'échelle du cluster Cilium avant d'utiliser des CCNP.

Étapes suivantes

• Lisez la documentation Kubernetes sur les règles de réseau

• Consultez CiliumClusterwideNetworkPolicy

• Configurer des règles de réseau pour les applications