Egress-Richtlinie

Eine Egress-Richtlinie legt fest, welche ausgehenden Netzwerkverbindungen ein System aufbauen darf, nach Ziel (einer Domain oder einem IP-Bereich), Protokoll und Port, und was mit allem anderen geschieht. Egress-Filterung ist die Durchsetzung einer solchen Richtlinie durch eine Firewall, einen Proxy oder eine Network Policy. Eine Egress-Firewall ist das Gerät oder die Funktion, die sie durchsetzt.

Default Allow und Default Deny

Eine Default-Allow-Richtlinie blockiert eine Liste bekannter schädlicher Ziele und lässt alles andere durch. Eine Default-Deny-Richtlinie erlaubt eine Liste bekannter vertrauenswürdiger Ziele und blockiert den Rest. Kubernetes funktioniert genauso: Ein Pod kann alles erreichen, bis eine Network Policy ihn für Egress auswählt, und ab dann nur noch die Verbindungen, die diese Richtlinie erlaubt (Kubernetes Network Policies).

Nur Default Deny stoppt Verkehr zu einem Ziel, mit dem niemand gerechnet hat, und der Server eines Angreifers ist genau das. Der Preis ist betrieblicher Aufwand: Eine Allowlist muss aufgebaut und aktuell gehalten werden.

Eine Default-Deny-Egress-Richtlinie in Kubernetes

Die Kubernetes-Dokumentation zeigt diese Richtlinie, die alle Pods eines Namespace auswählt und keinen ausgehenden Verkehr erlaubt (Kubernetes network policies):

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

Sie blockiert auch DNS. Workloads, die Namen auflösen, brauchen deshalb eine zweite Richtlinie, die ausgehenden Verkehr zum DNS-Dienst des Clusters erlaubt. Jedes erlaubte Ziel kommt dann als weitere Richtlinie hinzu, nach Pod, Namespace oder IP-Bereich (ipBlock).

FQDN-basierte Richtlinien

Eine Standard-NetworkPolicy erfasst Pods, Namespaces und IP-Bereiche, keine Domainnamen. Paket-Registries liegen hinter Content Delivery Networks mit wechselnden Adressen, deshalb werden Allowlists für sie über Namen geschrieben, als FQDN-basierte Richtlinien, die manche Netzwerk-Plugins ergänzen. Die toFQDNs-Regeln von Cilium erfassen einen exakten Namen mit matchName oder ein Platzhaltermuster mit matchPattern und lernen die Adressen aus den DNS-Antworten, die der DNS-Proxy sieht (Cilium DNS-based policies). Calico Cloud und Calico Enterprise führen domains in Egress-Allow-Regeln (Calico DNS policy).

Warum CI eine braucht

Ein Build-Job verfügt über Deploy-Keys, Cloud-Zugangsdaten und Tokens und führt Installationsskripte der heruntergeladenen Pakete aus. Eine kompromittierte Abhängigkeit kann diese Secrets überallhin senden, wo der CI-Runner hinkommt; so passiert Token-Exfiltration im CI. Die meisten Runner erlauben standardmäßig jeden ausgehenden Verkehr.

Nehmen Sie ein npm-postinstall-Skript, das die Umgebungsvariablen des Jobs an einen unbekannten Host sendet. Mit einer Default-Deny-Richtlinie, die nur die npm-Registry und Ihren Artefakt-Speicher erlaubt, schlägt die Anfrage fehl und die Secrets bleiben im Job.

Was ein Build sieht, wenn die Richtlinie blockiert

Die Verbindung scheitert, und der Build meldet einen gewöhnlichen Netzwerkfehler. Je nachdem, wo die Richtlinie durchgesetzt wird, ist das eine abgelehnte oder zurückgesetzte Verbindung, ein Timeout, eine fehlgeschlagene DNS-Abfrage oder ein Fehler im TLS-Handshake, oft nachdem der Paketmanager es erneut versucht hat. Für Entwickler sieht das wie eine unzuverlässige Registry aus. Deshalb protokolliert eine gute Egress-Richtlinie jede blockierte Verbindung mit Ziel und Grund.

Worauf Sie achten sollten

• Typisierte Ziele. Paket-Registries als Quellen benannt, nicht nur IP-Adressen, weil Registries hinter Content Delivery Networks liegen, deren Adressen sich ändern.
• Vor dem Jobstart validiert, damit eine fehlerhafte Richtlinie sichtbar scheitert, statt nur halb zu greifen.
• Blockiert im Fehlerfall, damit der Job nicht ungeschützt läuft, wenn die Durchsetzung nicht verfügbar ist.

Zur Einführung in GitHub Actions siehe Egress-Richtlinie für GitHub Actions.

CRACI

CRACI setzt eine Egress-Richtlinie am Runner durch, Default Deny oder Allow, mit 24 integrierten Presets für Softwarequellen und typisierten eigenen Quellen für npm, PyPI, apt, apk, den Go-Proxy, Nix, Cargo, OCI-Registries und Git über HTTPS und SSH. Die Richtlinie wird vor dem Jobstart validiert und blockiert im Fehlerfall, und Verstöße lösen Alarme aus. Derselbe Job erfasst, welche Pakete über die erlaubten Verbindungen kamen. Siehe Runner-Sicherheit im Vergleich.

Blockiert die Richtlinie von CRACI eine Verbindung, sieht der Job einen gewöhnlichen Fehler wie 403 Forbidden, eine zurückgesetzte Verbindung, ein EOF oder einen gescheiterten TLS-Handshake. Der Netzwerk-Trace des Jobs führt die Verbindung unter den Proxy-Verstößen mit einem Grund auf, etwa no_match, wenn kein Preset, keine Quelle und keine Regel zum Ziel passte. Der Trace wird in der Job-Ansicht live angezeigt, solange der Job läuft, und ist auch über die API abrufbar (CRACI-Doku: Netzwerkprobleme debuggen).

Für Egress-Kontrolle bei Kubernetes-Workloads, Servern oder GitHub-gehosteten Runnern, die Sie behalten, nutzen Sie eine Network Policy, eine Cloud-Firewall oder einen Runner-Agent: CRACI setzt seine Richtlinie nur auf seinen eigenen Runnern durch, und ein Audit-Modus vor dem Blockieren steht auf seiner Roadmap.