Politiques réseau

L’opérateur gère les ressources Kubernetes NetworkPolicy à deux niveaux, tous deux désactivés par défaut :

Politiques de cluster — politiques propres à chaque cluster couvrant le trafic interne des ressources ClickHouseCluster et KeeperCluster, activées via spec.networkPolicy sur chaque ressource personnalisée.
Politiques de pod de l’opérateur — politiques fournies avec le chart qui restreignent le trafic entrant vers le pod du controller manager lui-même pour les points de terminaison des métriques et webhook.

Une NetworkPolicy n’est appliquée que lorsque le plugin CNI du cluster l’implémente (par exemple Calico ou Cilium). Sur un CNI sans prise en charge de NetworkPolicy, les ressources sont créées mais n’ont silencieusement aucun effet — Kubernetes ne renvoie aucune erreur. Vérifiez que votre CNI applique bien ces politiques avant de vous y fier.

NetworkPolicies du cluster

Activez la politique gérée pour chaque cluster :

apiVersion: clickhouse.com/v1alpha1
kind: ClickHouseCluster
spec:
  networkPolicy:
    policy: Enabled
---
apiVersion: clickhouse.com/v1alpha1
kind: KeeperCluster
spec:
  networkPolicy:
    policy: Enabled

Les politiques gérées couvrent uniquement le trafic interne au cluster. La sélection des pods active le refus par défaut du trafic entrant, et l’opérateur n’autorise que ce dont les clusters ont besoin pour fonctionner :

Cluster	Source autorisée	Ports autorisés
ClickHouse	Les pods du cluster lui-même	`9009` (interserveur), `9001` (gestion)
ClickHouse	Pods de l’opérateur (label `clickhouse.com/role: operator`, dans n’importe quel espace de noms)	`9001`, `9002` (gestion)
Keeper	Les pods du cluster lui-même	`9234` (Raft)
Keeper	Pods de l’opérateur et chaque `ClickHouseCluster` faisant référence à ce keeper	`2181`, `2281` (client), `9123` (contrôle HTTP)

Un keeper admet les clusters ClickHouse en fonction de leur keeperClusterRef : l’ajout ou la suppression d’une référence met automatiquement à jour la politique du keeper, y compris pour les références provenant d’autres espaces de noms. Les clusters qui utilisent externalKeeper ne sont jamais admis, même si leurs nœuds pointent vers les pods du keeper.

Autoriser les clients et la supervision

Les connexions clientes et la collecte des métriques ne sont pas couvertes : lorsque la politique gérée est activée, aucun trafic ne peut atteindre les ports clients (9000/8123 ou leurs variantes TLS) ni le port des métriques tant que vous ne l’autorisez pas. Les NetworkPolicies étant additives, accordez donc l’accès à l’aide de votre propre politique, en complément de la politique gérée :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-clients
  namespace: <cluster-namespace>
spec:
  podSelector:
    matchLabels:
      app: <name>-clickhouse
  policyTypes: [Ingress]
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: my-app
    ports:
    - protocol: TCP
      port: 9000

Le même principe s’applique aux collectes Prometheus (port 9363 sur ClickHouse, 9090 sur Keeper) : autorisez explicitement votre espace de noms de monitoring. Définir networkPolicy.policy: Disabled (valeur par défaut) supprime la politique gérée ; les politiques définies par l’utilisateur ne sont jamais modifiées par l’opérateur, à moins qu’elles ne portent le label app du cluster.

Désactivation à l’échelle du cluster

La gestion des NetworkPolicy peut également être désactivée à l’échelle du cluster à l’aide de la variable d’environnement ENABLE_NETWORK_POLICY de l’opérateur. Lorsque ENABLE_NETWORK_POLICY=false, l’opérateur ignore l’étape de réconciliation des NetworkPolicy pour tous les ClickHouseCluster et KeeperCluster, quelle que soit leur spec.networkPolicy.policy, et ne surveille pas du tout les ressources NetworkPolicy. Le ServiceAccount de l’opérateur n’a donc pas besoin d’autorisations RBAC sur networkpolicies.networking.k8s.io, ce qui est utile lorsque l’opérateur s’exécute sous un ServiceAccount restreint qui ne dispose intentionnellement pas de ces autorisations.

# in the operator Deployment spec
env:
- name: ENABLE_NETWORK_POLICY
  value: "false"

Avec Helm, le même paramètre est disponible comme valeur du chart :

# values.yaml
controller:
  networkPolicyManagement:
    enabled: false

Politiques du pod de l’opérateur

Le chart fournit également des politiques facultatives qui restreignent le trafic pouvant atteindre le pod du controller manager — le processus de l’opérateur lui-même. Les politiques couvrent les deux ports que l’opérateur expose à d’autres clients : le point de terminaison des métriques et le webhook d’admission.

Ce que crée le chart Helm

Lorsqu’il est activé, le chart crée jusqu’à deux politiques n’autorisant que le trafic entrant, qui ciblent toutes deux le pod du controller manager :

Politique	Source autorisée	Port autorisé
`allow-metrics-traffic`	Espaces de noms portant le libellé `metrics: enabled`	`metrics.port` (par défaut `8080`/TCP)
`allow-webhook-traffic`	Espaces de noms portant le libellé `webhook: enabled`	`webhook.port` (par défaut `9443`/TCP)

Les deux politiques déclarent uniquement policyTypes: [Ingress]. Elles ne restreignent pas le trafic sortant de l’opérateur et ne concernent ni les pods du serveur ClickHouse ni ceux de Keeper.

Refus par défaut

Lorsqu’un pod est sélectionné par une NetworkPolicy d’entrée, il passe en refus par défaut du trafic entrant : dès qu’une politique s’applique, tout trafic entrant vers le pod du controller manager qui n’est pas explicitement autorisé est bloqué. Après activation, les seuls flux entrants qui atteignent l’opérateur sont :

une collecte de métriques depuis un espace de noms portant l’étiquette metrics: enabled, et
un appel au webhook d’admission depuis un espace de noms portant l’étiquette webhook: enabled.

Tout le reste à destination du pod est refusé. C’est bien le durcissement recherché, mais cela signifie qu’un scraper ou un appelant de webhook sans étiquette cesse de fonctionner dès que les politiques prennent effet.

Activation des politiques

Avec Helm, activez l’option dans vos values :

# values.yaml
networkPolicy:
  enabled: true

helm upgrade --install clickhouse-operator \
  oci://ghcr.io/clickhouse/clickhouse-operator-helm \
  -n clickhouse-operator-system --create-namespace \
  -f values.yaml

allow-webhook-traffic nécessite également webhook.enabled: true (la valeur par défaut) ; désactiver le webhook supprime donc aussi sa politique. Avec les manifestes kubectl bruts, décommentez la section [NETWORK POLICY] comme indiqué dans le guide d’installation kubectl. Les manifestes bruts incluent ces deux mêmes politiques.

Attribution de labels aux espaces de noms clients

Comme les deux politiques font correspondre l’origine via namespaceSelector, chaque espace de noms qui doit pouvoir joindre l’operator doit porter le label correspondant. Une collecte ou un appel de webhook provenant d’un espace de noms sans label est rejeté.

# Allow a Prometheus namespace to scrape the metrics endpoint
kubectl label namespace <prometheus-namespace> metrics=enabled

# Allow webhook callers from a given namespace
kubectl label namespace <caller-namespace> webhook=enabled

Combinez ceci avec le RBAC des métriques décrit dans Monitoring → Sécurisation du point de terminaison des métriques : la NetworkPolicy contrôle l’accessibilité, tandis que la liaison au rôle de cluster contrôle l’autorisation. Les deux doivent être en place pour qu’une collecte sécurisée réussisse.

Les requêtes du webhook d’admission proviennent du serveur d’API Kubernetes, et non d’un pod ordinaire. Le fait que ce trafic soit soumis à une NetworkPolicy, ainsi que la source dont il semble provenir, dépendent de la topologie de votre plan de contrôle et du CNI — les plans de contrôle managés, en particulier, peuvent atteindre le webhook depuis une adresse qu’aucun namespaceSelector ne peut sélectionner. Si le trafic du serveur d’API n’est pas couvert par un espace de noms webhook: enabled, l’activation de allow-webhook-traffic peut bloquer l’admission et faire expirer les requêtes de création et de mise à jour de ClickHouseCluster/KeeperCluster. Testez l’admission sur un cluster hors production après l’activation, et ajoutez une règle d’autorisation explicite pour le serveur d’API si nécessaire.

Vérification

NS=clickhouse-operator-system

# The policies exist
kubectl -n $NS get networkpolicy

# Inspect the selectors and allowed sources
kubectl -n $NS describe networkpolicy

Après l’activation, confirmez que :

Prometheus continue de scraper le point de terminaison des métriques (son espace de noms porte le libellé metrics: enabled et est lié au ClusterRole metrics-reader).
La création ou la mise à jour d’un ClickHouseCluster passe toujours l’admission (le webhook est joignable).

Si un scrape ne renvoie aucune donnée ou que l’application d’une CR reste bloquée, un espace de noms source non étiqueté ou la mise en garde ci-dessus concernant l’accessibilité du serveur API est la cause la plus probable.

Supervision de l’operator — le point de terminaison des métriques, son RBAC et la sécurisation de la collecte.
Installer avec kubectl — où décommenter la section de politique réseau.
Installer avec Helm — les valeurs du chart relatives à l’operator.

Installer

Guides

Référence

NetworkPolicies du cluster

Autoriser les clients et la supervision

Désactivation à l’échelle du cluster

Politiques du pod de l’opérateur

Ce que crée le chart Helm

Refus par défaut

Activation des politiques

Attribution de labels aux espaces de noms clients

Vérification

​NetworkPolicies du cluster

​Autoriser les clients et la supervision

​Désactivation à l’échelle du cluster

​Politiques du pod de l’opérateur

​Ce que crée le chart Helm

​Refus par défaut

​Activation des politiques

​Attribution de labels aux espaces de noms clients

​Vérification

​Guides associés

NetworkPolicies du cluster

Autoriser les clients et la supervision

Désactivation à l’échelle du cluster

Politiques du pod de l’opérateur

Ce que crée le chart Helm

Refus par défaut

Activation des politiques

Attribution de labels aux espaces de noms clients

Vérification

Guides associés