feat(plataforma): o certificado de selagem vem do controlador, pela URL

O ipBlock da deny-cross-tenant nao vale para destino em outro namespace (o k3s
avalia depois do DNAT), entao a variavel sozinha daria FalhaTemporaria. Vai
junto a netpol estreita: so o servico-captacao, so o pod do controlador, so a
porta 8080, so saida.
This commit is contained in:
deploy
2026-09-22 13:07:28 +00:00
parent 84293e4176
commit 8e0a2a8f18
2 changed files with 72 additions and 0 deletions
@@ -0,0 +1,60 @@
# =============================================================================
# P5.3 — o provisionamento alcanca o controlador do sealed-secrets.
#
# ── POR QUE, E POR QUE SO AGORA ─────────────────────────────────────────────
#
# A etapa `SEGREDOS_SELADOS` precisa do certificado PUBLICO do controlador. Ate
# 2026-09-22 ela o lia de um ARQUIVO; desde entao aceita tambem a URL
# `http://sealed-secrets-controller.kube-system:8080/v1/cert.pem`, que e a forma
# recomendada — o controlador ROTACIONA a chave a cada 30 dias (medido: 16/06,
# 16/07, 15/08, 14/09), e um arquivo versionado nasce certo e fica velho em um
# mes, EM SILENCIO.
#
# ── O MESMO DEFEITO DO 17-netpol-api-do-kubernetes, PELA MESMA CAUSA ────────
#
# Medido em 2026-09-22, de dentro do pod do `servico-captacao`:
#
# getent hosts sealed-secrets-controller.kube-system -> 10.43.71.152 OK
# curl http://sealed-secrets-controller.kube-system:8080/v1/cert.pem
# -> HTTP 000, exit 7
#
# O nome RESOLVE e a conexao NAO sai. A `deny-cross-tenant` libera
# `ipBlock: 10.43.0.0/16`, que cobre o ClusterIP `10.43.71.152` — e nao adianta:
# **o controlador de rede do k3s avalia DEPOIS do DNAT**, e ali o destino ja e o
# IP do POD do controlador (`10.42.x.x`), que nao casa com nenhuma regra.
#
# E a mesma armadilha que fez a API do Kubernetes devolver `000` em 2026-09-20,
# e vale registrar que ela se repete: `ipBlock` com ClusterIP nao protege nem
# libera nada para destino em OUTRO namespace.
#
# ── POR QUE ESTA REGRA E ESTREITA ───────────────────────────────────────────
#
# `podSelector` por app: so o `servico-captacao` sela segredo; nenhum outro pod
# do namespace tem o que pedir ao controlador.
#
# O destino e o POD do controlador, por rotulo, e nao o namespace inteiro —
# `namespaceSelector` sozinho abriria a porta 8080 de TODO o kube-system.
#
# Saida apenas; o controlador nunca inicia conversa conosco.
# =============================================================================
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: egress-sealed-secrets
namespace: plataforma-prod
spec:
podSelector:
matchLabels:
app: servico-captacao
policyTypes: [Egress]
egress:
- to:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: kube-system
podSelector:
matchLabels:
name: sealed-secrets-controller
ports:
- port: 8080
protocol: TCP
@@ -55,6 +55,18 @@ spec:
# noutro host, este valor muda junto ou o formulario toma CORS.
- { name: CAPTACAO_ORIGEM, value: "https://plataforma.athleticmap.influxdigital.com.br" }
- { name: CAPTACAO_RETENCAO_MESES, value: "24" }
# P5.3 — de onde vem o certificado PUBLICO do sealed-secrets.
#
# A URL, e nao um arquivo: o controlador ROTACIONA a chave a cada
# 30 dias (medido: 16/06, 16/07, 15/08, 14/09), e um certificado
# versionado nasce certo e fica velho em um mes, EM SILENCIO —
# selar com o antigo continua funcionando enquanto ele guardar as
# privadas anteriores. Lido a cada provisionamento, vem sempre o
# corrente.
#
# Depende do `18-netpol-sealed-secrets.yaml`: sem ele a conexao
# nao sai (o ipBlock da deny-cross-tenant nao vale depois do DNAT).
- { name: PROVISIONAMENTO_CERT_SELAGEM, value: "http://sealed-secrets-controller.kube-system:8080/v1/cert.pem" }
- { name: CAPTACAO_LIMITE_POR_IP, value: "5" }
# Destino do aviso ao comercial. Vazio = lead e gravado e o
# aviso vira log sem PII. Preencher quando houver SMTP.