Política de egress

Uma política de egress define que ligações de rede de saída um sistema pode fazer, por destino (um domínio ou um intervalo de IP), protocolo e porta, e o que acontece a todas as restantes. A filtragem de egress é a aplicação dessa política por uma firewall, um proxy ou uma network policy. Uma firewall de egress é o dispositivo ou a funcionalidade que a aplica.

Permissão por defeito e negação por defeito

Uma política de permissão por defeito bloqueia uma lista de destinos conhecidos como maliciosos e deixa passar tudo o resto. Uma política de negação por defeito permite uma lista de destinos conhecidos como fiáveis e bloqueia os restantes. O Kubernetes funciona da mesma forma: um pod pode chegar a qualquer destino até uma network policy o selecionar para egress e, a partir daí, apenas às ligações que essa política permite (network policies do Kubernetes).

Só a negação por defeito trava o tráfego para um destino que ninguém previu, e o servidor de um atacante é exatamente isso. O custo é operacional: é preciso construir uma lista de permissões e mantê-la atualizada.

Uma política de egress com negação por defeito no Kubernetes

A documentação do Kubernetes apresenta esta política, que seleciona todos os pods de um namespace e não permite tráfego de saída (Kubernetes network policies):

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-egress
spec:
  podSelector: {}
  policyTypes:
    - Egress

Também bloqueia o DNS, por isso as cargas de trabalho que resolvem nomes precisam de uma segunda política que permita tráfego de saída para o serviço DNS do cluster. Cada destino permitido é depois acrescentado como outra política, por pod, namespace ou intervalo de IP (ipBlock).

Políticas baseadas em FQDN

Uma NetworkPolicy padrão seleciona pods, namespaces e intervalos de IP, não nomes de domínio. Os registos de pacotes estão atrás de redes de distribuição de conteúdo cujos endereços mudam, por isso as suas listas de permissões escrevem-se por nome, como políticas baseadas em FQDN que alguns plugins de rede acrescentam. As regras toFQDNs do Cilium selecionam um nome exato com matchName ou um padrão com matchPattern e aprendem os endereços a partir das respostas DNS que o seu proxy DNS vê (Cilium DNS-based policies). O Calico Cloud e o Calico Enterprise indicam domains nas regras de egress que permitem tráfego (Calico DNS policy).

Porque a CI precisa de uma

Um job de build guarda chaves de implementação, credenciais cloud e tokens, e executa scripts de instalação dos pacotes que descarrega. Uma dependência comprometida pode enviar esses segredos para qualquer destino que o runner de CI consiga alcançar, e é assim que acontece a exfiltração de tokens na CI. A maioria dos runners permite todo o tráfego de saída por defeito.

Imagine um script postinstall de npm que envia as variáveis de ambiente do job para um host desconhecido. Com uma política de negação por defeito que permite apenas o registo npm e o seu repositório de artefactos, o pedido falha e os segredos ficam no job.

O que um build vê quando a política o bloqueia

A ligação falha e o build reporta um erro de rede comum. Conforme o ponto onde a política é aplicada, trata-se de uma ligação recusada ou reposta, de um tempo limite esgotado, de uma consulta DNS falhada ou de um erro no handshake TLS, muitas vezes depois de o gestor de pacotes ter tentado novamente. Para o programador parece um registo instável, e é por isso que uma boa política de egress regista cada ligação bloqueada com o destino e o motivo.

O que procurar

• Destinos tipificados. Registos de pacotes identificados como origens, e não apenas endereços IP, porque os registos estão atrás de redes de distribuição de conteúdos cujos endereços mudam.
• Validada antes de o job arrancar, para que uma política com erros falhe de forma visível em vez de ficar aplicada pela metade.
• Falha em modo fechado, para que, se a aplicação não estiver disponível, o job não seja executado sem proteção.

Para a implementação no GitHub Actions, consulte política de egress no GitHub Actions.

CRACI

O CRACI aplica uma política de egress no runner, com negação ou permissão por defeito, 24 predefinições integradas de origens de software e origens personalizadas tipificadas para npm, PyPI, apt, apk, o proxy de Go, Nix, Cargo, registos OCI e Git sobre HTTPS e SSH. A política é validada antes de o job arrancar e falha em modo fechado, e as violações geram alertas. O mesmo job regista que pacotes chegaram através das ligações permitidas. Consulte a segurança de runners comparada.

Quando a política da CRACI bloqueia uma ligação, o job vê uma falha comum, como um 403 Forbidden, uma ligação reposta, um EOF ou um handshake TLS falhado, e o rastreio de rede do job lista a ligação nas violações do proxy com um motivo, como no_match quando nenhum preset, fonte ou regra correspondeu ao destino. O rastreio aparece em direto na vista do job enquanto este corre e também está disponível através da API (documentação da CRACI: depurar problemas de rede).

Para controlo de egress em cargas de trabalho Kubernetes, servidores ou runners alojados no GitHub que mantenha, use uma network policy, uma firewall cloud ou um agente no runner: o CRACI aplica a sua política apenas nos seus próprios runners, e um modo de auditoria antes do bloqueio está no seu roadmap.