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 au niveau de l'espace de noms. Vous pouvez utiliser la ressource ClusterNetworkPolicy pour implémenter des actions Refuser, Accepter ou Transmettre explicites. 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 acceptés

Les règles ClusterNetworkPolicy peuvent faire correspondre le trafic en fonction des protocoles TCP, UDP ou SCTP. Vous pouvez spécifier des 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 cumulatives, 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 niveaux :

  • Niveau : les règles d'administrateur sont exécutées en premier, puis les règles NetworkPolicy et enfin les règles de base.
  • Priorité CNP : au sein d'un niveau, les règles sont évaluées en fonction de leur priorité numérique explicite.
  • Ordre des règles de PCN : 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).

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

Le diagramme précédent illustre le flux de décision de la hiérarchie d'évaluation des 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 "Validée", le trafic est envoyé au niveau NetworkPolicy.
  2. Niveau NetworkPolicy : le trafic est évalué par rapport aux règles standards de l'espace de noms. Si une correspondance est trouvée, le trafic est autorisé. Si aucune correspondance n'est trouvée, le trafic est acheminé vers le niveau de base.
  3. Niveau de base : le trafic est évalué par rapport aux règles ClusterNetworkPolicy du niveau de base. Si une correspondance "Autoriser" ou "Refuser" est trouvée, l'évaluation s'arrête. Si aucune correspondance n'est trouvée, le trafic est soumis au 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.
  • Transmettre : 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 règle d'autorisation globale peut permettre de s'assurer que tous les pods peuvent accéder au service DNS du cluster, quelles que soient les règles 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 schémas 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 posture 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 par le 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 abstraire les numéros de port de vos règles de sécurité, référencez les ports nommés définis dans les spécifications de vos pods.

  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 la règle 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 le trafic sortant 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 vont de 0 à 1 000, les nombres les plus bas indiquant la priorité la plus é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 règle 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 règle a été réconciliée par l'implémentation réseau de votre cluster.

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

Étapes suivantes