Políticas de rede

O operator gerencia recursos de NetworkPolicy do Kubernetes em dois níveis, ambos desabilitados por padrão:

Políticas de cluster — políticas por cluster que abrangem o tráfego interno dos recursos ClickHouseCluster e KeeperCluster, habilitadas por meio de spec.networkPolicy em cada recurso personalizado.
Políticas de pod do Kubernetes do operator — políticas fornecidas pelo chart que restringem o tráfego de entrada para o próprio pod do Kubernetes do controller manager nos endpoints de métricas e webhook.

Uma NetworkPolicy só é aplicada quando o plugin de CNI do cluster a implementa (por exemplo, Calico ou Cilium). Em uma CNI sem suporte à aplicação de NetworkPolicy, os recursos são criados, mas não têm efeito, sem qualquer aviso — o Kubernetes não retorna erro. Confirme que sua CNI aplica políticas antes de depender delas.

NetworkPolicies do cluster

Habilite a política gerenciada em cada cluster:

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

As políticas gerenciadas abrangem somente o tráfego interno do cluster. Ao selecionar os pods, elas passam a aplicar bloqueio por padrão para tráfego de entrada, e o operator permite exatamente o necessário para o funcionamento dos clusters:

Cluster	Origem permitida	Portas permitidas
ClickHouse	Os próprios pods do cluster	`9009` (interserver), `9001` (gerenciamento)
ClickHouse	Pods do operator (rótulo `clickhouse.com/role: operator`, em qualquer espaço de nomes)	`9001`, `9002` (gerenciamento)
Keeper	Os próprios pods do cluster	`9234` (Raft)
Keeper	Pods do operator e todo `ClickHouseCluster` que referencia este keeper	`2181`, `2281` (cliente), `9123` (HTTP control)

Um keeper admite clusters do ClickHouse com base em seu keeperClusterRef — adicionar ou remover uma referência atualiza automaticamente a política do keeper, inclusive referências de outros espaços de nomes. Clusters que usam externalKeeper nunca são admitidos, mesmo que seus nós apontem para os pods do keeper.

Permitir clientes e monitoramento

As conexões de clientes e a coleta de métricas não são contempladas: com a política gerenciada habilitada, nada pode acessar as portas de cliente (9000/8123 ou as variantes TLS) nem a porta de métricas até que você as permita. As NetworkPolicies são cumulativas; portanto, conceda acesso com sua própria política ao lado da política gerenciada:

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

O mesmo padrão se aplica às coletas do Prometheus (porta 9363 no ClickHouse, 9090 no Keeper) — permita explicitamente o acesso do seu espaço de nomes de monitoramento. Definir networkPolicy.policy: Disabled (o padrão) remove a política gerenciada; as políticas definidas pelo usuário nunca são alteradas pelo operator, a menos que tenham o rótulo app do cluster.

Desativação em todo o cluster

O gerenciamento de NetworkPolicy também pode ser desabilitado em todo o cluster por meio da variável de ambiente ENABLE_NETWORK_POLICY do operator. Com ENABLE_NETWORK_POLICY=false, o operator ignora a etapa de reconciliação de NetworkPolicy para todos os ClickHouseCluster e KeeperCluster, independentemente de spec.networkPolicy.policy, e não observa recursos NetworkPolicy. Portanto, o ServiceAccount do operator não precisa de permissões RBAC em networkpolicies.networking.k8s.io, o que é útil ao executar o operator com um ServiceAccount restrito que deliberadamente não tem essas permissões.

# in the operator Deployment spec
env:
- name: ENABLE_NETWORK_POLICY
  value: "false"

Com o Helm, a mesma opção é definida como um valor do chart:

# values.yaml
controller:
  networkPolicyManagement:
    enabled: false

Políticas de pod do Kubernetes do operator

O chart também fornece políticas opcionais que restringem quais tráfegos podem alcançar o pod do Kubernetes do controller manager — o próprio processo do operator. Elas abrangem as duas portas que o operator expõe a outros clientes: o endpoint de métricas e o admission webhook.

O que o chart do Helm cria

Quando habilitado, o chart cria até duas políticas somente de entrada, ambas selecionando o pod do controller-manager:

Política	Origem permitida	Porta permitida
`allow-metrics-traffic`	Espaços de nomes com o rótulo `metrics: enabled`	`metrics.port` (padrão `8080`/TCP)
`allow-webhook-traffic`	Espaços de nomes com o rótulo `webhook: enabled`	`webhook.port` (padrão `9443`/TCP)

Ambas as políticas declaram apenas policyTypes: [Ingress]. Elas não restringem o tráfego de saída do operator e não afetam os pods do servidor ClickHouse nem do Keeper.

Comportamento de bloqueio por padrão

Ao selecionar um pod do Kubernetes com uma NetworkPolicy de entrada, esse pod do Kubernetes passa a ter bloqueio por padrão para tráfego de entrada: assim que qualquer uma das políticas se aplica, todo tráfego de entrada para o pod do Kubernetes do controller manager que não seja explicitamente permitido é descartado. Depois de habilitadas, o único tráfego de entrada que chega ao operator é:

uma coleta de métricas de um espaço de nomes com o rótulo metrics: enabled, e
uma chamada de admission webhook de um espaço de nomes com o rótulo webhook: enabled.

Todo o restante destinado ao pod do Kubernetes é bloqueado. Esse é o reforço de segurança pretendido, mas isso significa que um scraper ou chamador de webhook sem o rótulo deixa de funcionar no momento em que as políticas entram em vigor.

Habilitando as políticas

Com o Helm, defina o gate em seus 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 também requer webhook.enabled: true (o valor padrão), então desabilitar o webhook também remove a política dele. Com os manifests brutos do kubectl, descomente a seção [NETWORK POLICY] conforme descrito no guia de instalação do kubectl. Os manifests brutos incluem as mesmas duas políticas.

Rotulando espaços de nomes de cliente

Como ambas as políticas correspondem à origem por meio de namespaceSelector, todo espaço de nomes que precisa se comunicar com o operator deve ter o rótulo correspondente. Uma coleta ou uma chamada de webhook de um espaço de nomes sem rótulo é descartado.

# 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

Combine isso com o RBAC de métricas descrito em Monitoring → Protegendo o endpoint de métricas: a NetworkPolicy controla o alcance, enquanto a vinculação da Função de cluster controla a autorização. Ambos precisam estar em vigor para que uma coleta protegida funcione.

As solicitações do admission webhook se originam no Kubernetes API server, e não em um pod do Kubernetes comum. Se esse tráfego está sujeito a uma NetworkPolicy e de qual origem ele aparece dependem da topologia do seu plano de controle e da CNI — em particular, planos de controle gerenciados podem alcançar o webhook a partir de um endereço que nenhum namespaceSelector consegue corresponder. Se o tráfego do API server não estiver coberto por um espaço de nomes com webhook: enabled, habilitar allow-webhook-traffic pode bloquear a admissão e fazer com que as solicitações de criação e atualização de ClickHouseCluster/KeeperCluster expirem por tempo limite. Teste a admissão em um cluster que não seja de produção após habilitar isso e adicione uma regra de permissão explícita para o API server, se necessário.

Verificação

NS=clickhouse-operator-system

# The policies exist
kubectl -n $NS get networkpolicy

# Inspect the selectors and allowed sources
kubectl -n $NS describe networkpolicy

Após habilitar, confirme que:

O Prometheus ainda coleta o endpoint de métricas (seu espaço de nomes está rotulado com metrics: enabled e associado à Função de cluster metrics-reader).
Criar ou atualizar um ClickHouseCluster ainda passa pela admissão (o webhook está acessível).

Se uma coleta não retornar dados ou a aplicação de um CR ficar travada, a causa mais provável é um espaço de nomes de origem sem rótulo ou a ressalva sobre a acessibilidade do servidor de API mencionada acima.

Monitorando o operator — o endpoint de métricas, seu RBAC e como proteger a coleta.
Instalar com kubectl — onde descomentar a seção de política de rede.
Instalar com Helm — os values do chart relevantes para o operator.

Instalar

Guias

Referência

NetworkPolicies do cluster

Permitir clientes e monitoramento

Desativação em todo o cluster

Políticas de pod do Kubernetes do operator

O que o chart do Helm cria

Comportamento de bloqueio por padrão

Habilitando as políticas

Rotulando espaços de nomes de cliente

Verificação

​NetworkPolicies do cluster

​Permitir clientes e monitoramento

​Desativação em todo o cluster

​Políticas de pod do Kubernetes do operator

​O que o chart do Helm cria

​Comportamento de bloqueio por padrão

​Habilitando as políticas

​Rotulando espaços de nomes de cliente

​Verificação

​Guias relacionados

NetworkPolicies do cluster

Permitir clientes e monitoramento

Desativação em todo o cluster

Políticas de pod do Kubernetes do operator

O que o chart do Helm cria

Comportamento de bloqueio por padrão

Habilitando as políticas

Rotulando espaços de nomes de cliente

Verificação

Guias relacionados