Skip to main content
L’opérateur fournit des ressources Kubernetes NetworkPolicy facultatives qui restreignent le trafic pouvant atteindre le pod du controller manager — le processus de l’opérateur lui-même, et non le ClickHouse server ni les pods Keeper. Elles sont désactivées par défaut, vous ne les activez donc que si vous souhaitez isoler le trafic entrant de l’opérateur. Les politiques couvrent les deux ports que l’opérateur expose à d’autres clients : le point de terminaison des métriques et l’admission 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.

​
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 : 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 :
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é.
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

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.
Dernière modification le 3 juillet 2026