Wer eine sichere Anwendung baut, untersagt ihr in der Regel jede Verbindung nach außerhalb der Virtual Private Cloud (VPC). Manchmal braucht es aber eine gezielte Öffnung – etwa wenn die Anwendung eine Drittanbieter-API ansprechen muss.
Gateway to Domain, Lovecraft-style. Credit: StableDiffusion
Üblich ist, Egress nur für die relevanten IP-Adressen zuzulassen – konfiguriert über die Firewall der Google Cloud Platform oder über Network ACLs auf AWS. IP-Adressen können sich allerdings im Laufe der Zeit ändern, während der Fully Qualified Domain Name (FQDN), beispielsweise api.example.com, einen stabilen, öffentlich bekannten Endpunkt liefert. Die meisten Anwendungen sind so konfiguriert, dass sie einen FQDN ansprechen und keine IP-Adresse.
In diesem Artikel zeige ich Wege, Egress ausschließlich auf einen bestimmten FQDN zu beschränken – mit den jeweiligen Vor- und Nachteilen.
Gesucht sind Optionen, die kostengünstig, wartungsarm, robust und unkompliziert sind.
Wir schauen uns außerdem Lösungen an, die zusätzlich Kubernetes-aware sind: Wenn Ihre Anwendung in Kubernetes läuft, möchten Sie Egress womöglich aus einem bestimmten Kubernetes-Namespace erlauben, aus anderen jedoch nicht.
Sinnvoll ist auch eine feingranulare Kontrolle auf Domain-Ebene, denn hinter einer einzigen IP-Adresse können mehrere Domains liegen. Die meisten der hier vorgestellten Lösungen berücksichtigen das nicht – wer Zugriff auf eine Domain mit einer bestimmten IP-Adresse erlaubt, lässt damit auch Egress zu allen anderen Domains hinter dieser Adresse zu. In der Regel ist das kein Sicherheitsproblem, da üblicherweise alle Domains unter einer IP-Adresse von derselben Stelle kontrolliert werden. Name-based Virtual Hosting ermöglicht jedoch genau dieses Szenario, weshalb wir auch Lösungen vorstellen, die das abdecken.
Die hier behandelten Optionen sind:
- Squid als Beispiel für einen selbstverwalteten Proxy
- AWS Network Gateway mit Deep Packet Inspection, das Kontrolle bis auf Domain-Ebene ermöglicht – auch bei Virtual Hosting.
- Ein neues Feature in der Google Firewall, das FQDN-Kontrolle mit dem Komfort eines Serverless-Dienstes bietet.
- Das neue Google Secure Web Gateway, das granulare Kontrolle bis hinunter auf Domain- und sogar URL-Ebene ergänzt.
- Kubernetes-aware Lösungen: Cilium und Istio.
(Hinweis zu OSI-Layern: Da Domain-Namen und DNS auf der "Application Layer" des OSI-Netzwerkmodells angesiedelt sind – Layer 7 –, wird FQDN Egress Control mitunter auch "Layer 7 Egress Control" genannt. Auf Layer 3 hingegen werden IP-Adressen definiert; sie ist die Ebene, auf der klassische Firewalls oder Network ACLs greifen.)
Selbst implementieren
Schauen wir uns zunächst an, wie sich das selbst umsetzen ließe. Nicht, dass ich das empfehlen würde – aber es zeigt, was diese Lösungen unter der Haube tatsächlich tun.
Auch wenn die Anwendung mit dem FQDN der Drittanbieter-API konfiguriert ist, muss Ihre Lösung Pakete auf IP-Ebene blockieren, denn der gesamte Netzwerk-Traffic basiert darauf. Domain-Namen sind nur vor dem Verbindungsaufbau relevant, wenn der Client die IP-Adresse anhand des Domain-Namens auflöst.
Beachten Sie auch, dass ein einzelner FQDN auf mehrere IP-Adressen verweisen kann. Das ist kein Problem, denn ein normaler DNS-Lookup liefert diese zurück, sodass Sie den Zugriff auf eine Liste von IP-Adressen freigeben können.
Sie haben eine Firewall oder Network ACL, die jeden Traffic außer den relevanten IP-Adressen blockiert.
Sie schreiben und deployen eine Anwendung, die regelmäßig DNS abfragt, um die aktuelle IP-Adresse für den FQDN der API – api.example.com – zu ermitteln. (Eine kostengünstige Variante hierfür sind GCP Cloud Functions oder AWS Lambda mit periodischem Trigger.) In den seltenen Fällen, in denen sich die IP-Adresse geändert hat, aktualisiert Ihre Anwendung anschließend die Firewall oder Network ACL.
Selbstverwaltete Reverse Web Proxies
Eine "klassische" Lösung für FQDN Egress Control ist ein Reverse Web Proxy, wobei Squid die bekannteste Open-Source-Variante ist. Sie nutzen den Routing-Service Ihrer Cloud, um den gesamten ausgehenden Traffic über eine VM zu leiten, auf der der Squid-Proxy läuft. Dieser prüft den Domain-Namen anhand einer ACL-Whitelist und leitet den Traffic bei einer Übereinstimmung weiter.
Squid ist im AWS Marketplace verfügbar; siehe dazu diese Architektur-Diskussion. Ebenso steht es im GCP Marketplace bereit; siehe hierzu dieses Networking-Setup. Sehenswert ist auch diese Diskussion über FQDN Egress Control in Squid und anderen Proxies wie DiscrimiNAT und Aviatrix.
Proxies wie Squid auf einer VM bringen Wartungsaufwand mit sich – etwa beim Aktualisieren der VM-Betriebssysteme oder beim Umgang mit Abstürzen. Da der gesamte Netzwerk-Traffic durch eine einzige VM läuft (sofern Sie nicht zusätzlich ein Load-Balanced-Deployment aufsetzen), kann die Last hoch werden. Das gefährdet die Robustheit und macht unter Umständen eine größere VM im 24/7-Betrieb nötig, auch wenn diese nicht voll ausgelastet ist.
AWS Network Firewall
AWS Network Firewall führt Deep Packet Inspection durch und erhält dadurch deutlich mehr Filtertiefe. Sie ist daher nicht direkt mit der Google Firewall vergleichbar, die eher AWS Network ACLs ähnelt.
AWS Network Firewall unterstützt FQDN Egress Control über stateful Domain List Rule Groups. Über den Server Name Indicator (SNI), der beim Aushandeln einer TCP-Verbindung für HTTPS-Traffic übermittelt wird, kann sie zwischen Domains in Virtual-Hosting-Szenarien unterscheiden.
Network Firewall lässt sich mit der Route 53 DNS Firewall integrieren, die DNS-Auflösungsversuche blockiert – sodass etwa eine DNS-Anfrage für api.example.com aus einer Anwendung innerhalb der VPC gar nicht erst zu einer IP-Adresse aufgelöst wird. Die DNS Firewall verhindert allerdings nicht den Zugriff auf diese IP-Adresse selbst; das übernimmt die Network Firewall.
Network Firewall ist eine gute Wahl, kann aber kostspielig werden: Sie ist für komplexe Multi-Network-Enterprise-Umgebungen konzipiert. ( Siehe meinen Artikel im DoiT Blog, in dem ich die Use Cases der zahlreichen Firewall-ähnlichen Services auf AWS vergleiche.)
Google Firewall und Web Gateway
Eine vom Cloud-Anbieter vollständig verwaltete Lösung ist deutlich komfortabler, als die VM selbst zu betreiben. Google bringt nun einige Lösungen heraus, die genau das ermöglichen. In einem Folgebeitrag gehe ich detailliert auf deren Verwendung ein – hier zunächst die wichtigsten Eckpunkte.
Die Google Firewall verfügt über ein neues FQDN-Objects-Feature, derzeit in Limited Preview. Es nutzt Cloud DNS, um alle 30 Sekunden die aktuelle IP-Adresse des externen Dienstes nachzuschlagen.
Ein weiterer Service in Limited Preview, das Secure Web Gateway, erlaubt ebenfalls Kontrolle auf Domain-Ebene. Dazu gewähren Sie ihm Zugriff auf Ihre SSL-Zertifikate im GCP Certificate Manager, damit es Ihren HTTPS-Traffic ent- und wieder verschlüsseln kann. Dieser tiefe Einblick ermöglicht Egress-Kontrolle auf Domain-Ebene, sogar in Virtual-Hosting-Szenarien. Da der vollständige HTTP-Request sichtbar ist, lässt sich sogar bis auf URL-Ebene steuern.
Cilium
Die bisher genannten Lösungen arbeiten auf Ebene der VPC. Wenn Ihre Anwendung jedoch auf Kubernetes läuft, soll die Egress-Kontrolle idealerweise mit Kubernetes-Konzepten zusammenspielen. Hierfür können Sie CiliumNetworkPolicy einsetzen. Dabei handelt es sich um eine Custom Resource Definition (CRD), die Domain-Namen zu IP-Adressen auflöst und Traffic auf der eBPF-basierten Cilium-Netzwerkschicht blockiert oder zulässt. (Siehe zwei Beiträge im DoiT Blog.) Die CRD ist Kubernetes-aware, sodass Sie Pods nach Namespace unterscheiden können: einige mit Zugriff auf die externe API, andere ohne. Eine weitere CRD, CiliumClusterwideNetworkPolicy, leistet dasselbe, ihre Konfiguration gilt jedoch namespaceübergreifend für den gesamten Cluster.
Diese Lösung erhöht die Komplexität Ihres Clusters, da eine zusätzliche Cilium-Netzwerkschicht hinzukommt. Wie in den Cilium Docs angekündigt, soll bald gelten: "all of the functionality will be merged into the standard resource format and this CRD will no longer be required." Eine Standardspezifikation gibt es noch nicht, doch die Kubernetes Networking Special Interest Group arbeitet derzeit daran.
Istio
Den größten Funktionsumfang bietet das Istio Service Mesh. Istio kontrolliert den Traffic vollständig und erlaubt es, jeden Egress zu blockieren – außer dort, wo er in einer ServiceEntry definiert ist. Mit der Angabe resolution: DNS weisen Sie Istio an, sich nicht auf die IP-Adresse zu verlassen, mit der sich der Client (ein Pod) verbindet, sondern den Domain-Namen regelmäßig per DNS aufzulösen. Der Istio-Service lässt sich gezielt nur den Namespaces zugänglich machen, die Sie auswählen. Istio bietet die größte Kontrolle, bringt aber mehr Komplexität als Cilium mit sich – mit der vollen Leistungsfähigkeit und Funktionalität einer Service-Mesh-Schicht.
Was tun?
Sie haben eine ganze Reihe von Optionen: das bewährte Squid (oder einen anderen Reverse Web Proxy); die neuen Managed Services Google Firewall FQDN Objects und AWS Network Firewall; das HTTP-proxying Secure Web Gateway sowie zusätzlich die Kubernetes-aware Lösungen Cilium und Istio.
Wenn Sie eine stabile, verwaltete Lösung möchten, empfehle ich die neue Google Firewall (sobald sie ausgereift ist) und AWS Network Firewall (sofern das Pricing ins Budget passt). Brauchen Sie Kontrolle auf Ebene von Kubernetes-Namespaces, ist die einfachste Lösung eine Cilium-CRD; sobald der Kubernetes-native Standard verfügbar ist, sollten Sie auf diesen wechseln.