# =============================================================================
# P5.6/P5.9 — o provisionamento alcanca a API do Kubernetes.
#
# ── O QUE ESTAVA ACONTECENDO (achado em 2026-09-20, com o RBAC ja no ar) ────
#
# Com o ClusterRole e o RoleBinding aplicados, um `curl` de dentro do pod do
# `servico-captacao` ainda devolvia `000` — nem chegava a receber 403. A
# internet respondia (200 de fora), a API nao.
#
# O motivo: a `deny-cross-tenant` deste namespace libera saida para
# `ipBlock: 0.0.0.0/0` **na porta 443**, e a API do k3s atende na **6443**. O
# pod fala com `10.43.0.1:443` (o ClusterIP do Service `kubernetes`), mas o
# controlador de rede avalia DEPOIS do DNAT — e ali o destino ja e
# `187.77.37.184:6443`, que nao casa com nenhuma regra.
#
# Sem esta politica o RBAC nao adianta: a etapa de espera de rollout (P5.6) e a
# de suspensao (P5.9) falham por REDE, com uma mensagem que fala de HTTP.
#
# ── O IP ESTA ESCRITO AQUI, E ISSO E LIMITACAO DA FERRAMENTA ────────────────
#
# NetworkPolicy so entende IP e porta; nao existe "o Service kubernetes" como
# destino. O endereco e o do no (`kubectl -n default get endpoints kubernetes`).
# **No dia em que o no mudar de IP, este arquivo muda junto** — e o sintoma
# sera de novo `000` no lugar de 403.
#
# So o `servico-captacao` precisa disso: nenhum outro pod do namespace fala com
# a API. Por isso o `podSelector` e por app, e nao vazio.
# =============================================================================
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-api-do-kubernetes
  namespace: plataforma-prod
spec:
  podSelector:
    matchLabels:
      app: servico-captacao
  policyTypes: [Egress]
  egress:
    - to:
        - ipBlock:
            cidr: 187.77.37.184/32
      ports:
        - { protocol: TCP, port: 6443 }