Dienstkontoschlüssel in Google Cloud sind Dateien — und Dateien werden kopiert, per E-Mail verschickt, versehentlich in Git eingecheckt oder auf Laptops vergessen. Verlässt jemand ein Team, weiß die Organisation oft nicht mehr, welche Schlüssel diese Person besaß. Für dieses als Secret Sprawl bekannte Problem bietet die Kubernetes-Welt GitOps-Operatoren an: Entwickler halten gar keine Cloud-Anmeldedaten mehr, der Controller authentifiziert sich an ihrer Stelle.
Googles Umsetzung heißt Kubernetes Config Connector. KCC läuft typischerweise in einem Google-Kubernetes-Engine-Cluster, beobachtet Konfigurationsdateien, die Google-Cloud-Ressourcen beschreiben, und ruft die passenden APIs auf. Wer einer Anwendung Lesezugriff auf einen Storage-Bucket geben will, reicht etwa eine IAMPolicyMember-Ressource ein. Weil KCC Infrastruktur über mehrere Projekte, Ordner oder eine ganze Organisation hinweg verwalten kann, erhält sein Dienstkonto häufig sehr weitreichende Rollen.
Der Bruch liegt darin, dass KCC jede Operation mit dem eigenen Konto ausführt — gleichgültig, wer die Ressource im Cluster eingereicht hat. Ein Angreifer mit begrenztem Cluster-Zugriff wendet eine YAML-Datei an, KCC liest sie und fordert die IAM-Änderung mit seinem eigenen, dazu berechtigten Dienstkonto an. Google Cloud akzeptiert die Anfrage. Damit kontrolliert der Angreifer die Organisation, ohne je ein Google-Cloud-Anmeldedatum besessen zu haben.
Der Grund sind zwei getrennte Autorisierungssysteme: Kubernetes sieht lediglich, dass im Cluster eine Ressource angelegt wird; Google Cloud sieht ausschließlich das KCC-Dienstkonto als Urheber der Änderung. Technisch ist das ein klassisches Confused-Deputy-Problem — eine Instanz mit weitreichenden Befugnissen führt Anweisungen von Nutzern mit geringeren Rechten aus, ohne zu prüfen, ob diese die Befugnis überhaupt nutzen dürften. Die Designentscheidung, Entwicklern Cloud-Anmeldedaten zu ersparen, kappt zugleich die Verbindung zwischen der Kubernetes-Identität und den in ihrem Namen genutzten Google-Cloud-Rechten.
Google antwortete auf ConfigConfusion, KCC arbeite wie vorgesehen. Der Administrator habe sich entschieden, KCC ein Dienstkonto auf Organisationsebene zu geben und Entwicklern das Anlegen von IAMPolicyMember-Ressourcen in KCC-verwalteten Namespaces zu erlauben; aus Googles Sicht sind das Konfigurationsentscheidungen. Das ist technisch zutreffend — nur macht die Dokumentation den Zusammenhang zwischen beiden Entscheidungen nicht deutlich. Die meisten Administratoren betrachten getrennt, welche Kubernetes-Ressourcentypen ein Team anlegen darf und was das KCC-Dienstkonto in Google Cloud kann. In KCC hängen beide zusammen.
Die naheliegende Korrektur — vor der Ausführung zu prüfen, ob der einreichende Kubernetes-Nutzer die entsprechende Google-Cloud-Berechtigung besitzt — scheitert am Modell selbst: Sie setzt voraus, dass dieser Nutzer eine Cloud-Identität hat, was KCC gerade vermeiden will. Zudem käme bei jedem Abgleichzyklus eine zusätzliche Autorisierungsprüfung samt weiterer API-Aufrufe hinzu. Googles empfohlene Gegenmaßnahmen zielen deshalb darauf, die über KCC verfügbare Autorität zu verringern, statt die Autorisierung pro Anfrage zu ändern.
Das Problem ist nicht auf KCC beschränkt: Jeder Infrastruktur-Operator, der Anweisungen von einer Identität entgegennimmt und sie über eine andere ausführt, kann dieselbe Lücke erzeugen. Verwundbar wird die Konfiguration erst durch die Kombination aus einem KCC-Dienstkonto mit organisationsweiten IAM-Rechten und breitem Schreibzugriff auf KCC-verwaltete Namespaces. Jede Bedingung für sich ist beherrschbar — zusammen ergeben sie einen Weg zur Rechteausweitung, der ohne jedes Google-Cloud-Anmeldedatum auskommt.
Beitrag gesponsert und verfasst von Varonis.