Egress policy

Egress policy (politika odchozího provozu) určuje, jaká odchozí síťová spojení smí systém navazovat podle cíle (domény nebo rozsahu IP adres), protokolu a portu, a co se stane se vším ostatním. Egress filtering, tedy filtrování odchozího provozu, je vynucování takové politiky firewallem, proxy nebo síťovou politikou. Egress firewall je zařízení nebo funkce, která vynucování provádí.

Výchozí povolení a výchozí zákaz

Politika s výchozím povolením blokuje seznam známých škodlivých cílů a vše ostatní pustí. Politika s výchozím zákazem povolí seznam známých důvěryhodných cílů a zbytek zablokuje. Kubernetes funguje stejně: pod se může připojit kamkoli, dokud ho síťová politika nevybere pro egress, a od té chvíle jen tam, kam mu tato politika dovolí (Kubernetes network policies).

Jen výchozí zákaz zastaví provoz k cíli, se kterým nikdo nepočítal, a server útočníka je přesně takový cíl. Cenou je provozní zátěž: allowlist je třeba sestavit a udržovat aktuální.

Egress policy s výchozím zákazem v Kubernetes

Dokumentace Kubernetes uvádí tuto politiku, která vybere každý pod v namespace a nepovolí žádný egress (Kubernetes network policies):

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

Blokuje také DNS, takže workloady, které překládají názvy, potřebují druhou politiku, která povolí egress ke službě DNS v clusteru. Každý povolený cíl se pak přidá jako další politika, podle podu, namespace nebo rozsahu IP adres (ipBlock).

Politiky založené na FQDN

Standardní NetworkPolicy porovnává pody, namespaces a rozsahy IP adres, ne doménová jména. Registry balíčků sedí za sítěmi pro doručování obsahu (CDN), jejichž adresy se mění, proto se allowlisty pro ně píšou podle názvů, jako politiky založené na FQDN, které přidávají některé síťové pluginy. Pravidla toFQDNs v Cilium porovnávají přesný název pomocí matchName nebo zástupný vzor pomocí matchPattern a adresy se učí z odpovědí DNS, které vidí jejich DNS proxy (Cilium DNS-based policies). Calico Cloud a Calico Enterprise uvádějí domains v pravidlech povolujících egress (Calico DNS policy).

Proč ji CI potřebuje

Build job má k dispozici klíče pro nasazení, přihlašovací údaje ke cloudu a tokeny a spouští instalační skripty z balíčků, které stahuje. Kompromitovaná závislost může tyto tajné údaje odeslat kamkoli, kam CI runner dosáhne, a právě tak v CI dochází k exfiltraci tokenů. Většina runnerů ve výchozím stavu povoluje veškerý odchozí provoz.

Vezměme skript npm postinstall, který odešle proměnné prostředí jobu na neznámého hostitele. S politikou výchozího zákazu, která povolí jen registr npm a vaše úložiště artefaktů, požadavek selže a tajné údaje zůstanou v jobu.

Co build vidí, když ho politika zablokuje

Spojení selže a build ohlásí běžnou síťovou chybu. Podle toho, kde se politika vynucuje, jde o odmítnuté nebo resetované spojení, timeout, neúspěšný DNS dotaz nebo chybu TLS handshake, často až poté, co to správce balíčků zkusil znovu. Vývojáři to připadá jako nespolehlivý registr, a proto dobrá egress policy zaznamenává každé zablokované spojení s jeho cílem a důvodem zablokování.

Na co se zaměřit

• Typované cíle. Registry balíčků pojmenované jako zdroje, nejen IP adresy, protože registry sedí za CDN, jejichž adresy se mění.
• Ověření před spuštěním jobu, aby chybná politika selhala viditelně, místo aby se uplatnila jen napůl.
• Fail-closed, takže pokud vynucování není k dispozici, job nepoběží bez ochrany.

Zavedení v GitHub Actions popisuje článek egress policy pro GitHub Actions.

CRACI

CRACI vynucuje egress policy na runneru, s výchozím zákazem nebo povolením, s 24 vestavěnými předvolbami softwarových zdrojů a typovanými vlastními zdroji pro npm, PyPI, apt, apk, Go proxy, Nix, Cargo, registry OCI a Git přes HTTPS a SSH. Politika se ověřuje před spuštěním jobu, je fail-closed a porušení vyvolávají upozornění. Stejný job zaznamenává, které balíčky prošly povolenými spojeními. Viz srovnání bezpečnosti runnerů.

Když politika CRACI zablokuje spojení, job uvidí běžné selhání, například 403 Forbidden, resetované spojení, EOF nebo selhání TLS handshake, a síťový záznam jobu uvede spojení mezi porušeními proxy s důvodem, například no_match, když cíli neodpovídala žádná předvolba, zdroj ani pravidlo. Záznam se během běhu jobu průběžně zobrazuje v pohledu jobu a je dostupný i přes API (dokumentace CRACI: ladění síťových problémů).

Pro kontrolu egress u workloadů v Kubernetes, serverů nebo runnerů hostovaných na GitHubu, které si ponecháváte, použijte síťovou politiku, cloudový firewall nebo agenta na runneru: CRACI vynucuje svou politiku jen na vlastních runnerech a režim auditu před blokováním je v plánu vývoje.