Auf dieser Seite wird beschrieben, wie Sie einen OAuth-Client für eine andere Anwendung in Ihrer Organisation freigeben.
Übersicht
Wenn Sie OAuth-Clients für mehrere Projekte freigeben, verwenden Sie einen einzelnen benutzerdefinierten OAuth-Client für mehrere mit 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.
Bei der Konfiguration 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:
- Ermöglicht nur den Zugriff für Nutzer in Ihrer Organisation (interne Nutzer)
- Zeigt Google Cloud auf dem Zustimmungsbildschirm das Branding von Google anstelle des Brandings Ihrer Organisation
Benutzerdefinierter OAuth-Client: Sie erstellen und verwalten diesen selbst. Diese Option bietet folgende Vorteile:
- Kann für mehrere Anwendungen freigegeben 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 für eine einzelne 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 (ohne 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 Anwendungen, die keine Browser sind, bei Ihren mit IAP geschützten Ressourcen authentifizieren können. So können Skripts, automatisierte Jobs und Back-End-Dienste sicher auf Ihre geschützten Anwendungen zugreifen, ohne dass sich Nutzer interaktiv anmelden müssen.
Sie können diese Authentifizierungseinstellungen auf jeder Ebene Ihrer Ressourcen Hierarchie anwenden: Organisation, Ordner oder Projekt.
Implementierungsschritte finden Sie im Leitfaden zur programmatischen Authentifizierung und in der Dokumentation zur Verwaltung der IAP-Einstellungen.
gcloud
Bereiten Sie eine Einstellungsdatei mit Ihren OAuth-Client-IDs vor:
cat << EOF > SETTINGS_FILENAME access_settings: oauth_settings: programmatic_clients: [clientId1, clientId2, ..] EOFWenden Sie die Einstellungen mit dem
gcloud iap settings setBefehl 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=SERVICEWobei:
- 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,organizationoderfolder) - SERVICE: Der Dienstname (optional für
computeoderapp-engineRessourcentypen) - VERSION: Der Versionsname (nicht anwendbar für
compute, optional fürapp-engine)
API
Bereiten Sie eine JSON-Datei mit den Einstellungen vor:
cat << EOF > iap_settings.json { "access_settings": { "oauth_settings": { programmatic_clients: [clientId1, clientId2, ..] } } } EOFRufen Sie den Ressourcennamen ab:
gcloud iap settings get \ [--organization=ORGANIZATION | --folder=FOLDER | --project=PROJECT] \ [--resource-type=RESOURCE_TYPE] \ [--service=SERVICE] \ [--version=VERSION]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,organizationoderfolder) - SERVICE: Der Dienstname (optional für
computeoderapp-engineRessourcentypen) - VERSION: Der Versionsname (nicht anwendbar für
compute, optional fürapp-engine)
Melden Sie sich nach der Konfiguration mit einer der konfigurierten OAuth-Client-IDs in der Anwendung an. Weitere Informationen finden Sie unter Programmatische Authentifizierung.
Browserzugriff
Wenn IAP Ihre Client-ID und Ihren Clientschlüssel über die Google Cloud Konsole verwenden soll, folgen Sie der Anleitung unter:
- OAuth-Client für Compute Engine konfigurieren (Compute Engine)
- OAuth-Client für Google Kubernetes Engine (GKE) konfigurieren
- OAuth-Client für App Engine konfigurieren
- OAuth-Client für Cloud Run konfigurieren
Risiken
Die Freigabe eines Clients für mehrere 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, wird ein Single Point Of Failure erstellt. 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 steuern:
- Implementieren Sie geeignete Zugriffssteuerungen, um versehentliche Änderungen oder Löschungen zu verhindern.
- Beschränken Sie den Zugriff auf OAuth-Clients mit den
clientauthconfig.clients.*Berechtigungen - Verwenden Sie Google Cloud Audit-Logs, um Administratoraktivitäten im Zusammenhang mit OAuth-Clients zu verfolgen.
Dies ist in erster Linie ein Betriebsrisiko und kein Sicherheitsrisiko. Mit geeigneten Zugriffssteuerungen und Monitoring überwiegen die Vorteile der gemeinsamen Nutzung von OAuth-Clients in Bezug auf Komfort und Verwaltung in der Regel dieses Risiko.
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 unterscheiden, ob Tokens von Ihrer Anwendung oder aus einem gehackten Clientschlüssel erstellt wurden.
So können Sie dieses Risiko reduzieren:
- Schützen Sie Clientschlüssel wie Passwörter und speichern Sie sie niemals als Klartext.
- Implementieren Sie eine sichere Verwaltung von Anmeldedaten mit Secret Manager.
- Überwachen Sie den Zugriff auf Ihre IAP-Ressourcen mit Cloud-Audit-Logging.
- Ein gehackter Clientschlüssel wirkt sich nur auf die Authentifizierung aus, nicht auf die Autorisierung für den Zugriff auf Ressourcen. Wenn Sie vermuten, dass Ihr Clientschlüssel gehackt wurde, setzen Sie ihn sofort zurück.
Für den programmatischen Zugriff auf mit IAP geschützte Ressourcen sollten Sie die JWT-Authentifizierung mit Dienstkonten verwenden, anstatt OAuth-Clientschlüssel für einzelne Nutzer freizugeben. Dieser Ansatz bietet eine bessere Sicherheitsisolation und gleichzeitig die Vorteile eines freigegebenen OAuth-Clients für Ihre Anwendungen.
Überlegungen zum Umfang der Berechtigungen
Wenn Sie OAuth-Clients freigeben, verwenden alle Anwendungen dieselben Berechtigungsbereiche. Für IAP sind nur openid und email erforderlich. Dieses Risiko ist an sich nicht bedeutend, aber es ist wichtig, Folgendes zu wissen:
- OAuth wird in IAP nur für die Authentifizierung (Überprüfung der Identität) verwendet. Die Autorisierung (Ressourcenzugriff) wird separat über IAM-Richtlinien verwaltet.
- Auch wenn Anmeldedaten für die Authentifizierung kompromittiert werden, benötigt ein Angreifer weiterhin die entsprechenden IAM-Berechtigungen, um auf geschützte Ressourcen zuzugreifen.
- Wenn Sie den Client auf die erforderlichen Bereiche
openidundemailbeschränken, können Sie die potenziellen Auswirkungen auf die Sicherheit begrenzen.