# =============================================================================
# O Sino do painel do dono le os alertas ativos do Alertmanager.
#
# MESMA ARMADILHA JA VISTA TRES VEZES neste tenant (API do Kubernetes,
# controlador do sealed-secrets, Gitea): `deny-cross-tenant` libera
# `ipBlock: 10.43.0.0/16` (a faixa de ClusterIP), e isso NAO adianta — o
# controlador de rede do k3s avalia a politica DEPOIS do DNAT, quando o
# destino ja e o IP do POD (10.42.x.x), fora da faixa liberada. Atravessar
# para outro namespace exige `namespaceSelector` + `podSelector`, sempre.
#
# Por que o pod, e nao o Service `alertmanager-operated`: o mesmo raciocinio
# de sempre — o NetworkPolicy filtra o trafego que chega ao POD de destino,
# entao o rotulo tem de ser do POD, nao do objeto Service (que nao tem
# pacote nenhum passando por ele).
#
# Saida apenas: o Alertmanager nunca inicia conversa conosco.
# =============================================================================
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-alertmanager
  namespace: plataforma-prod
spec:
  podSelector:
    matchLabels:
      app: servico-captacao
  policyTypes: [Egress]
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: monitoring
          podSelector:
            matchLabels:
              app.kubernetes.io/name: alertmanager
      ports:
        - port: 9093
          protocol: TCP