Egress-politik

En egress-politik definerer, hvilke udgående netværksforbindelser et system må oprette, efter destination (et domæne eller et IP-område), protokol og port, og hvad der sker med alt andet. Egress-filtrering er håndhævelsen af en sådan politik med en firewall, en proxy eller en netværkspolitik. En egress-firewall er den enhed eller funktion, der står for håndhævelsen.

Default allow og default deny

En default allow-politik blokerer en liste over kendte dårlige destinationer og lukker alt andet igennem. En default deny-politik tillader en liste over kendte gode destinationer og blokerer resten. Kubernetes fungerer på samme måde: En pod kan nå alt, indtil en netværkspolitik vælger den for egress, og derefter kun de forbindelser, som politikken tillader (Kubernetes network policies).

Kun default deny stopper trafik til en destination, som ingen havde forudset, og en angribers server er netop det. Prisen er driftsmæssig: En allowlist skal bygges og holdes opdateret.

En egress-politik med default deny i Kubernetes

Kubernetes-dokumentationen viser denne politik, som vælger alle pods i et namespace og ikke tillader udgående trafik (Kubernetes network policies):

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

Den blokerer også DNS, så workloads, der slår navne op, har brug for en anden politik, der tillader udgående trafik til clusterets DNS-tjeneste. Hver tilladt destination tilføjes derefter som en ny politik, efter pod, namespace eller IP-interval (ipBlock).

FQDN-baserede politikker

En almindelig NetworkPolicy rammer pods, namespaces og IP-intervaller, ikke domænenavne. Pakkeregistre ligger bag content delivery networks, hvis adresser skifter, så allowlister for dem skrives med navne, som FQDN-baserede politikker, som nogle netværksplugins tilføjer. Ciliums toFQDNs-regler rammer et præcist navn med matchName eller et mønster med matchPattern og lærer adresserne fra de DNS-svar, DNS-proxyen ser (Cilium DNS-based policies). Calico Cloud og Calico Enterprise angiver domains i egress-regler, der tillader trafik (Calico DNS policy).

Hvorfor CI har brug for en

Et build-job har deploy-nøgler, cloud-legitimationsoplysninger og tokens og kører install-scripts fra de pakker, det downloader. En kompromitteret afhængighed kan sende de secrets hvor som helst, CI-runneren kan nå, og det er sådan, token-eksfiltrering sker i CI. De fleste runnere tillader som standard al udgående trafik.

Tag et npm-script til postinstall, der sender jobbets miljøvariabler til en ukendt host. Med en default deny-politik, der kun tillader npm-registryet og dit artefaktlager, fejler forespørgslen, og secrets bliver i jobbet.

Hvad et build ser, når politikken blokerer

Forbindelsen fejler, og buildet melder en almindelig netværksfejl. Afhængigt af, hvor politikken håndhæves, er det en afvist eller nulstillet forbindelse, en timeout, et mislykket DNS-opslag eller en fejl i TLS-handshaket, ofte efter at pakkehåndteringen har prøvet igen. For udvikleren ligner det et ustabilt registry, og derfor logger en god egress-politik hver blokeret forbindelse med destination og årsag.

Hvad du skal kigge efter

• Typede destinationer. Pakke-registries angivet som kilder, ikke kun som IP-adresser, fordi registries ligger bag content delivery networks, hvis adresser skifter.
• Valideret før jobbet starter, så en defekt politik fejler synligt i stedet for at blive halvt anvendt.
• Blokerer ved fejl, så jobbet ikke kører ubeskyttet, hvis håndhævelsen ikke er tilgængelig.

For udrulning i GitHub Actions, se egress-politik for GitHub Actions.

CRACI

CRACI håndhæver en egress-politik på runneren, default deny eller allow, med 24 indbyggede presets for softwarekilder og typede brugerdefinerede kilder til npm, PyPI, apt, apk, Go-proxyen, Nix, Cargo, OCI-registries og Git over HTTPS og SSH. Politikken valideres, før jobbet starter, og blokerer ved fejl, og overtrædelser udløser alarmer. Det samme job registrerer, hvilke pakker der kom gennem de tilladte forbindelser. Se runner-sikkerhed sammenlignet.

Når CRACI's politik blokerer en forbindelse, ser jobbet en almindelig fejl som 403 Forbidden, en nulstillet forbindelse, en EOF eller et mislykket TLS-handshake, og jobbets netværkstrace viser forbindelsen under proxy-overtrædelser med en årsag, for eksempel no_match, når ingen preset, kilde eller regel matchede destinationen. Tracet vises live i jobvisningen, mens jobbet kører, og er også tilgængeligt via API'et (CRACI-dokumentation: fejlfind netværksproblemer).

Til egress-kontrol af Kubernetes-workloads, servere eller GitHub-hostede runnere, du beholder, så brug en netværkspolitik, en cloud-firewall eller en runner-agent: CRACI håndhæver kun sin politik på sine egne runnere, og en audit-tilstand før blokering er på roadmappen.