Einrichtung von Berechtigungen für das Design

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

Die folgenden Designs werden zwar empfohlen, müssen aber nicht genau so umgesetzt werden. Jede GDC-Umgebung hat individuelle Anforderungen und Überlegungen, die von Fall zu Fall erfüllt werden müssen.

Identitätsanbieter pro Organisation konfigurieren

Ein Operator 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-Umgebung zu verwalten.

Es kann vorkommen, dass Ihr Unternehmen mehrere Abteilungen mit separaten Organisationen hat und jede Organisation zur Authentifizierung eine Verbindung zum selben Identitätsanbieter herstellt. In diesem Fall liegt es in Ihrer Verantwortung, die Kombination von Berechtigungen zu verstehen und zu prüfen, die ein Nutzer in den verschiedenen Organisationen hat. Achten Sie darauf, dass ein Nutzer mit Berechtigungen in mehreren Organisationen die Anforderungen für die Trennung von Arbeitslasten in verschiedenen Organisationen nicht verletzt.

Alternativ kann es vorkommen, dass verschiedene Nutzergruppen unterschiedliche Identitätsanbieter verwenden, um sich in einer einzelnen Organisation zu authentifizieren, z. B. wenn mehrere Anbieterteams in einer einzelnen Organisation zusammenarbeiten. Überlegen Sie, ob die Konsolidierung von Nutzeridentitäten in einem einzelnen Identitätsanbieter oder die Verwendung separater Identitätsanbieter am besten zu Ihrem Ansatz für die Identitätsverwaltung passt.

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

GDC verwendet Ihre IAM-Plattform zur 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 potenziell auf sensible Ressourcen zugreifen können.

Verwaltete Dienste und Marketplace-Dienste einschränken

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

Wenn Sie den Zugriff auf Dienste aus Projekten verweigern möchten, wenden Sie Gatekeeper-Einschränkungen auf die benutzerdefinierte Ressourcendefinition eines Dienstes und eine Liste von Namespaces an. Der Ansatz zum Verweigern des Zugriffs mit Gatekeeper gilt für verwaltete Dienste und Marketplace-Dienste.

kubeconfig-Dateien für mehrere Cluster verwalten

Für verschiedene betriebliche 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-Pod-Ressource in einem Kubernetes-Cluster aus.

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

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

Best Practices für Kubernetes-Dienstkonten

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

  • Laden Sie keine persistenten Anmeldedaten für Dienstkonten herunter, um sie außerhalb von GDC zu verwenden.
  • 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 Dienstkonto-Tokenprojektion Ihrer Arbeitslasten fest.
  • Rotieren Sie regelmäßig die Anmeldedaten für Dienstkonten.

Prinzip der geringsten Berechtigung beachten

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

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

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

Prüfen Sie die in Ihrer Organisation gewährten Rollen und führen Sie Audits auf übermäßige Berechtigungen durch. Sie müssen sicherstellen, dass die gewährten Rollen für einen einzelnen Nutzer erforderlich sind, um seine Arbeit zu erledigen, und dass Kombinationen von Rollen in verschiedenen Projekten nicht zu einem Eskalations- oder Exfiltrationsrisiko führen.

Wenn Ihr Unternehmen mehrere Organisationen verwendet, empfehlen wir nicht, dass ein einzelner Nutzer hochprivilegierte Rollen in mehreren Organisationen hat, da dies den Grund für die Trennung von Organisationen zunichtemachen könnte.