Contrôle du trafic entre les pods à l'aide de règles Kubernetes

Virtual Private Cloud

Vous pouvez utiliser des règles Kubernetes pour contrôler le trafic réseau entre les pods de votre cluster et pour isoler les uns des autres des microservices d'application au sein d'un espace de noms ou entre différents espaces de noms.

Niveau d'application : noeud final d'hôte de noeud worker

Comportement par défaut : par défaut, il n'existe aucune règle réseau Kubernetes dans votre cluster. Par défaut, un pod, quel qu'il soit, a accès à n'importe quel autre pod présent dans le cluster. En outre, un pod, quel qu'il soit, a accès à n'importe quel service qui est exposé par le réseau de pods, par exemple, un service de métriques, le DNS de cluster, le serveur d'API ou les services que vous créez manuellement dans votre cluster.

Cas d'utilisation : les règles de réseau Kubernetes spécifient de quelle façon les pods peuvent communiquer avec d'autres pods et avec des noeuds finaux externes. Le trafic réseau entrant et sortant peut être autorisé ou bloqué en fonction d'un protocole, d'un port et d'adresses IP source ou d'adresses IP de destination. Le trafic peut également être filtré en fonction des libellés de pod et d'espace de noms. Lorsque les règles Kubernetes sont appliquées, elles sont automatiquement converties en règles réseau Calico. Le plug-in réseau Calico dans votre cluster applique ces règles en configurant des règles Linux Iptables sur les noeuds worker. Les règles Iptables font office de pare-feu pour le noeud worker en définissant les caractéristiques que le trafic réseau doit respecter pour être acheminé vers la ressource ciblée.

Si la plupart ou tous les pods n'ont pas besoin d'accéder à des pods ou des services spécifiques et que vous voulez vous assurer que les pods par défaut ne peuvent pas accéder à ces pods ou services, vous pouvez créer une politique de réseau Kubernetes pour bloquer le trafic de sortie vers ces pods ou ces services. Par exemple, n'importe quel pod peut accéder aux noeuds finaux de métriques sur les pods CoreDNS. Pour bloquer les accès inutiles, vous pouvez appliquer une règle telle que celle décrite ci-après, qui autorise toutes les entrées vers le port TCP et UDP 53 afin de permettre aux pods d'accéder à la fonctionnalité CoreDNS. Toutefois, elle bloque toutes les autres entrées, telles que les tentatives de collecte de métriques à partir des pods CoreDNS, sauf à partir des pods ou des services présents dans les espaces de noms ayant le libellé coredns-metrics-policy: allow ou à partir des pods présents dans l'espace de noms kube-system ayant le libellé coredns-metrics-policy: allow.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: coredns-metrics
  namespace: kube-system
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          coredns-metrics-policy: allow
    - podSelector:
        matchLabels:
          coredns-metrics-policy: allow
  - ports:
    - port: 53
      protocol: TCP
    - port: 53
      protocol: UDP
  podSelector:
    matchLabels:
      k8s-app: kube-dns
  policyTypes:
  - Ingress

Pour plus d'informations sur la manière dont les stratégies réseau d' Kubernetes contrôlent le trafic entre les pods et pour obtenir d'autres exemples de stratégies, consultez la documentation d' Kubernetes.

Isolement des services d'application au sein d'un espace de noms

Le scénario suivant illustre comment gérer le trafic entre les microservices d'application au sein d'un espace de noms.

Une équipe nommée Accounts déploie plusieurs services d'application dans un espace de noms, mais ces services doivent être isolés pour n'autoriser que la communication nécessaire entre les microservices sur le réseau public. Pour l'application Srv1, l'équipe dispose de services de front end et de back end, et d'un service de base de données. Elle indique pour chaque service le libellé app: Srv1 et le libellé tier: frontend, tier: backend ou tier: db.

Utiliser une politique réseau pour gérer le trafic inter-espaces de noms. — Use a network policy to manage namespace traffic

L'équipe Accounts souhaite autoriser le trafic du service de front end vers le service de back end et du service de back end vers le service de base de données. Elle utilise des libellés dans les règles réseau pour désigner les flux de trafic autorisés entre les microservices.

L'équipe commence par créer une règle réseau Kubernetes autorisant le trafic à partir du service front end vers le service de back end :

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-allow
spec:
  podSelector:
    matchLabels:
      app: Srv1
      tier: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: Srv1
          Tier: frontend

La section spec.podSelector.matchLabels répertorie les libellés du service dorsal Srv1 de sorte que la règle ne s'applique qu'à Vers. La section spec.ingress.from.podSelector.matchLabels répertorie les libellés du service frontal Srv1 de sorte que l'entrée ne soit autorisée qu'à à partir de ces gousses.

Ensuite, l'équipe crée une règle Kubernetes similaire pour autoriser le trafic du service de back end vers la base de données :

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: db-allow
spec:
  podSelector:
    matchLabels:
      app: Srv1
      tier: db
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: Srv1
          Tier: backend

La section spec.podSelector.matchLabels répertorie les libellés du service de base de données Srv1 de sorte que la règle ne s'applique qu'à Vers. La section spec.ingress.from.podSelector.matchLabels répertorie les libellés du service dorsal Srv1 de sorte que l'entrée ne soit autorisée qu'à à partir de ces gousses.

Le trafic peut désormais circuler du service de front end vers le service de back end et du service de back end vers le service de base de données. La base de données peut répondre au service de back end et le service de back end peut répondre au service de front end, mais les connexions de trafic inverses ne peuvent pas être établies.

Isolement des services d'application entre les espaces de noms

Le scénario suivant illustre comment gérer le trafic entre les microservices d'application entre plusieurs espaces de noms.

Les services qui appartiennent à différentes sous-équipes doivent communiquer, mais les services sont déployés dans des espaces de noms différents au sein du même cluster. L'équipe Accounts déploie des services de front end, de back end et de base de données pour l'application app Srv1 dans l'espace de noms Accounts. L'équipe Finance déploie des services de front end, de back end et de base de données pour l'application app Srv2 dans l'espace de noms Finance. Ces deux équipes étiquettent chaque service avec le libellé app: Srv1 ou app: Srv2 et le libellé tier: frontend, tier: backend ou tier: db. Elles étiquettent également les espaces de noms avec le libellé usage: accounts ou usage: finance.

Le service Srv2 de l'équipe Finance doit demander des informations au service de back end Srv1 de l'équipe Accounts. Par conséquent, l'équipe Accounts crée une règle réseau Kubernetes utilisant des libellés pour autoriser tout le trafic en provenance de l'espace de noms Finance vers le service de back end Srv1 dans l'espace de noms Accounts. L'équipe indique également le port 3111 pour isoler l'accès uniquement via ce port.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  Namespace: accounts
  name: accounts-allow
spec:
  podSelector:
    matchLabels:
      app: Srv1
      Tier: backend
  ingress:
  - from:
    - NamespaceSelector:
        matchLabels:
          usage: finance
      ports:
        port: 3111

La section spec.podSelector.matchLabels répertorie les libellés du service dorsal Srv1 de sorte que la règle ne s'applique qu'à Vers. La section spec.ingress.from.NamespaceSelector.matchLabels répertorie le libellé de l'espace de nom financier de sorte que l'entrée n'autorise que les services à partir de dans cet espace de nom.

Le trafic peut désormais circuler des microservices Finance vers le service de back end Srv1. Le service de back end Srv1 de Accounts peut répondre aux microservices Finance, mais une connexion de trafic inverse n'est pas possible.

Dans cet exemple, l'ensemble du trafic en provenance de tous les microservices dans l'espace de noms Finance est autorisé. Vous ne pouvez pas autoriser le trafic en provenance de pods d'application spécifiques d'un autre espace de noms car les éléments podSelector et namespaceSelector ne peuvent pas être combinés.

Règles de politique requises pour les VPC avec un cluster qui s'exécute à la version 1.28 ou ultérieure

Dans les versions 1.27 et antérieures, les clusters VPC tirent des images du IBM Cloud Container Registry par l'intermédiaire d'un point d'extrémité de service de cloud privé pour le Container Registry. À partir de la version 1.28, ce chemin réseau est mis à jour de sorte que les images sont tirées par une passerelle VPE au lieu d'un point d'extrémité de service privé. Cette modification concerne tous les clusters d'un VPC ; lorsque vous créez ou mettez à jour un seul cluster d'un VPC vers la version 1.28, tous les clusters de ce VPC, quelle que soit leur version ou leur type, voient leur chemin d'accès au réseau mis à jour. Pour plus d'informations, voir Networking changes for VPC clusters.

Si vous disposez d'un cluster dans votre VPC qui exécute la version 1.28 ou ultérieure et que vous utilisez des règles Calico pour restreindre les connexions sortantes des agents de cluster, vous devez ajouter la règle de politique suivante pour autoriser les connexions à la passerelle VPE pour le registre. Cette règle doit être créée pour chaque zone du VPC et doit spécifier la plage de préfixes d'adresse VPC entière pour la zone en tant que CIDR de destination. Pour trouver la plage de préfixes d'adresse VPC pour chaque zone du VPC, exécutez ibmcloud is vpc-address-prefixes <vpc_name_or_id>.

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: allow-vpe-gateway-registry
spec:
  egress:
  - action: Allow
    destination:
      nets:
      - <entire-vpc-address-prefix-range> # example: 10.245.0.0/16
      ports:
      - 443
      - 4443
    protocol: TCP
    source: {}
  order: 500
  selector: ibm.role == 'worker_private'
  types:
  - Egress