> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-trino-dialect.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Políticas de rede

> Como o operator gerencia NetworkPolicies do Kubernetes para clusters ClickHouse e Keeper, como permitir tráfego de clientes e monitoramento e como restringir o tráfego de entrada para o pod do Kubernetes do controller manager.

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.

<Note>
  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.
</Note>

<div id="cluster-network-policies">
  ## NetworkPolicies do cluster
</div>

Habilite a política gerenciada em cada cluster:

```yaml theme={null}
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:

| 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.

<div id="allowing-clients">
  ### Permitir clientes e monitoramento
</div>

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:

```yaml theme={null}
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.

<div id="np-cluster-wide-disable">
  ### Desativação em todo o cluster
</div>

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.

```yaml theme={null}
# 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:

```yaml theme={null}
# values.yaml
controller:
  networkPolicyManagement:
    enabled: false
```

<div id="operator-pod-policies">
  ## Políticas de pod do Kubernetes do operator
</div>

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.

<div id="what-the-helm-chart-creates">
  ## O que o chart do Helm cria
</div>

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.

<div id="default-deny">
  ## Comportamento de bloqueio por padrão
</div>

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.

<div id="enabling">
  ## Habilitando as políticas
</div>

Com o Helm, defina o gate em seus 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` 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](/pt-BR/products/kubernetes-operator/install/kubectl).
Os manifests brutos incluem as mesmas duas políticas.

<div id="labeling-namespaces">
  ## Rotulando espaços de nomes de cliente
</div>

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.

```bash theme={null}
# 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](/pt-BR/products/kubernetes-operator/guides/monitoring#securing-the-metrics-endpoint):
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.

<Warning>
  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.
</Warning>

<div id="verifying">
  ## Verificação
</div>

```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
```

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.

<div id="related-guides">
  ## Guias relacionados
</div>

* [Monitorando o operator](/pt-BR/products/kubernetes-operator/guides/monitoring) — o endpoint de métricas, seu RBAC e como proteger a coleta.
* [Instalar com kubectl](/pt-BR/products/kubernetes-operator/install/kubectl) — onde descomentar a seção de política de rede.
* [Instalar com Helm](/pt-BR/products/kubernetes-operator/install/helm) — os values do chart relevantes para o operator.