Sélectionner les Pods via les Labels

Le rôle central des Labels et Selectors

Comme pour de nombreux autres objets dans Kubernetes, les Labels et les Selectors jouent un rôle absolument fondamental dans le fonctionnement des Network Policies. Ils sont le mécanisme principal par lequel vous spécifiez quels Pods sont soumis à une politique donnée et quelles sont les sources ou destinations autorisées pour le trafic réseau.

Sans un système de Labels cohérent et bien pensé sur vos Pods et Namespaces, il devient très difficile, voire impossible, de définir des Network Policies efficaces et granulaires. Les Labels fournissent les 'poignées' nécessaires pour regrouper logiquement les Pods et appliquer des règles de communication spécifiques à ces groupes.

Dans le contexte des Network Policies, les sélecteurs basés sur les labels sont utilisés à trois endroits principaux : pour cibler les Pods auxquels la politique s'applique (`spec.podSelector`), et pour définir les sources (`ingress.from`) et les destinations (`egress.to`) du trafic autorisé.

Cibler les Pods avec `spec.podSelector`

Le champ `spec.podSelector` au niveau supérieur de la définition d'une `NetworkPolicy` détermine quels Pods, au sein du namespace où la politique est créée, seront affectés par les règles `ingress` et `egress` définies dans cette politique. Ce sélecteur fonctionne exactement comme les sélecteurs que vous utilisez pour les Services ou les Deployments.

Par exemple, pour appliquer une politique à tous les Pods ayant le label `app=api`:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes: [Ingress, Egress]
  # ... règles ingress et egress ici ...

Si `spec.podSelector` est omis ou laissé vide (podSelector: {}), la politique s'applique à tous les Pods dans le namespace. C'est souvent utilisé pour établir une politique d'isolation par défaut (tout refuser) pour l'ensemble du namespace, avant d'ajouter d'autres politiques plus spécifiques pour autoriser certains flux.

Identifier les sources et destinations avec les sélecteurs

Au sein des règles `ingress.from` et `egress.to`, vous utilisez également des sélecteurs pour spécifier les Pods ou les Namespaces avec lesquels les Pods ciblés par la politique sont autorisés à communiquer.

• podSelector : Utilisé dans from ou to, il sélectionne des Pods (sources ou destinations) dans le même namespace que la Network Policy, en fonction de leurs labels. Par exemple, podSelector: { matchLabels: { role: frontend } } autorise le trafic depuis/vers les Pods ayant le label `role=frontend` dans le namespace actuel.
• namespaceSelector : Permet de sélectionner des Pods dans d'autres namespaces. Il sélectionne d'abord les namespaces en fonction de leurs propres labels, puis, par défaut, autorise le trafic depuis/vers tous les Pods de ces namespaces sélectionnés. Par exemple, namespaceSelector: { matchLabels: { project: monitoring } } autorise le trafic depuis/vers tous les Pods des namespaces ayant le label `project=monitoring`.
• Combinaison namespaceSelector et podSelector : Vous pouvez combiner les deux pour une granularité accrue. Cela sélectionne des Pods spécifiques (via podSelector) uniquement au sein des namespaces qui correspondent au namespaceSelector. C'est la méthode standard pour autoriser le trafic entre des Pods spécifiques situés dans des namespaces différents.

Exemple autorisant le trafic entrant depuis les Pods 'frontend' du même namespace et depuis n'importe quel Pod du namespace 'monitoring' :

# ... spec ...
  ingress:
  - from:
    - podSelector: # Pods dans le même namespace
        matchLabels:
          role: frontend
    - namespaceSelector: # Tous les Pods dans les namespaces correspondants
        matchLabels:
          purpose: monitoring
# ... ports ...

Exemple autorisant le trafic sortant vers les Pods 'database' dans le namespace 'data-services' (en supposant que le namespace 'data-services' a le label `name=data-services`) :

# ... spec ...
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          name: data-services
      podSelector:
        matchLabels:
          app: database
# ... ports ...

Comme pour `spec.podSelector`, un sélecteur vide (`podSelector: {}` ou `namespaceSelector: {}`) dans une clause `from` ou `to` correspond à tous les Pods ou tous les Namespaces, respectivement. Attention, `podSelector: {}` dans une règle `from` ou `to` ne sélectionne que les Pods du namespace de la politique, sauf s'il est combiné avec un `namespaceSelector`.

L'importance d'une stratégie de labellisation

L'efficacité de vos Network Policies dépend directement de la qualité et de la cohérence de votre stratégie de labellisation. Des labels clairs et descriptifs appliqués aux Pods (via leurs Deployments, StatefulSets, etc.) et aux Namespaces sont essentiels.

Pensez à utiliser des labels pour indiquer le rôle de l'application (`app=frontend`, `role=backend`), l'environnement (`env=production`, `env=staging`), le niveau de sensibilité (`tier=internal`, `tier=dmz`), ou tout autre critère pertinent pour définir vos frontières de sécurité réseau.

Une bonne pratique consiste à documenter votre stratégie de labellisation et à l'appliquer de manière cohérente à travers tous vos déploiements. Cela simplifiera grandement la création et la maintenance de vos Network Policies à mesure que votre environnement Kubernetes évolue.