deploy
efc9d35f94
A etapa MANIFESTOS_GERADOS renderiza o molde para tenants/<nome> numa copia de trabalho, e o pod obtem essa copia clonando o Gitea na subida. Clonar e leitura. Escrever continua fora de alcance, de proposito: empurrar no ramo padrao E o deploy, e depende de uma credencial que ainda nao existe. O Gitea aceita clone ANONIMO deste repositorio (conferido com git ls-remote sem credencial), entao a etapa 1 funciona antes de a credencial de escrita existir. A MESMA armadilha de rede, pela TERCEIRA vez. De dentro do pod, antes desta politica: HTTP 000, exit 7. O ipBlock 10.43.0.0/16 da deny-cross-tenant cobre o ClusterIP do Gitea e nao adianta — o k3s avalia DEPOIS do DNAT, e ali o destino ja e o IP do POD. Aconteceu com a API do Kubernetes em 20/09, com o sealed-secrets hoje mais cedo, e agora aqui. E regra deste cluster, nao coincidencia. Estreita: so o servico-captacao, so o POD do Gitea por rotulo (namespaceSelector sozinho abriria a 3000 do namespace inteiro, onde tambem vivem o Valkey e o runner de CI), so a 3000, so saida.
63 lines
2.7 KiB
YAML
63 lines
2.7 KiB
YAML
# =============================================================================
|
|
# P5.3 — o provisionamento LE o repositorio GitOps.
|
|
#
|
|
# ── POR QUE, E O QUE ISTO NAO DA ────────────────────────────────────────────
|
|
#
|
|
# A etapa `MANIFESTOS_GERADOS` renderiza o molde (`moldes/consolidado`) para
|
|
# `tenants/<nome>`, numa copia de trabalho do repositorio. O pod obtem essa
|
|
# copia clonando o Gitea na subida — e clonar e LEITURA.
|
|
#
|
|
# **Escrever continua fora de alcance**, e de proposito: empurrar no ramo padrao
|
|
# E o deploy (o ArgoCD esta com `automated` e `selfHeal`), e isso depende de uma
|
|
# credencial que ainda nao existe. Esta politica nao muda nada disso; ela so
|
|
# permite ler.
|
|
#
|
|
# O Gitea aceita clone ANONIMO deste repositorio — conferido em 2026-09-22 com
|
|
# `git ls-remote` sem credencial. Por isso a etapa 1 funciona antes de a
|
|
# credencial de escrita existir.
|
|
#
|
|
# ── A MESMA ARMADILHA, PELA TERCEIRA VEZ ────────────────────────────────────
|
|
#
|
|
# Medido de dentro do pod do `servico-captacao`, antes desta politica:
|
|
#
|
|
# curl http://gitea-http.gitea.svc:3000/... -> HTTP 000, exit 7
|
|
#
|
|
# A `deny-cross-tenant` libera `ipBlock: 10.43.0.0/16`, que cobre o ClusterIP do
|
|
# Gitea — e nao adianta: **o controlador de rede do k3s avalia a politica DEPOIS
|
|
# do DNAT**, e ali o destino ja e o IP do POD (10.42.x.x).
|
|
#
|
|
# Aconteceu com a API do Kubernetes em 2026-09-20, com o controlador do
|
|
# sealed-secrets em 2026-09-22, e agora aqui. **E regra deste cluster, e nao
|
|
# coincidencia:** `ipBlock` com ClusterIP nao libera nada para outro namespace;
|
|
# atravessar exige `namespaceSelector` + `podSelector`.
|
|
#
|
|
# ── POR QUE ESTA REGRA E ESTREITA ───────────────────────────────────────────
|
|
#
|
|
# `podSelector` por app: so o `servico-captacao` provisiona tenant. O destino e
|
|
# o POD do Gitea, por rotulo — `namespaceSelector` sozinho abriria a 3000 de
|
|
# todo o namespace `gitea`, onde tambem vivem o Valkey e o runner de CI.
|
|
#
|
|
# Saida apenas: o Gitea nunca inicia conversa conosco.
|
|
# =============================================================================
|
|
apiVersion: networking.k8s.io/v1
|
|
kind: NetworkPolicy
|
|
metadata:
|
|
name: egress-gitea
|
|
namespace: plataforma-prod
|
|
spec:
|
|
podSelector:
|
|
matchLabels:
|
|
app: servico-captacao
|
|
policyTypes: [Egress]
|
|
egress:
|
|
- to:
|
|
- namespaceSelector:
|
|
matchLabels:
|
|
kubernetes.io/metadata.name: gitea
|
|
podSelector:
|
|
matchLabels:
|
|
app: gitea
|
|
ports:
|
|
- port: 3000
|
|
protocol: TCP
|