Configurer des règles de réseau de cluster

ClusterNetworkPolicy vous permet de définir des stratégies de sécurité GKE globales pour l'ensemble du cluster. Ce document est destiné aux administrateurs de cluster qui doivent appliquer des garde-fous de sécurité obligatoires ou établir des bases de référence Zero Trust.

Cette ressource repose sur une hiérarchie d'évaluation stricte qui fonctionne avec une priorité plus élevée que les ressources NetworkPolicy standards à portée d'espace de noms. Vous pouvez utiliser la ressource ClusterNetworkPolicy pour implémenter des actions explicites Deny, Accept ou Pass. Ces actions vous permettent de configurer des règles d'autorisation ou de refus globales, de déléguer le contrôle du trafic à des espaces de noms spécifiques et de limiter le trafic de sortie à des blocs CIDR.

Avant de commencer

Avant de configurer une règle de réseau de cluster, assurez-vous de remplir les conditions suivantes :

  1. Assurez-vous que votre cluster GKE exécute la version 1.36.0-gke.4447000 ou ultérieure.
  2. Assurez-vous que votre cluster utilise GKE Dataplane V2.

Protocoles et ports compatibles

Les règles ClusterNetworkPolicy peuvent faire correspondre le trafic en fonction des protocoles TCP, UDP ou SCTP. Vous pouvez spécifier les ports de destination de différentes manières :

  • Numéro de port spécifique : utilisez le paramètre destinationPort.number pour cibler un seul port (par exemple, 80).
  • Plage de ports : utilisez le paramètre destinationPort.range pour cibler une plage de ports (par exemple, de 8000 à 9000).
  • Port nommé : utilisez le paramètre destinationNamedPort pour cibler un nom symbolique défini dans une spécification de pod.

Hiérarchie d'évaluation des règles

Contrairement aux NetworkPolicies standards et additifs, une ClusterNetworkPolicy (CNP) repose sur une hiérarchie d'évaluation stricte où la première règle correspondante est appliquée. Le trafic transite de manière séquentielle par un pipeline à trois couches :

  • Le niveau : les règles d'administration s'exécutent en premier, puis les règles NetworkPolicy, puis les règles de référence.
  • Priorité de la stratégie de réseau de cluster : au sein d'un niveau, les stratégies sont évaluées en fonction de leur priorité numérique explicite.
  • Ordre des règles CNP : dans une même règle, les règles sont traitées de haut en bas, comme une liste de contrôle des accès (LCA).

Diagramme illustrant la hiérarchie d'évaluation des règles de réseau GKE

Le schéma précédent illustre le flux de décision de la hiérarchie d'évaluation du CNP :

  1. Niveau Administrateur : le trafic est d'abord évalué par rapport aux règles ClusterNetworkPolicy du niveau Admin. Si une correspondance "Autoriser" ou "Refuser" est trouvée, l'évaluation s'arrête. S'il n'y a aucune correspondance ou si l'action est "Pass", le trafic est envoyé au niveau NetworkPolicy.
  2. Niveau NetworkPolicy : le trafic est évalué par rapport aux règles d'espace de noms standards. En cas de correspondance, le trafic est autorisé. Si aucune correspondance n'est trouvée, le trafic est acheminé vers le niveau de base.
  3. Niveau de référence : le trafic est évalué par rapport aux règles ClusterNetworkPolicy du niveau de référence. Si une correspondance "Autoriser" ou "Refuser" est trouvée, l'évaluation s'arrête. Si aucune correspondance n'est trouvée, le trafic suit le comportement par défaut.
  4. Comportement GKE par défaut : si aucune règle ne correspond à un niveau, le trafic est soumis à un comportement d'autorisation implicite.

Actions de verdict : autoriser, refuser et transmettre

Lorsqu'un paquet correspond à une règle, celle-ci déclenche l'une des trois actions strictes suivantes :

  • Refuser : bloque immédiatement le trafic.
  • Accepter : autorise le trafic. Ces deux actions court-circuitent instantanément le pipeline, qui ignore toutes les règles restantes.
  • Pass : transfère le contrôle au niveau inférieur, ce qui permet aux ingénieurs de plate-forme de déléguer des décisions de trafic spécifiques à des règles standards au niveau de l'espace de noms sans renoncer au contrôle administratif global.

Configurer une règle de refus globale

Pour isoler un espace de noms sensible de tout autre trafic interne au cluster, appliquez une règle de refus non modifiable. Cette règle de refus par défaut permet de s'assurer que tout trafic vers ou depuis l'espace de noms sensible est bloqué au niveau administratif. Cette règle sert de référence de protection qui ne peut pas être contournée accidentellement par des règles au niveau de l'espace de noms.

  1. Enregistrez le manifeste suivant sous le nom global-deny.yaml :

    apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: cluster-wide-deny-sensitive
spec:
  tier: Admin
  priority: 10
  subject:
    namespaces:
      matchLabels:
        kubernetes.io/metadata.name: sensitive-ns
  ingress:
  - action: Deny
    name: deny-all-ingress
    from:
    - namespaces:
        matchLabels: {}
  egress:
  - action: Deny
    name: deny-all-egress
    to:
    - namespaces:
        matchLabels: {}

  2. Appliquez le fichier manifeste à votre cluster :

    kubectl apply -f global-deny.yaml

Configurer une stratégie d'autorisation globale

Une stratégie d'autorisation globale peut permettre de s'assurer que tous les pods peuvent accéder au service DNS du cluster, quelles que soient les stratégies réseau créées par les développeurs.

  1. Enregistrez le manifeste suivant sous le nom global-allow-dns.yaml :

    apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: allow-kube-dns-admin
spec:
  tier: Admin
  priority: 20
  subject:
    namespaces: {}
  egress:
  - action: Accept
    name: allow-dns-egress
    to:
    - pods:
        namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: kube-system
        podSelector:
          matchLabels:
            k8s-app: kube-dns
    protocols:
    - udp:
        destinationPort:
          number: 53
    - tcp:
        destinationPort:
          number: 53

  2. Appliquez le fichier manifeste à votre cluster :

    kubectl apply -f global-allow-dns.yaml

Déléguer le trafic aux règles d'espace de noms

Déléguez des modèles de trafic spécifiques à des objets NetworkPolicy standards à portée d'espace de noms.

  1. Enregistrez le manifeste suivant sous le nom delegate-policy.yaml :

    apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: delegate-to-netpol
spec:
  tier: Admin
  priority: 30
  subject:
    namespaces: {}
  egress:
  - action: Pass
    name: delegate-web-traffic
    to:
    - namespaces:
        matchLabels:
          app: web-backend
    protocols:
    - tcp:
        destinationPort:
          number: 8080

  2. Appliquez le fichier manifeste à votre cluster :

    kubectl apply -f delegate-policy.yaml

  3. Pour autoriser le trafic délégué dans l'espace de noms cible, enregistrez le fichier manifeste NetworkPolicy standard suivant sous le nom allow-web-backend.yaml :

    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-backend
  namespace: backend-ns
spec:
  podSelector:
    matchLabels:
      app: web-backend
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          app: web-frontend
    ports:
    - protocol: TCP
      port: 8080

  4. Appliquez le fichier manifeste NetworkPolicy standard à votre cluster :

    kubectl apply -f allow-web-backend.yaml

Configurer des garde-fous de référence

Établissez une stratégie de sécurité GKE par défaut que les administrateurs d'espaces de noms peuvent remplacer à l'aide de règles de réseau standards.

  1. Enregistrez le fichier manifeste de référence suivant sous le nom baseline-deny.yaml :

    apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: default-deny-baseline
spec:
  tier: Baseline
  priority: 100
  subject:
    namespaces: {}
  ingress:
  - action: Deny
    name: baseline-deny-all
    from:
    - namespaces: {}

  2. Appliquez le fichier manifeste de référence à votre cluster :

    kubectl apply -f baseline-deny.yaml

  3. Enregistrez le fichier manifeste de remplacement du développeur suivant sous le nom developer-allow.yaml :

    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-access
  namespace: my-app-ns
spec:
  podSelector:
    matchLabels:
      app: frontend
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: ingress-nginx

  4. Appliquez le fichier manifeste de remplacement à votre cluster :

    kubectl apply -f developer-allow.yaml

Configurer des règles à l'aide de ports nommés

Pour extraire les numéros de port de vos stratégies de sécurité, référencez les ports nommés définis dans vos spécifications de pod.

  1. Enregistrez le fichier manifeste de déploiement suivant sous le nom app-deployment.yaml :

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-webapp
spec:
  template:
    spec:
      containers:
      - name: web-container
        image: nginx
        ports:
        - name: http-web
          containerPort: 8080

  2. Appliquez le fichier manifeste de déploiement à votre cluster :

    kubectl apply -f app-deployment.yaml

  3. Enregistrez le fichier manifeste de stratégie suivant sous le nom named-port-policy.yaml :

    apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: allow-web-named-port
spec:
  tier: Admin
  priority: 40
  subject:
    namespaces: {}
  egress:
  - action: Accept
    to:
    - namespaces:
        matchLabels:
          app: my-webapp
    protocols:
    - tcp:
        destinationNamedPort: http-web

  4. Appliquez le fichier manifeste de la règle à votre cluster :

    kubectl apply -f named-port-policy.yaml

Limiter la sortie aux blocs CIDR

Contrôlez l'accès aux ressources externes ou aux intranets d'entreprise en spécifiant des blocs CIDR.

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

    apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: allow-egress-to-intranet
spec:
  tier: Admin
  priority: 60
  subject:
    namespaces: {}
  egress:
  - action: Accept
    name: allow-intranet
    to:
    - networks:
      - 10.0.0.0/8
      - 192.168.0.0/16

  2. Appliquez le fichier manifeste à votre cluster :

    kubectl apply -f cidr-policy.yaml

Configurer la priorité

Pour contrôler l'ordre d'évaluation lorsque plusieurs règles s'appliquent aux mêmes pods, spécifiez une priorité. Les priorités sont comprises entre 0 et 1 000. Plus le nombre est faible, plus la priorité est élevée. Un seul objet ClusterNetworkPolicy peut contenir au maximum 100 règles d'entrée et 100 règles de sortie.

  1. Enregistrez le manifeste suivant sous le nom priority-policies.yaml :

    apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: deny-beta
spec:
  tier: Admin
  priority: 10
  subject:
    namespaces:
      matchLabels:
        team: alpha
  ingress:
  - action: Accept
    name: allow-beta-monitoring
    from:
    - pods:
        namespaceSelector:
          matchLabels:
            team: beta
        podSelector:
          matchLabels:
            app: monitoring
  - action: Deny
    name: deny-all-other-ingress-from-beta
    from:
    - namespaces:
        matchLabels:
          team: beta
---
apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: allow-beta
spec:
  tier: Admin
  priority: 50
  subject:
    namespaces:
      matchLabels:
        team: alpha
  ingress:
  - action: Accept
    name: allow-all-ingress-from-beta
    from:
    - namespaces:
        matchLabels:
          team: beta

  2. Appliquez le fichier manifeste à votre cluster :

    kubectl apply -f priority-policies.yaml

Résoudre les problèmes

Pour trouver des méthodes de diagnostic et de résolution des erreurs liées aux règles, utilisez les commandes suivantes.

Répertoriez toutes les règles de réseau de cluster dans votre cluster :

kubectl get clusternetworkpolicies

Décrivez une stratégie spécifique pour inspecter son état et son niveau d'évaluation :

kubectl describe clusternetworkpolicy/<policy-name>

Le champ status.conditions de la sortie indique si la stratégie a été réconciliée par l'implémentation réseau de votre cluster.

Pour surveiller les flux de trafic et les décisions liées aux règles, utilisez l'observabilité GKE Dataplane V2.

Étapes suivantes