Políticas de red

El operador gestiona recursos NetworkPolicy de Kubernetes en dos niveles, ambos desactivados de forma predeterminada:

• Políticas de clúster: políticas por clúster que cubren el tráfico interno de los recursos ClickHouseCluster y KeeperCluster, habilitadas mediante spec.networkPolicy en cada recurso personalizado.
• Políticas del pod de Kubernetes del operador: políticas incluidas en el gráfico de Helm que restringen el ingreso al propio pod de Kubernetes del controller manager para los endpoints de métricas y webhook.

Habilite la política gestionada para cada clúster:

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

Las políticas administradas cubren únicamente el tráfico interno del clúster. Al seleccionar los pods, se aplica una denegación predeterminada para el Ingreso, y el operador permite exactamente lo que los clústeres necesitan para funcionar:

Un keeper admite clústeres de ClickHouse según su keeperClusterRef: añadir o eliminar una referencia actualiza automáticamente la política del keeper, incluidas las referencias de otros espacios de nombres.

Las conexiones de clientes y el scraping de métricas no están cubiertos: con la política administrada habilitada, nada puede acceder a los puertos de cliente (9000/8123 o las variantes TLS) ni al puerto de métricas hasta que lo permitas. Las NetworkPolicies son aditivas, así que concede acceso con tu propia política junto a la administrada:

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

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.

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.

# 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:

# values.yaml
controller:
  networkPolicyManagement:
    enabled: false

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.

Cuando está habilitado, el gráfico crea hasta dos políticas únicamente de Ingreso, ambas seleccionando el pod de Kubernetes del controller manager:

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.

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.

Con Helm, active esta opción en sus 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 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. Los manifiestos sin procesar incluyen las mismas dos políticas.

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.

# 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

Combina esto con el RBAC de métricas descrito en Monitorización → Protección del endpoint de métricas: 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.

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.

• Monitorización del operador — el endpoint de métricas, su RBAC y cómo proteger el scraping.
• Instalar con kubectl — dónde descomentar la sección de la política de red.
• Instalar con Helm — los values del chart relevantes para el operador.