Sicherung des Zugriffs auf die GKE-Steuerungsebene mithilfe DNS-basierter Endpunkte

Wir alle schätzen private Google Kubernetes Engine (GKE)-Cluster. Die Absicherung Ihrer Steuerungsebene, damit diese nicht dem öffentlichen Internet ausgesetzt ist, gehört zu den Grundlagen der Kubernetes-Sicherheit. Sobald Sie jedoch versuchen, Ihre CI/CD-Pipeline anzubinden – beispielsweise GitHub Actions, die auf gehosteten Runners ausgeführt werden –, stoßen Sie auf eine klassische architektonische Hürde.

Die von GitHub gehosteten Runner nutzen einen riesigen, sich dynamisch verändernden Pool öffentlicher IP-Adressen. Bislang mussten Sie sich zwischen zwei unangenehmen Optionen entscheiden:

Während Proxy-Architekturen für Tools, die nativ in Ihre Google Cloud-Umgebung eingebettet sind, hervorragend funktionieren, verursacht deren Einrichtung für externe CI/CD-Plattformen unnötigen betrieblichen Aufwand und Wartungsrückstände.

Glücklicherweise gibt es heutzutage eine bessere und optimierte Lösung! Durch den Einsatz von GKE DNS-basierten Endpunkten in Verbindung mit Workload Identity Federation (WIF) können Sie Ihren externen GitHub-Actions-Workflows sicheren, direkten Zugriff auf die Steuerungsebene Ihres privaten Clusters gewähren, ohne auch nur die geringste Proxy-Infrastruktur unterhalten zu müssen.

Der Übergang von Netzwerksicherheit zu IAM-gesteuerter Sicherheit

GKE-DNS-basierte Endpunkte verändern grundlegend die Art und Weise, wie externer Datenverkehr von der GKE-Steuerungsebene verarbeitet wird. Anstatt sich ausschließlich auf IP-Whitelisting auf Netzwerkebene über „Master Authorized Networks“ zu stützen, führt diese Funktion einen rein DNS-basierten, durch IAM gesicherten Endpunkt (*.gke.goog) ein.

Wenn Sie externen Datenverkehr über einen DNS-Endpunkt zulassen, ist dieser Endpunkt zwar technisch über das Internet auflösbar, doch der Netzwerkzugang allein reicht nicht aus. Jede einzelne Anfrage, die bei diesem Endpunkt eingeht, muss explizit über Google Cloud IAM authentifiziert und autorisiert werden.

Auf diese Weise können Sie einen „Merge-before-Apply“-GitOps-Workflow direkt über die von GitHub gehosteten Standard-Runner sicher ausführen:

Strikte Prinzipien der minimalen Berechtigungen: Der Runner verfügt lediglich über kurzlebige Token mit streng begrenzten IAM-Berechtigungen zur Verwaltung des Clusters.

Architekturplan

In einer streng gesicherten Landing Zone für Unternehmen dient der DNS-basierte Endpunkt als sichere, isolierte Verwaltungsverbindung zwischen Ihren externen Steuerungsebenen und Ihren privaten Workloads.

So lässt sich das System in eine umfassende Sicherheitsarchitektur integrieren:

‌

Implementierung von DNS-Endpunkten mit Terraform

Die Umsetzung dieser Architektur ist unkompliziert. Um den Überblick zu bewahren, zeigt der folgende produktionsreife Codeausschnitt ausschließlich die Konfiguration, die erforderlich ist, um die DNS-basierte Endpunkt- und die Verschlüsselung von Geheimnissen auf Anwendungsebene zu aktivieren.

Die übrigen Standarddefinitionen für den GKE-Cluster und den Knotenpool lassen wir vorerst außer Acht. In Ihrem GKE-Terraform-Modul müssen Sie den Block „control_plane_endpoints_config“ innerhalb der Ressource „google_container_cluster“ konfigurieren, wobei Ihr Cluster im privaten Netzwerk verbleiben muss.

resource "google_container_cluster" "primary" {
  # ... other configurations/settings ...

  # Isolate your node infrastructure strictly inside the private network
  private_cluster_config {
    enable_private_nodes    = true
    enable_private_endpoint = true
    
    # Use your own custom private /28 CIDR range here
    master_ipv4_cidr_block  = var.master_ipv4_cidr_block 
  }

  ### WHERE THE MAGIC HAPPENS ###
  
  # Leave out the network-level IP whitelisting entirely (MAN).
  # No more maintaining brittle, shifting lists of public CI/CD runner IPs.
  master_authorized_networks_config {}

  # Expose a public, cryptographically IAM-gated DNS endpoint.
  # This allows authenticated external platforms (like GitHub Actions) to safely reach the cluster API using identity verification instead of an IP address.
  control_plane_endpoints_config {
    dns_endpoint_config {
      allow_external_traffic = true
    }
  }

  # ... other configurations/settings ...
}

Wichtiger Sicherheitshinweis

DNS-basierte Endpunkte machen Bastion-Hosts und umfangreiche IP-Zulassungslisten überflüssig, verlagern jedoch gleichzeitig Ihre Sicherheitsgrenze von der Netzwerkschicht auf die Identitätsschicht.

Bei „Master Authorized Networks“ (MAN) konnten nur vertrauenswürdige IP-Adressen auf die Steuerungsebene zugreifen. Bei DNS-basierten Endpunkten wird der Zugriff stattdessen durch IAM und Workload Identity Federation (WIF) geschützt.

Das bedeutet, dass Ihre WIF-Konfiguration von entscheidender Bedeutung ist. Eine falsch konfigurierte WIF-Bindung oder zu weit gefasste IAM-Berechtigungen könnten unbeabsichtigt den Zugriff auf den Cluster ermöglichen.

Um die Sicherheit dieser Konfiguration zu gewährleisten:

Bei korrekter Konfiguration bietet dies ein robustes Zero-Trust-Modell ohne den betrieblichen Aufwand einer Proxy-Infrastruktur.

Zusammenfassung der Leistungen

Indem Sie Ihre Strategie für den privaten GKE-Zugriff durch DNS-basierte Endpunkte und zusätzliche Sicherheitsmaßnahmen modernisieren, erreichen Sie eine Zero-Trust-Architektur ohne betriebliche Probleme:

Echte Zero-Trust-Sicherheit: Perimetersicherheit ist anfällig. Die Umstellung Ihrer Sicherheitsstrategie auf kryptografisch validierte Identitäten (OIDC + IAM) gewährleistet, dass ein Angreifer, selbst wenn er den DNS-Namen Ihres Clusters herausfindet, ohne gültige Cloud-Anmeldedaten keinen Zugriff darauf erlangen kann.

Nützliche Links

Sind Sie daran interessiert, die Workload Identity Federation (WIF) mit GitHub Actions einzurichten?

Sind Sie an einem weiteren sicheren Ansatz unter Verwendung eines IAP-Proxys interessiert?