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.

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 :

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 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.

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

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.

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.

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.

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.

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.

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.