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.

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 negar por padrão o tráfego de entrada, e o operator permite exatamente o necessário para o funcionamento dos clusters:

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.

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.

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

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.

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

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.

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.

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.

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.

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.