-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.
```yaml theme={null}
# 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 :
```yaml theme={null}
# 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 :
```yaml theme={null}
# values.yaml
networkPolicy:
enabled: true
```
```bash theme={null}
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](/fr/products/kubernetes-operator/install/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é.
```bash theme={null}
# Allow a Prometheus namespace to scrape the metrics endpoint
kubectl label namespace metrics=enabled
# Allow webhook callers from a given namespace
kubectl label namespace webhook=enabled
```
Combinez ceci avec le RBAC des métriques décrit dans
[Monitoring → Sécurisation du point de terminaison des métriques](/fr/products/kubernetes-operator/guides/monitoring#securing-the-metrics-endpoint) :
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
```bash theme={null}
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.
## Guides associés
* [Supervision de l'operator](/fr/products/kubernetes-operator/guides/monitoring) — le point de terminaison des métriques, son RBAC et la sécurisation de la collecte.
* [Installer avec kubectl](/fr/products/kubernetes-operator/install/kubectl) — où décommenter la section de politique réseau.
* [Installer avec Helm](/fr/products/kubernetes-operator/install/helm) — les valeurs du chart relatives à l'operator.