-clickhouse
policyTypes: [Ingress]
ingress:
- from:
- podSelector:
matchLabels:
role: my-app
ports:
- protocol: TCP
port: 9000
```
El mismo patrón se aplica a los scrape de Prometheus (puerto `9363` en ClickHouse,
`9090` en Keeper): permita explícitamente el espacio de nombres de monitorización.
Configurar `networkPolicy.policy: Disabled` (el valor predeterminado) elimina la política
gestionada; el operador nunca modifica las políticas definidas por el usuario, salvo que
incluyan la etiqueta `app` del clúster.
### Exclusión a nivel de todo el clúster
La gestión de NetworkPolicy también puede deshabilitarse para todo el clúster mediante la variable de entorno `ENABLE_NETWORK_POLICY` del operador. Con `ENABLE_NETWORK_POLICY=false`,
el operador omite el paso de reconciliación de NetworkPolicy para **todos** los
ClickHouseCluster y KeeperCluster, independientemente de su `spec.networkPolicy.policy`,
y **no supervisa** ningún recurso `NetworkPolicy`. Por lo tanto, el
ServiceAccount del operador no necesita permisos RBAC sobre
`networkpolicies.networking.k8s.io`, lo que resulta útil al ejecutar el operador
con un ServiceAccount restringido que deliberadamente no incluye esos permisos.
```yaml theme={null}
# in the operator Deployment spec
env:
- name: ENABLE_NETWORK_POLICY
value: "false"
```
Con Helm, la misma opción se expone como un valor del chart:
```yaml theme={null}
# values.yaml
controller:
networkPolicyManagement:
enabled: false
```
## Políticas de pods de Kubernetes del operador
El gráfico de Helm también incluye políticas opcionales que restringen qué tráfico puede llegar al
**pod de Kubernetes del controller manager**; es decir, al proceso del propio operador. Cubren los dos
puertos que el operador expone a otros clientes: el endpoint de métricas y el
admission webhook.
## Lo que crea el gráfico de Helm
Cuando está habilitado, el gráfico crea hasta dos políticas únicamente de Ingreso, ambas seleccionando
el pod de Kubernetes del controller manager:
| Política | Origen permitido | Puerto permitido |
| ----------------------- | ------------------------------------------------------ | ---------------------------------------- |
| `allow-metrics-traffic` | Espacios de nombres etiquetados con `metrics: enabled` | `metrics.port` (por defecto, `8080`/TCP) |
| `allow-webhook-traffic` | Espacios de nombres etiquetados con `webhook: enabled` | `webhook.port` (por defecto, `9443`/TCP) |
Ambas políticas declaran únicamente `policyTypes: [Ingress]`. No restringen la salida
del operador ni afectan a los pods de Kubernetes de ClickHouse server o Keeper.
## Comportamiento de denegación por defecto
Seleccionar un pod de Kubernetes con una `NetworkPolicy` de ingreso hace que ese pod de Kubernetes pase a **denegar por defecto el ingreso**: una vez que se aplica cualquiera de estas políticas, se descarta todo el tráfico entrante al pod de Kubernetes del controller manager que no esté permitido explícitamente. Después de habilitarlas,
el único ingreso que llega al operador es:
* un scrape de métricas desde un espacio de nombres etiquetado con `metrics: enabled`, y
* una llamada al admission webhook desde un espacio de nombres etiquetado con `webhook: enabled`.
Todo lo demás que llegue al pod de Kubernetes se deniega. Este es el endurecimiento previsto, pero
significa que un scraper o emisor de llamadas al webhook sin etiquetar deja de funcionar en cuanto las
políticas entran en vigor.
## Habilitar las políticas
Con Helm, active esta opción en sus 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` también requiere `webhook.enabled: true` (el
valor predeterminado), por lo que deshabilitar el webhook también elimina su política.
Con los manifiestos sin procesar de `kubectl`, descomente la sección `[NETWORK POLICY]` como se
describe en la [guía de instalación de kubectl](/es/products/kubernetes-operator/install/kubectl).
Los manifiestos sin procesar incluyen las mismas dos políticas.
## Etiquetado de los espacios de nombres del client
Como ambas políticas coinciden con el origen mediante `namespaceSelector`, todo espacio de nombres
que necesite llegar al operador debe llevar la etiqueta correspondiente. Un scrape o
una llamada de webhook desde un espacio de nombres sin etiquetar se descarta.
```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
```
Combina esto con el RBAC de métricas descrito en
[Monitorización → Protección del endpoint de métricas](/es/products/kubernetes-operator/guides/monitoring#securing-the-metrics-endpoint):
la `NetworkPolicy` controla el acceso, mientras que la vinculación del Rol de clúster controla
la autorización. Ambos deben estar configurados para que un scrape seguro funcione correctamente.
Las solicitudes del webhook de admisión se originan en el Kubernetes API server, no en un
pod de Kubernetes normal. Que ese tráfico esté sujeto a una `NetworkPolicy`, y desde
qué origen aparezca, depende de la topología del plano de control y del CNI;
en particular, los planos de control gestionados pueden llegar al webhook desde una dirección que
ningún `namespaceSelector` puede identificar. Si el tráfico del servidor de API no está cubierto por un
espacio de nombres con `webhook: enabled`, habilitar `allow-webhook-traffic` puede bloquear
la admisión y hacer que las solicitudes de creación y actualización de `ClickHouseCluster`/`KeeperCluster`
agoten el tiempo de espera. Prueba la admisión en un clúster no de production después de habilitarlo y añade una
regla explícita de permiso para el servidor de API si es necesario.
## Verificación
```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
```
Después de habilitarlo, confirma que:
* Prometheus siga recopilando métricas desde el endpoint de métricas (su espacio de nombres está etiquetado
con `metrics: enabled` y asociado al Rol de clúster metrics-reader).
* Crear o actualizar un `ClickHouseCluster` siga pasando la validación de admisión (el webhook
es accesible).
Si un scrape no devuelve datos o la aplicación de un CR se queda bloqueada, la causa más probable es un espacio de nombres de origen sin etiquetar o
la advertencia anterior sobre la accesibilidad del servidor API.
## Guías relacionadas
* [Monitorización del operador](/es/products/kubernetes-operator/guides/monitoring) — el endpoint de métricas, su RBAC y cómo proteger el scraping.
* [Instalar con kubectl](/es/products/kubernetes-operator/install/kubectl) — dónde descomentar la sección de la política de red.
* [Instalar con Helm](/es/products/kubernetes-operator/install/helm) — los values del chart relevantes para el operador.