Egressbeleid

Een egressbeleid bepaalt welke uitgaande netwerkverbindingen een systeem mag maken, op bestemming (een domein of een IP-bereik), protocol en poort, en wat er met al het andere gebeurt. Egressfiltering is het afdwingen van zo'n beleid door een firewall, een proxy of een netwerkbeleid. Een egressfirewall is het apparaat of de functie die het afdwingt.

Standaard toestaan en standaard weigeren

Een beleid van standaard toestaan blokkeert een lijst bekende slechte bestemmingen en laat al het andere door. Een beleid van standaard weigeren staat een lijst bekende goede bestemmingen toe en blokkeert de rest. Kubernetes werkt op dezelfde manier: een pod kan alles bereiken tot een network policy hem selecteert voor egress, en vanaf dat moment alleen de verbindingen die dat beleid toestaat (Kubernetes network policies).

Alleen standaard weigeren stopt verkeer naar een bestemming die niemand had voorzien, en de server van een aanvaller is precies dat. De prijs is operationeel: een allowlist moet worden opgebouwd en actueel gehouden.

Een standaard-weigeren-egressbeleid in Kubernetes

De Kubernetes-documentatie geeft dit beleid, dat alle pods in een namespace selecteert en geen uitgaand verkeer toestaat (Kubernetes network policies):

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

Het blokkeert ook DNS, dus workloads die namen opzoeken hebben een tweede beleid nodig dat uitgaand verkeer naar de DNS-service van het cluster toestaat. Elke toegestane bestemming komt er daarna bij als een extra beleid, op pod, namespace of IP-bereik (ipBlock).

Beleid op basis van FQDN

Een standaard NetworkPolicy selecteert pods, namespaces en IP-bereiken, geen domeinnamen. Pakketregistries staan achter content delivery networks met wisselende adressen, dus allowlists voor die registries worden op naam geschreven, als beleid op basis van FQDN dat sommige netwerkplug-ins toevoegen. De toFQDNs-regels van Cilium selecteren een exacte naam met matchName of een patroon met matchPattern, en leren de adressen uit de DNS-antwoorden die de DNS-proxy ziet (Cilium DNS-based policies). Calico Cloud en Calico Enterprise zetten domains in egress-allowregels (Calico DNS policy).

Waarom CI er een nodig heeft

Een buildjob bevat deploysleutels, cloudreferenties en tokens, en voert installatiescripts uit van de pakketten die hij downloadt. Een gecompromitteerde dependency kan die secrets overal naartoe sturen waar de CI-runner bij kan, en zo vindt tokenexfiltratie plaats in CI. De meeste runners staan standaard al het uitgaande verkeer toe.

Neem een npm-script postinstall dat de omgevingsvariabelen van de job naar een onbekende host post. Met een beleid van standaard weigeren dat alleen de npm-registry en uw artefactopslag toestaat, mislukt het verzoek en blijven de secrets in de job.

Wat een build ziet als het beleid blokkeert

De verbinding mislukt, en de build meldt een gewone netwerkfout. Afhankelijk van waar het beleid wordt afgedwongen is dat een geweigerde of verbroken verbinding, een time-out, een mislukte DNS-lookup of een fout in de TLS-handshake, vaak nadat de pakketbeheerder het opnieuw heeft geprobeerd. Voor de ontwikkelaar lijkt het op een onbetrouwbare registry. Daarom legt een goed egressbeleid elke geblokkeerde verbinding vast, met de bestemming en de reden.

Waar u op let

• Getypeerde bestemmingen. Pakketregistries benoemd als bronnen, niet alleen IP-adressen, omdat registries achter content delivery networks staan waarvan de adressen veranderen.
• Gevalideerd voordat de job start, zodat een kapot beleid zichtbaar faalt in plaats van half te worden toegepast.
• Fail-closed, zodat de job niet onbeschermd draait als de afdwinging niet beschikbaar is.

Voor de uitrol in GitHub Actions, zie egressbeleid voor GitHub Actions.

CRACI

CRACI dwingt een egressbeleid af op de runner, standaard weigeren of toestaan, met 24 ingebouwde presets voor softwarebronnen en getypeerde eigen bronnen voor npm, PyPI, apt, apk, de Go-proxy, Nix, Cargo, OCI-registries en Git via HTTPS en SSH. Het beleid wordt gevalideerd voordat de job start en werkt fail-closed, en overtredingen leiden tot meldingen. Dezelfde job legt vast welke pakketten via de toegestane verbindingen binnenkwamen. Zie runnerbeveiliging vergeleken.

Blokkeert het beleid van CRACI een verbinding, dan ziet de job een gewone fout, zoals 403 Forbidden, een verbroken verbinding, een EOF of een mislukte TLS-handshake, en de netwerktrace van de job toont de verbinding onder de proxyschendingen met een reden, zoals no_match als geen preset, bron of regel bij de bestemming paste. De trace loopt live mee in de jobweergave zolang de job draait en is ook via de API beschikbaar (CRACI-documentatie: netwerkproblemen debuggen).

Voor egresscontrole op Kubernetes-workloads, servers of door GitHub gehoste runners die u houdt, gebruikt u een network policy, een cloudfirewall of een runneragent: CRACI dwingt zijn beleid alleen af op zijn eigen runners, en een auditmodus vóór het blokkeren staat op de roadmap.