OAuth-Clients freigeben

Auf dieser Seite wird beschrieben, wie Sie einen OAuth-Client für eine andere Anwendung in Ihrer Organisation freigeben.

Übersicht

Wenn Sie OAuth-Clients zwischen Projekten freigeben, verwenden Sie einen einzelnen, benutzerdefinierten OAuth-Client für mehrere durch Identity-Aware Proxy (IAP) geschützte Anwendungen, anstatt für jede Anwendung einen neuen OAuth-Client zu erstellen. Dieser Ansatz vereinfacht die Verwaltung, insbesondere für Organisationen mit vielen Anwendungen.

Beim Konfigurieren von IAP können Sie einen von zwei OAuth-Clienttypen verwenden:

  • Von Google verwalteter OAuth-Client: IAP verwendet diesen standardmäßig automatisch. Für diese integrierte Option ist keine manuelle Clienterstellung erforderlich, sie hat jedoch zwei wichtige Einschränkungen:

    • Nur Nutzer innerhalb Ihrer Organisation (interne Nutzer) haben Zugriff.

    • Auf dem Zustimmungsbildschirm wird das Branding von Google Cloud anstelle des Brandings Ihrer Organisation angezeigt.

  • Benutzerdefinierter OAuth-Client: Sie erstellen und verwalten diesen selbst. Diese Option:

    • Kann von mehreren Anwendungen gemeinsam genutzt werden

    • Ermöglicht die Anpassung des Brandings auf dem Zustimmungsbildschirm

    • Unterstützt den Zugriff für externe Nutzer (außerhalb Ihrer Organisation)

Wenn Sie einen benutzerdefinierten OAuth-Client erstellen, können Sie ihn flexibel mit einer einzelnen Anwendung verwenden oder für mehrere Anwendungen freigeben. Die Freigabe eines benutzerdefinierten OAuth-Clients bietet mehrere Vorteile:

  • Reduziert den Verwaltungsaufwand für die Verwaltung mehrerer Clients

  • Vereinfacht die Aktivierung von IAP für Teammitglieder, die keinen Zugriff auf die Seite „Anmeldedaten“ haben sollten

  • Ermöglicht den programmatischen Zugriff (nicht über den Browser) auf Anwendungen, die durch IAP geschützt sind

Informationen zum Erstellen von OAuth-Clients finden Sie unter OAuth-Clients für IAP erstellen. Weitere Informationen zu von Google verwalteten OAuth-Clients finden Sie unter OAuth-Konfiguration anpassen, um IAP zu aktivieren.

Hinweis

Erstellen Sie einen neuen OAuth-Client, indem Sie die Schritte unter OAuth-Client erstellen ausführen, oder verwenden Sie einen vorhandenen OAuth-Client.

Programmatischer Zugriff

Konfigurieren Sie OAuth-Clients für den programmatischen Zugriff, damit sich nicht browserbasierte Anwendungen bei Ihren IAP-geschützten Ressourcen authentifizieren können. So können Skripts, automatisierte Jobs und Backend-Dienste sicher auf Ihre geschützten Anwendungen zugreifen, ohne dass sich ein Nutzer interaktiv anmelden muss.

Sie können diese Authentifizierungseinstellungen auf jeder Ebene Ihrer Ressourcenhierarchie anwenden: Organisation, Ordner oder Projekt.

Eine Anleitung zur Implementierung finden Sie im Leitfaden zur programmatischen Authentifizierung und in der Dokumentation zur Verwaltung von IAP-Einstellungen.

gcloud

  1. Bereiten Sie eine Einstellungsdatei mit Ihren OAuth-Client-IDs vor:

    cat << EOF > SETTINGS_FILENAME
  access_settings:
    oauth_settings:
      programmatic_clients: [clientId1, clientId2, ..]
EOF

  2. Wenden Sie die Einstellungen mit dem Befehl gcloud iap settings set an:

    gcloud iap settings set SETTINGS_FILENAME \
  [--organization=ORGANIZATION | --folder=FOLDER | --project=PROJECT] \
  [--resource-type=RESOURCE_TYPE] \
  [--service=SERVICE] \
  [--version=VERSION]

    Beispiele für Befehle:

    # Organization level
gcloud iap settings set SETTINGS_FILENAME --organization=ORGANIZATION

# Folder level
gcloud iap settings set SETTINGS_FILENAME --folder=FOLDER

# Project level (web resources)
gcloud iap settings set SETTINGS_FILENAME \
  --project=PROJECT \
  --resource-type=iap_web

# App Engine service in a project
gcloud iap settings set SETTINGS_FILENAME \
  --project=PROJECT \
  --resource-type=app-engine \
  --service=SERVICE

    Wobei:

    • SETTINGS_FILENAME: Die von Ihnen vorbereitete YAML-Datei.

    • ORGANIZATION: Die Organisations-ID

    • FOLDER: Die Ordner-ID

    • PROJECT: die Projekt-ID

    • RESOURCE_TYPE: Der IAP-Ressourcentyp (app-engine, iap_web, compute, organization oder folder)

    • SERVICE: Der Dienstname (optional für die Ressourcentypen compute oder app-engine)

    • VERSION: Der Versionsname (gilt nicht für compute, optional für app-engine)

API

  1. Bereiten Sie eine JSON-Datei mit den Einstellungen vor:

    cat << EOF > iap_settings.json
{
  "access_settings": {
    "oauth_settings": {
      programmatic_clients: [clientId1, clientId2, ..]
    }
  }
}
EOF

  2. Rufen Sie den Ressourcennamen ab:

    gcloud iap settings get \
  [--organization=ORGANIZATION | --folder=FOLDER | --project=PROJECT] \
  [--resource-type=RESOURCE_TYPE] \
  [--service=SERVICE] \
  [--version=VERSION]

  3. Aktualisieren Sie die Einstellungen mit dem Ressourcennamen:

    curl -X PATCH \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-d @iap_settings.json \
"https://iap.googleapis.com/v1/RESOURCE_NAME:iapSettings?updateMask=iapSettings.accessSettings.oauthSettings.programmaticClients"

    Wobei:

    • ORGANIZATION: Die Organisations-ID

    • FOLDER: Die Ordner-ID

    • PROJECT: die Projekt-ID

    • RESOURCE_TYPE: Der IAP-Ressourcentyp (app-engine, iap_web, compute, organization oder folder)

    • SERVICE: Der Dienstname (optional für die Ressourcentypen compute oder app-engine)

    • VERSION: Der Versionsname (gilt nicht für compute, optional für app-engine)

Melden Sie sich nach der Konfiguration mit einer der von Ihnen konfigurierten OAuth-Client-IDs in der Anwendung an. Weitere Informationen finden Sie unter Programmatische Authentifizierung.

Browserzugriff

Führen Sie die folgenden Schritte aus, um IAP die Verwendung Ihrer Client-ID und Ihres Secrets über dieGoogle Cloud Console zu ermöglichen:

Risiken

Die gemeinsame Nutzung eines Clients durch Ihre Anwendungen ist zwar praktisch, birgt aber auch Risiken. In diesem Abschnitt wird beschrieben, welche potenziellen Risiken bei der gemeinsamen Nutzung von Clients bestehen und wie sie reduziert werden können.

Single Point Of Failure

Wenn Sie einen OAuth-Client für viele Anwendungen verwenden, entsteht ein Single Point of Dependency. Wenn ein Client gelöscht oder falsch geändert wird, sind alle Anwendungen betroffen, die diesen Client verwenden. Gelöschte OAuth-Clients können innerhalb von 30 Tagen wiederhergestellt werden.

So können Sie dieses Betriebsrisiko effektiv managen:

Dies ist in erster Linie ein operatives Risiko und kein Sicherheitsrisiko. Bei entsprechender Zugriffssteuerung und Überwachung überwiegen die Vorteile der gemeinsamen OAuth-Clients in Bezug auf Komfort und Verwaltung in der Regel diese Überlegung.

Schwachstellen bei Clientschlüsseln

Damit Sie einen Client freigeben können, müssen Sie Ihren Clientschlüssel für andere Personen und Skripts freigeben. Dadurch sind Ihre Clientschlüssel einem größeren Risiko ausgesetzt, in falsche Hände zu gelangen. IAP kann nicht zwischen Tokens unterscheiden, die von Ihrer Anwendung erstellt wurden, und Tokens, die von einem geleakten Clientschlüssel erstellt wurden.

So können Sie dieses Risiko minimieren:

  • Clientschlüssel wie Passwörter schützen und niemals als Nur-Text speichern

  • Sichere Verwaltung von Anmeldedaten mit Secret Manager implementieren

  • Zugriff auf Ihre IAP-Ressourcen mit Cloud-Audit-Logging überwachen

  • Ein geleakter Clientschlüssel wirkt sich nur auf die Authentifizierung aus, nicht auf die Autorisierung für den Zugriff auf Ressourcen. Wenn Sie vermuten, dass Ihr Secret geleakt wurde, setzen Sie es sofort zurück.

Für den programmatischen Zugriff auf IAP-geschützte Ressourcen sollten Sie die JWT-Authentifizierung für Dienstkonten verwenden, anstatt OAuth-Clientschlüssel mit einzelnen Nutzern zu teilen. Dieser Ansatz bietet eine bessere Sicherheitsisolation und behält gleichzeitig die Vorteile eines freigegebenen OAuth-Clients für Ihre Anwendungen bei.

Überlegungen zum Berechtigungsumfang

Wenn OAuth-Clients gemeinsam genutzt werden, verwenden alle Anwendungen dieselben Berechtigungsbereiche. Für IAP sind openid und email die einzigen erforderlichen Bereiche. Dieser Aspekt ist an sich kein nennenswertes Risiko, aber es ist wichtig, Folgendes zu verstehen:

  • OAuth wird in IAP nur für die Authentifizierung (Identitätsprüfung) verwendet. Die Autorisierung (Ressourcenzugriff) wird separat über IAM-Richtlinien abgewickelt.

  • Selbst wenn Authentifizierungsdaten kompromittiert werden, benötigt ein Angreifer immer noch die entsprechenden IAM-Berechtigungen, um auf geschützte Ressourcen zuzugreifen.

  • Wenn Sie den Client auf die erforderlichen openid- und email-Bereiche beschränken, können Sie potenzielle Sicherheitsrisiken minimieren.