Berechtigungen für das Design einrichten

In diesem Dokument werden Best Practices für das Berechtigungsdesign in einer Air-Gap-Umgebung von Google Distributed Cloud (GDC) beschrieben. Dabei werden die folgenden Themen behandelt:

Die folgenden Designs werden zwar empfohlen, es ist aber nicht erforderlich, sie genau wie beschrieben zu verwenden. Für jedes GDC-Universum gelten individuelle Anforderungen und Überlegungen, die jeweils erfüllt werden müssen.

Identitätsanbieter pro Organisation konfigurieren

Ein Betreiber muss einen oder mehrere Identitätsanbieter pro Organisation konfigurieren. Ein Administrator stellt dann eine Verbindung zu einem Identitätsanbieter her, um Authentifizierungsdienste für Anwendungen in der GDC-Welt zu verwalten.

Es kann vorkommen, dass Ihr Unternehmen mehrere Abteilungen mit separaten Organisationen hat und jede Organisation zur Authentifizierung mit demselben Identitätsanbieter verbunden ist. In diesem Fall liegt es in Ihrer Verantwortung, die Kombination von Berechtigungen zu verstehen und zu prüfen, die ein Nutzer organisationsübergreifend hat. Achten Sie darauf, dass ein Nutzer mit Berechtigungen in mehreren Organisationen nicht gegen die Anforderungen für die Trennung von Arbeitslasten in separate Organisationen verstößt.

Alternativ kann es auch sein, dass verschiedene Nutzergruppen unterschiedliche Identitätsanbieter für die Authentifizierung innerhalb einer einzelnen Organisation verwenden, z. B. wenn mehrere Anbieterteams in einer einzelnen Organisation zusammenarbeiten. Überlegen Sie, ob es für die Identitätsverwaltung Ihres Unternehmens besser ist, Nutzeridentitäten in einem einzigen Identitätsanbieter zusammenzufassen oder separate Identitätsanbieter zu verwenden.

Multi-Faktor-Authentifizierung für Ihren Identitätsanbieter konfigurieren

GDC verwendet Ihre IAM-Plattform für die Authentifizierung, einschließlich zusätzlicher Sicherheitseinstellungen wie der Multi-Faktor-Authentifizierung. Es empfiehlt sich, die Multi-Faktor-Authentifizierung mit einem physischen Schlüssel für alle Nutzer zu konfigurieren, die möglicherweise auf vertrauliche Ressourcen zugreifen.

Verwaltete Dienste und Marketplace-Dienste einschränken

Möglicherweise möchten Sie bestimmte Projekte für bestimmte Dienste blockieren, um die potenzielle Angriffsfläche in einem Projekt zu begrenzen oder die Verwendung nicht genehmigter Dienste zu vermeiden. Verwaltete Dienste wie künstliche Intelligenz und maschinelles Lernen sind standardmäßig in jedem Projekt verfügbar. Im Vergleich zu verwalteten Diensten müssen Marketplace-Dienste zuerst für die Organisation aktiviert werden.

Um den Dienstzugriff von Projekten aus zu verweigern, wenden Sie Gatekeeper-Einschränkungen auf die benutzerdefinierte Ressourcendefinition eines Dienstes und eine Liste von Namespaces an. Die Methode zum Verweigern des Zugriffs mit Gatekeeper gilt für verwaltete Dienste und Marketplace-Dienste.

Kubeconfig-Dateien für mehrere Cluster verwalten

Für verschiedene operative Aufgaben ist eine Verbindung zu verschiedenen Clustern erforderlich. Sie führen beispielsweise Aufgaben wie das Binden einer IAM-Rolle an ein Projekt und das Bereitstellen einer Kubernetes-Ressource Pod in einem Kubernetes-Cluster aus.

Wenn Sie die GDC-Konsole verwenden, müssen Sie nicht wissen, welcher zugrunde liegende Cluster eine Aufgabe ausführt, da die GDC-Konsole die Low-Level-Vorgänge wie das Herstellen einer Verbindung zu einem Cluster abstrahiert.

Wenn Sie jedoch mit der gdcloud CLI oder kubectl CLI arbeiten, haben Sie möglicherweise mehrere kubeconfig-Dateien, um Ihre Aufgaben zu erledigen. Achten Sie darauf, dass Sie sich mit den kubeconfig-Anmeldedaten für den für Ihre Aufgabe geeigneten Cluster anmelden.

Best Practices für Kubernetes-Dienstkonten

Bei Kubernetes-Dienstkonten basiert die Autorisierung auf einem geheimen Token. Um das Risiko von Dienstkonto-Tokens zu minimieren, sollten Sie die folgenden Best Practices beachten:

  • Vermeiden Sie das Herunterladen von persistenten Dienstkontoanmeldedaten zur Verwendung außerhalb von GDC.
  • Achten Sie auf Kubernetes-Escalation-Pfade für Nutzer oder Dienstkonten, die Pods erstellen und bearbeiten können.
  • Legen Sie für das Feld expirationSeconds einen kurzen Zeitraum für die Dienstkontotoken-Projektion Ihrer Arbeitslasten fest.
  • Rotieren Sie die Anmeldedaten für Dienstkonten regelmäßig.

Prinzip der geringsten Berechtigung berücksichtigen

Berücksichtigen Sie das Prinzip der geringsten Berechtigung (Principle of Least Privilege, PoLP), wenn Sie Nutzern Rollenbindungen gewähren. Gemäß dem Prinzip der geringsten Berechtigung sollten Sie nur die Berechtigungen zuweisen, die zum Ausführen einer Aufgabe erforderlich sind.

Sie weisen einem Nutzer beispielsweise die Rolle „Project IAM Admin“ in einem einzelnen Projekt zu, damit dieser Nutzer die Berechtigung zum Zuweisen von Rollen in diesem Projekt delegieren kann. Dieser Nutzer weist dann anderen Entwicklern im Projekt detaillierte Rollen basierend auf den von ihnen verwendeten Diensten zu. Die Rolle „Project IAM Admin“ muss auf einen vertrauenswürdigen Lead beschränkt werden, da sie verwendet werden kann, um Berechtigungen zu eskalieren und sich selbst oder anderen zusätzliche Rollen im Projekt zuzuweisen.

Regelmäßig auf übermäßige Berechtigungen prüfen

Prüfen Sie die in Ihrer Organisation gewährten Rollen und achten Sie darauf, dass keine übermäßigen Berechtigungen vorhanden sind. Sie müssen dafür sorgen, dass die gewährten Rollen für die Erledigung der Aufgaben eines einzelnen Nutzers erforderlich sind und dass Kombinationen von Rollen in Projekten nicht zu einem Eskalierungs- oder Exfiltrationsrisiko führen.

Wenn Ihr Unternehmen mehrere Organisationen verwendet, empfehlen wir nicht, dass ein einzelner Nutzer in mehreren Organisationen Rollen mit hohen Berechtigungen hat, da dies möglicherweise gegen den Grund für die Trennung von Organisationen verstößt.