deploy
45 lines
1.9 KiB
YAML
45 lines
1.9 KiB
YAML
# =============================================================================
|
|
# 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 }
|