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

Pour activer la règle de réseau à l'échelle du cluster Cilium dans un nouveau cluster, créez un cluster avec l'option --enable-cilium-clusterwide-network-policy.

Autopilot

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

Remplacez les éléments suivants :

  • CLUSTER_NAME par le nom de votre cluster.
  • COMPUTE_LOCATION par l'emplacement de votre cluster.

Standard

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

Remplacez les éléments suivants :

  • CLUSTER_NAME par le nom de votre cluster.
  • COMPUTE_LOCATION par l'emplacement de votre cluster.

API

Pour activer la règle de réseau à l'échelle du cluster Cilium, vous devez spécifier les options suivantes lors de la création d'un cluster :

Champ datapathProvider dans l'objet networkConfig.

{
  "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.

gcloud

  1. Vérifiez que GKE Dataplane V2 est activé sur le cluster.

    gcloud container clusters describe CLUSTER_NAME \
        --location COMPUTE_LOCATION \
        --format="value(networkConfig.datapathProvider)" \
    

    Remplacez les éléments suivants :

    • CLUSTER_NAME par le nom de votre cluster.
    • COMPUTE_LOCATION par l'emplacement de votre cluster.
  2. Mettez à jour le cluster à l'aide de l'option --enable-cilium-clusterwide-network-policy.

    gcloud container clusters update CLUSTER_NAME \
        --location COMPUTE_LOCATION \
        --enable-cilium-clusterwide-network-policy
    
  3. Redémarrez le DaemonSet anetd.

    kubectl rollout restart ds -n kube-system anetd && \
        kubectl rollout status ds -n kube-system anetd
    

API

Vérifiez que le cluster est activé pour GKE Dataplane V2 :

{
  "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:
'user@example.com', 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