Egress-policy

En egress-policy anger vilka utgående nätverksanslutningar ett system får göra, efter destination (en domän eller ett IP-intervall), protokoll och port, och vad som händer med allt annat. Egress-filtrering är när en brandvägg, en proxy eller en nätverkspolicy upprätthåller en sådan policy. En egress-brandvägg är enheten eller funktionen som upprätthåller den.

Tillåt som standard och neka som standard

En policy som tillåter som standard blockerar en lista med kända skadliga destinationer och släpper igenom allt annat. En policy som nekar som standard tillåter en lista med kända bra destinationer och blockerar resten. Kubernetes fungerar på samma sätt: en pod kan nå vad som helst tills en nätverkspolicy väljer ut den för egress, och från och med då bara de anslutningar som policyn tillåter (Kubernetes network policies).

Bara en policy som nekar som standard stoppar trafik till en destination som ingen förutsåg, och en angripares server är just en sådan. Kostnaden är operativ: en tillåtelselista måste byggas och hållas aktuell.

En egresspolicy med neka som standard i Kubernetes

Kubernetes-dokumentationen visar den här policyn, som väljer alla poddar i ett namespace och inte tillåter någon utgående trafik (Kubernetes network policies):

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

Den blockerar också DNS, så arbetslaster som slår upp namn behöver en andra policy som tillåter utgående trafik till klustrets DNS-tjänst. Varje tillåten destination läggs sedan till som en egen policy, per podd, namespace eller IP-intervall (ipBlock).

FQDN-baserade policyer

En vanlig NetworkPolicy matchar poddar, namespaces och IP-intervall, inte domännamn. Paketregister ligger bakom innehållsleveransnätverk vars adresser ändras, så tillåtelselistor för dem skrivs med namn, som FQDN-baserade policyer som vissa nätverksplugin lägger till. Cilium-regler med toFQDNs matchar ett exakt namn med matchName eller ett mönster med matchPattern och lär sig adresserna från de DNS-svar som DNS-proxyn ser (Cilium DNS-based policies). Calico Cloud och Calico Enterprise anger domains i egressregler som tillåter trafik (Calico DNS policy).

Därför behöver CI en

Ett byggjobb har deploynycklar, molnuppgifter och tokens, och kör installationsskript från de paket som det laddar ner. Ett komprometterat beroende kan skicka de hemligheterna vart som helst som CI-runnern kan nå, och det är så tokenexfiltrering går till i CI. De flesta runners tillåter all utgående trafik som standard.

Ta ett npm-skript för postinstall som postar jobbets miljövariabler till en okänd värd. Med en policy som nekar som standard och bara tillåter npm-registret och ditt artefaktlager misslyckas begäran, och hemligheterna stannar i jobbet.

Vad ett bygge ser när policyn blockerar

Anslutningen misslyckas, och bygget rapporterar ett vanligt nätverksfel. Beroende på var policyn tillämpas är det en nekad eller återställd anslutning, en timeout, en misslyckad DNS-uppslagning eller ett fel i TLS-handskakningen, ofta efter att pakethanteraren har försökt igen. För utvecklaren ser det ut som ett instabilt register, och därför loggar en bra egresspolicy varje blockerad anslutning med destination och orsak.

Det här ska du titta på

• Typade destinationer. Paketregister angivna som källor, inte bara IP-adresser, eftersom register ligger bakom nätverk för innehållsleverans vars adresser ändras.
• Validering innan jobbet startar, så att en trasig policy misslyckas synligt i stället för att tillämpas till hälften.
• Blockerar vid fel, så att jobbet inte körs oskyddat om upprätthållandet inte är tillgängligt.

För att införa en i GitHub Actions, se egress-policy för GitHub Actions.

CRACI

CRACI upprätthåller en egress-policy i runnern, som nekar eller tillåter som standard, med 24 inbyggda förinställningar för programvarukällor och typade egna källor för npm, PyPI, apt, apk, Go-proxyn, Nix, Cargo, OCI-register och Git över HTTPS och SSH. Policyn valideras innan jobbet startar och blockerar vid fel, och överträdelser utlöser varningar. Samma jobb registrerar vilka paket som kom genom de tillåtna anslutningarna. Se runnersäkerhet i jämförelse.

När CRACI:s policy blockerar en anslutning ser jobbet ett vanligt fel, till exempel 403 Forbidden, en återställd anslutning, ett EOF eller en misslyckad TLS-handskakning, och jobbets nätverksspår listar anslutningen bland proxyöverträdelserna med en orsak, som no_match när ingen förinställning, källa eller regel matchade destinationen. Spåret visas live i jobbvyn medan jobbet körs och finns också via API:et (CRACI-dokumentationen: felsök nätverksproblem).

För egress-kontroll av arbetslaster i Kubernetes, servrar eller GitHub-hostade runners som du behåller, använd en nätverkspolicy, en brandvägg i molnet eller en agent på runnern: CRACI upprätthåller sin policy bara på sina egna runners, och ett granskningsläge innan blockering finns på roadmapen.