Nutzung von Dienstkonten einschränken

Im Resource Manager sind Einschränkungen verfügbar, mit denen Sie in Organisationsrichtlinien die Nutzung von IAM-Dienstkonten (Identity and Access Management) begrenzen können.

Viele dieser Einschränkungen bestimmen, ob Dienstkonten und andere Ressourcen auf bestimmte Weise erstellt oder konfiguriert werden können. Diese Einschränkungen sind nicht rückwirkend. Sie haben keinen Einfluss auf bereits erstellte und konfigurierte Dienstkonten.

Hinweise

Sie müssen die Berechtigung haben, Organisationsrichtlinien zu ändern, um Einschränkungen festzulegen. Die Rolle orgpolicy.policyAdmin hat beispielsweise die Berechtigung zum Festlegen von Einschränkungen für Organisationsrichtlinien. Lesen Sie unter Einschränkungen verwenden, wie Richtlinien auf Organisationsebene verwaltet werden.

Boolesche Einschränkungen

Die folgenden Einschränkungen sind Typen von boolean constraint, die auf wahr oder falsch gesetzt sind.

Standarddienstberechtigungen für Standarddienstkonten deaktivieren

Einige Google Cloud-Dienste erstellen automatisch Standarddienstkonten. Wenn ein Standarddienstkonto erstellt wird, erhält es automatisch die Rolle "Bearbeiter" (roles/editor) für Ihr Projekt.

Zur Verbesserung der Sicherheit empfehlen wir Ihnen dringend, die automatische Rollenzuweisung zu deaktivieren. Verwenden Sie die boolesche Einschränkung iam.automaticIamGrantsForDefaultServiceAccounts, um die automatische Rollenzuweisung zu deaktivieren.

Erstellen von Dienstkonten deaktivieren

Sie können die boolesche Einschränkung iam.disableServiceAccountCreation verwenden, um die Erstellung neuer Dienstkonten zu deaktivieren. Auf diese Weise können Sie die Verwaltung von Dienstkonten zentralisieren, ohne die anderen Projektberechtigungen Ihrer Entwickler einzuschränken.

Wenn Sie diese Einschränkung in einem Projekt erzwingen, können einige Google Cloud-Dienste nicht automatisch Standarddienstkonten erstellen. Wenn das Projekt Arbeitslasten ausführt, für die eine Identitätsübernahme des Dienstkontos erforderlich ist, enthält das Projekt möglicherweise kein Dienstkonto, das von der Arbeitslast verwendet werden kann. Zur Behebung dieses Problems können Sie die Identitätswechsel zwischen Dienstkonten über Projekte hinweg aktivieren. Wenn Sie dieses Feature aktivieren, können Sie Dienstkonten in einem zentralisierten Projekt erstellen und diese Dienstkonten dann an Ressourcen in anderen Projekten anhängen.

Weitere Informationen zum Organisieren von Dienstkonten finden Sie unter Wo werden Dienstkonten erstellt?.

Erstellen von Dienstkontoschlüsseln deaktivieren

Sie können die boolesche Einschränkung iam.disableServiceAccountKeyCreation verwenden, um die Erstellung neuer externer Dienstkontoschlüssel zu deaktivieren. Damit können Sie die Verwendung von nicht verwalteten, langfristigen Anmeldedaten für Dienstkonten steuern. Wenn diese Einschränkung festgelegt ist, können keine von Nutzern verwalteten Anmeldedaten für Dienstkonten in Projekten erstellt werden, die von der Einschränkung betroffen sind.

Hochladen von Dienstkontoschlüsseln deaktivieren

Mit der booleschen Einschränkung iam.disableServiceAccountKeyUpload können Sie das Hochladen externer öffentlicher Schlüssel in Dienstkonten deaktivieren. Wenn diese Einschränkung festgelegt ist, können Nutzer keine öffentlichen Schlüssel in Dienstkonten in Projekten hochladen, die von der Einschränkung betroffen sind.

Anhängen von Dienstkonten an Ressourcen in anderen Projekten deaktivieren

Jedes Dienstkonto befindet sich in einem Projekt. Sie können die boolesche Einschränkung iam.disableCrossProjectServiceAccountUsage verwenden, um zu verhindern, dass Dienstkonten in einem Projekt an Ressourcen in anderen Projekten angehängt werden.

Wenn Sie die Verwendung von Dienstkonten über Projekte hinweg zulassen möchten, finden Sie weitere Informationen unter Identitätswechsel für Dienstkonten über Projekte hinweg aktivieren.

Entfernen von Projektsperren einschränken, wenn Dienstkonten projektübergreifend verwendet werden

Wenn Sie zulassen, dass die Dienstkonten eines Projekts an Ressourcen in anderen Projekten angehängt werden, fügt IAM eine Projektsperre hinzu, die das Löschen des Projekts verhindert. Standardmäßig kann jeder, der die Berechtigung resourcemanager.projects.updateLiens für das Projekt hat, die Sperre löschen.

Wenn Sie die boolesche Einschränkung iam.restrictCrossProjectServiceAccountLienRemoval erzwingen, können Hauptkonten nur dann gelöscht werden, wenn sie die Berechtigung resourcemanager.projects.updateLiens für die Organisation haben.

Wir empfehlen, diese Einschränkung zu erzwingen, wenn eines Ihrer Projekte den projektübergreifenden Identitätswechsel für Dienstkonten zulässt.

Workload Identity-Clustererstellung deaktivieren

Sie können die boolesche Einschränkung iam.disableWorkloadIdentityClusterCreation verwenden, um zu verlangen, dass bei neuen Google Kubernetes Engine-Clustern die Funktion Workload Identity bei ihrer Erstellung deaktiviert ist. Wenn Sie den Zugriff auf Dienstkonten in Ihrer Organisation streng kontrollieren möchten, möchten Sie möglicherweise zusätzlich zur Erstellung von Dienstkonten und Dienstkontenschlüsseln die Workload Identity deaktivieren.

Bestehende GKE-Cluster mit aktivierter Workload Identity sind nicht betroffen und funktionieren weiterhin wie gewohnt.

Boolesche Einschränkung erzwingen

Console

So legen Sie eine Organisationsrichtlinie fest, die eine Einschränkung erzwingt, um die Verwendung von Dienstkonten zu beschränken:

  1. Wechseln Sie in der Google Cloud Console zur Seite Organisationsrichtlinien.

    Zu den Organisationsrichtlinien

  2. Wählen Sie in der Projektauswahl die Organisation aus, für die Sie die Nutzung des Dienstkontos einschränken möchten.

  3. Klicken Sie auf eine der booleschen Einschränkungen für die Dienstkontonutzung auf dieser Seite.

  4. Klicken Sie auf Richtlinie verwalten.

  5. Wählen Sie unter Gilt für die Option Richtlinie der übergeordneten Ressource überschreiben aus.

  6. Klicken Sie auf Regel hinzufügen.

  7. Wählen Sie unter Erzwingung die Option An aus.

  8. Klicken Sie auf Richtlinie festlegen, um die Richtlinie zu erzwingen.

gcloud

Richtlinien können über die Google Cloud CLI festgelegt werden.

Führen Sie den folgenden Befehl aus, um die Verwendung des Dienstkontos einzuschränken:

gcloud resource-manager org-policies enable-enforce \
    --organization 'ORGANIZATION_ID' \
    BOOLEAN_CONSTRAINT

Dabei ist BOOLEAN_CONSTRAINT die boolesche Einschränkung, die Sie erzwingen möchten.

Zur Deaktivierung der Erzwingung kann der gleiche Befehl mit

disable-enforce
ausgeführt werden.

Weitere Informationen zur Verwendung von Einschränkungen in Organisationsrichtlinien finden Sie unter Einschränkungen verwenden.

Beispielrichtlinie mit boolescher Einschränkung

Das folgende Code-Snippet zeigt eine Organisationsrichtlinie, die die boolesche Einschränkung iam.disableServiceAccountCreation erzwingt, die verhindert, dass Dienstkonten erstellt werden:

name: organizations/012345678901/policies/iam.disableServiceAccountCreation
spec:
  rules:
  - enforce: true

Listeneinschränkungen

Die folgenden Einschränkungen sind Typen von Listeneinschränkungen, für die eine Liste von Werten festgelegt wird.

Lebensdauer von OAuth 2.0-Zugriffstokens verlängern

Sie können ein OAuth 2.0-Zugriffstoken erstellen, das kurzlebige Anmeldedaten für ein Dienstkonto bereitstellt. Standardmäßig beträgt die maximale Lebensdauer eines Zugriffstokens 1 Stunde (3.600 Sekunden). Sie können die maximale Lebensdauer jedoch auf 12 Stunden verlängern. Identifizieren Sie dazu zuerst die Dienstkonten, bei denen eine verlängerte Lebensdauer für Zugriffstoken festgelegt werden soll. Fügen Sie diese Dienstkonten danach einer Organisationsrichtlinie hinzu, in der die Listeneinschränkung constraints/iam.allowServiceAccountCredentialLifetimeExtension enthalten ist.

Lebensdauer von Dienstkontoschlüsseln begrenzen

Mit einem Dienstkontoschlüssel können Sie eine Anfrage als Dienstkonto authentifizieren. Standardmäßig laufen Dienstkontoschlüssel nie ab. Sie können diese Standardeinstellung ändern, indem Sie eine Ablaufzeit für alle neu erstellten Schlüssel in Ihrem Projekt, Ordner oder Ihrer Organisation festlegen.

Verwenden Sie zum Festlegen einer Ablaufzeit die Listeneinschränkung constraints/iam.serviceAccountKeyExpiryHours, um die Anzahl der Stunden anzugeben, für die ein neu erstellter Schlüssel gültig ist. Nach diesem Zeitraum läuft der Dienstkontoschlüssel ab und Sie können ihn nicht mehr verwenden.

Diese Listeneinschränkung akzeptiert die folgenden ALLOW-Werte. Sie akzeptiert keine DENY-Werte. Es hat sich bewährt, die kürzeste Ablaufzeit zu verwenden, die Ihren Anforderungen entspricht:

  • 1h: 1 Stunde
  • 8h: 8 Stunden
  • 24h: 24 Stunden (1 Tag)
  • 168h: 168 Stunden (7 Tage)
  • 336h: 336 Stunden (14 Tage)
  • 720h: 720 Stunden (30 Tage)
  • 1440h: 1.440 Stunden (60 Tage)
  • 2160h: 2.160 Stunden (90 Tage)

Die Einschränkung constraints/iam.serviceAccountKeyExpiryHours kann nicht mit einer übergeordneten Richtlinie zusammengeführt werden. Wenn Sie diese Einschränkung erzwingen möchten, müssen Sie die übergeordnete Richtlinie entweder ersetzen oder übernehmen.

Zulässige externe Identitätsanbieter angeben

Wenn Sie die Workload Identity-Föderation verwenden, mit der externe Identitäten auf Google Cloud-Ressourcen zugreifen können, können Sie angeben, welche externen Identitätsanbieter zulässig sind. Standardmäßig sind alle Anbieter zulässig. Verwenden Sie zum Festlegen eines Limits die Listeneinschränkung constraints/iam.workloadIdentityPoolProviders, um URIs für die zulässigen Anbieter in den folgenden Formaten anzugeben:

  • Amazon Web Services (AWS): https://sts.amazonaws.com

    Verwenden Sie die auf dieser Seite beschriebene Listeneinschränkung constraints/iam.workloadIdentityPoolAwsAccounts, um die zulässigen AWS-Konten zu begrenzen.

  • Microsoft Azure: https://sts.windows.net/azure-tenant-id

  • Andere Identitätsanbieter, die OpenID Connect (OIDC) unterstützen: Verwenden Sie den Aussteller-URI Ihres Identitätsanbieters.

Zulässige AWS-Konten angeben

Wenn Sie die Workload Identity-Föderation verwenden, mit der externe Identitäten auf Google Cloud-Ressourcen zugreifen können, können Sie angeben, welche AWS-Konten auf Ihre Ressourcen zugreifen dürfen. Standardmäßig können Arbeitslasten von jedem AWS-Konto auf Ihre Google Cloud-Ressourcen zugreifen. Wenn Sie begrenzen möchten, welche AWS-Konten zulässig sind, geben Sie mit der Listeneinschränkung constraints/iam.workloadIdentityPoolAwsAccounts eine Liste der zulässigen Konto-IDs an.

Gefährdete Dienstkontoschlüssel automatisch deaktivieren

Google Cloud erkennt gelegentlich, dass ein bestimmter Dienstkontoschlüssel offengelegt wurde. So kann beispielsweise ein Schlüssel in einem öffentlichen Repository erkannt werden. Verwenden Sie die Listeneinschränkung iam.serviceAccountKeyExposureResponse, um anzugeben, was Google Cloud mit diesen Schlüsseln macht.

Diese Listeneinschränkung akzeptiert die folgenden ALLOW-Werte. Sie akzeptiert keine DENY-Werte.

  • DISABLE_KEY: Wenn Google Cloud einen preisgegebenen Schlüssel erkennt, wird er automatisch deaktiviert.
  • WAIT_FOR_ABUSE: Google Cloud deaktiviert die offengelegten Schlüssel nicht proaktiv. Google Cloud kann die offengelegten Schlüssel jedoch trotzdem deaktivieren, wenn sie auf eine Weise verwendet werden, die sich nachteilig auf die Plattform auswirkt.

Wenn Google Cloud einen Schlüssel deaktiviert, enthalten die Audit-Logs das Hauptkonto gcp-compromised-key-response@system.gserviceaccount.com.

Es wird dringend empfohlen, diese Einschränkung auf DISABLE_KEY festzulegen. Wenn Sie diese Einschränkung auf WAIT_FOR_ABUSE festlegen, steigt das Risiko, dass gehackte Schlüssel missbräuchlich verwendet werden.

Wenn Sie die Einschränkung auf WAIT_FOR_ABUSE setzen, sollten Sie Ihre Sicherheitskontaktdaten unter Wichtige Kontakte prüfen und dafür sorgen, dass Ihre Sicherheitskontakte zeitnah auf Benachrichtigungen reagieren.

Die Einschränkung iam.serviceAccountKeyExposureResponse kann nicht mit einer übergeordneten Richtlinie zusammengeführt werden. Zum Erzwingen dieser Einschränkung müssen Sie die übergeordnete Richtlinie ersetzen.

Listeneinschränkung festlegen

Console

So legen Sie eine Organisationsrichtlinie fest, die eine Listeneinschränkung enthält:

  1. Wechseln Sie in der Google Cloud Console zur Seite Organisationsrichtlinien.

    Zu den Organisationsrichtlinien

  2. Klicken Sie am oberen Rand der Seite auf die Drop-down-Liste Organisation und wählen Sie Ihre Organisation aus.

  3. Klicken Sie auf die Einschränkung, die Sie hinzufügen möchten.

  4. Klicken Sie auf Richtlinie verwalten.

  5. Wählen Sie unter Gilt für die Option Richtlinie der übergeordneten Ressource überschreiben aus.

  6. Wählen Sie unter Richtlinienerzwingung die Option Mit übergeordneter Ressource zusammenführen aus, um diese Richtlinie mit vorhandenen Richtlinien in Ihrer Hierarchie zusammenzuführen.

  7. Klicken Sie auf Regel hinzufügen.

  8. Wählen Sie unter Richtlinienwerte die Option Benutzerdefiniert.

  9. Wählen Sie unter Richtlinientyp Zulassen aus.

  10. Geben Sie unter Benutzerdefinierte Werte den ersten Wert für die Listeneinschränkung ein.

    1. Wenn Sie weitere Werte hinzufügen möchten, klicken Sie auf Neuer Richtlinienwert, um weitere Zeilen zu erstellen, und fügen Sie jeder Zeile einen Wert hinzu.
  11. Klicken Sie auf Richtlinie festlegen, um die Richtlinie zu erzwingen.

gcloud

Richtlinien können über die Google Cloud CLI festgelegt werden:

gcloud resource-manager org-policies allow \
    CONSTRAINT_NAME \
    VALUE_1 [VALUE_N ...] \
    --organization=ORGANIZATION_ID \

Ersetzen Sie die folgenden Werte:

  • CONSTRAINT_NAME: Der Name der Listeneinschränkung. Beispiel: constraints/iam.allowServiceAccountCredentialLifetimeExtension
  • VALUE_1, VALUE_N...: Werte für die Listeneinschränkung.

Weitere Informationen zur Verwendung von Einschränkungen in Organisationsrichtlinien finden Sie unter Einschränkungen verwenden.

Beispielrichtlinie mit Listeneinschränkung

Das folgende Code-Snippet zeigt eine Organisationsrichtlinie, die die Listeneinschränkung iam.allowServiceAccountCredentialLifetimeExtension erzwingt, die die maximale Lebensdauer von OAuth 2.0-Zugriffstokens für die aufgeführten Dienstkonten verlängert:

name: organizations/012345678901/policies/iam.allowServiceAccountCredentialLifetimeExtension
spec:
  rules:
  - values:
      allowedValues:
      - SERVICE_ACCOUNT_ADDRESS

Fehlermeldungen

Erstellen von Dienstkonten deaktivieren

Wenn iam.disableServiceAccountCreation erzwungen wird, schlägt das Erstellen eines Dienstkontos fehl und folgende Fehlermeldung wird zurückgegeben:

FAILED_PRECONDITION: Service account creation is not allowed on this project.

Erstellen von Dienstkontoschlüsseln deaktivieren

Wenn iam.disableServiceAccountKeyCreation erzwungen wird, schlägt das Erstellen eines Dienstkontos fehl und folgende Fehlermeldung wird zurückgegeben:

FAILED_PRECONDITION: Key creation is not allowed on this service account.

Workload Identity-Clustererstellung deaktivieren

Wenn iam.disableWorkloadIdentityClusterCreation erzwungen wird, schlägt das Erstellen eines GKE-Clusters mit aktivierter Workload Identity mit dem folgenden Fehler fehl:

FAILED_PRECONDITION: Workload Identity is disabled by the organization
policy constraints/iam.disableWorkloadIdentityClusterCreation. Contact your
administrator to enable this feature.

Bekannte Fehler beheben

Standarddienstkonten

Durch Anwendung der Einschränkung iam.disableServiceAccountCreation wird die Erstellung von Dienstkonten in diesem Projekt verhindert. Diese Einschränkung betrifft auch Google Cloud-Dienste, die bei Aktivierung automatisch Standarddienstkonten im Projekt erstellen, wie zum Beispiel:

  • Compute Engine
  • GKE
  • App Engine
  • Dataflow

Wenn die Einschränkung iam.disableServiceAccountCreation angewendet wird, schlägt das Aktivieren dieser Dienste fehl, da ihre Standarddienstkonten nicht erstellt werden können.

So lösen Sie dieses Problem:

  1. Entfernen Sie vorübergehend die Einschränkung iam.disableServiceAccountCreation.
  2. Aktivieren Sie die gewünschten Dienste.
  3. Erstellen Sie gegebenenfalls weitere Dienstkonten.
  4. Wenden Sie die Einschränkung wieder an.