Häufig gestellte Fragen und Fehlerbehebung

Dieser Artikel enthält häufig gestellte Fragen zum Identity-Aware Proxy (IAP).

Welche Anwendungen kann ich mit IAP schützen?

IAP kann verwendet werden mit:

  • Anwendungen für die App Engine-Standardumgebung und die flexible App Engine-Umgebung
  • Compute Engine-Instanzen mit HTTP(S)-Load-Balancing-Back-End-Diensten
  • Google Kubernetes Engine-Container

Derzeit kann IAP nicht mit Cloud CDN verwendet werden.

Warum steht ein # am Ende meiner URL, nachdem ich mich bei meiner Anwendung angemeldet habe?

In einigen Browsern und unter bestimmten Bedingungen wird nach der Authentifizierung ein # an die URL angehängt. Das hat keine spezielle Bedeutung und verursacht beim Anmelden keine Probleme.

Warum wurde die Fragmentkennung #... am Ende meiner URL entfernt?

Aus Sicherheitsgründen wird dieser Teil einer URL während des Anmeldevorgangs entfernt. Nach dem Anmelden funktioniert das erneute Aufrufen Ihrer URL wie erwartet.

Warum schlagen meine Anfragen fehl und geben den Statuscode "405 Method Not Allowed" (Methode nicht zulässig) zurück?

Dies kann daran liegen, dass Ihren Anfragen keine Cookies angehängt werden. Bei JavaScript-Methoden werden Anfragen standardmäßig keine Cookies angehängt.

Die Vorgehensweise zum Hinzufügen von Cookies hängt von der Anfragemethode ab. Bei Anfragen, die mit einem XMLHttpRequest-Objekt gesendet werden, muss z. B. für das Attribut withCredentials der Wert true festgelegt sein und bei Anfragen, die mit der Fetch API gesendet werden, muss für die Option credentials der Wert include oder same-origin ausgewählt sein.

Informationen zur Behebung von Fehlern, die erst nach einer gewissen Zeit auftreten, finden Sie unter Cloud IAP-Sitzungen verwalten.

Warum erhalte ich anstelle des Statuscodes "HTTP 302 Redirect" (Weiterleitung) den Statuscode "HTTP 401 Unauthorized" (Nicht autorisiert)?

IAP antwortet mit dem Statuscode 302 Redirect, wenn ein Client für die Verarbeitung von Weiterleitungen konfiguriert ist. Damit Ihr Client Weiterleitungen verarbeiten kann, muss im Header der Anfrage unbedingt HTTP Accept="text/html,*/*" angegeben sein.

Warum lösen POST-Anfragen keine Weiterleitungen aus?

Stellen Sie für das Weiterleiten von Anfragen sicher, dass Aufrufe an IAP keine POST-Anfragen sind. Browser führen keine Weiterleitungen als Antwort auf POST-Anfragen aus. Daher antwortet IAP mit dem Statuscode 401 Unauthorized anstelle von 302 Redirect.

Damit IAP POST-Anfragen verarbeitet, müssen im Header der Anfrage entweder das ID-Token oder gültige Cookies übergeben werden.

Fügen Sie das ID-Token in einen Authorization: Bearer-Header ein, um eine authentifizierte Anfrage an die mit IAP gesicherte Ressource zu senden. Rufen Sie gültige Cookies durch Aktualisieren der Sitzung ab.

IAP erwartet die folgenden Cookie-Präfixe:

  • GCP_IAAP_AUTH_TOKEN_<random_string>
  • GCP_IAP_UID

Solche Cookies können problemlos mehrmals in einem Anfrage-Header enthalten sein.

Kann ich IAP verwenden, wenn ich die API deaktiviert habe?

Ja, der Zugriff auf mit IAP gesicherte Ressourcen funktioniert bei deaktivierter API. Sie können jedoch keine Änderungen an IAM-Berechtigungen vornehmen.

Wie kann ich verhindern, dass Nutzer mit der Rolle "Inhaber" IAP für TCP verwenden?

Vermeiden Sie das Zuweisen der Rolle "Inhaber" (roles/owner) so weit wie möglich. Die Rolle "Inhaber" gewährt umfassende Berechtigungen in Google Cloud. Durch Zuweisen detaillierter Rollen und Berechtigungen können Sie die Sicherheit Ihres Projekts erhöhen. Weitere Informationen finden sich in den Best Practices für IAM.

Wenn sich die Nutzung der Rolle "Inhaber" nicht einschränken lässt, können Sie IAP für TCP mithilfe von Firewallregeln blockieren.

Welche Domain verwendet IAP für TCP?

TCP-Tunneldaten von IAP über die Domain tunnel.cloudproxy.app. Diese Domain ist Eigentum von Google. Sie sollten dafür sorgen, dass Traffic zu dieser Domain nicht blockiert wird.

Wenn Sie den Traffic zu dieser Domain blockieren, können Sie IAP für TCP nicht verwenden. Möglicherweise erhalten Sie eine von mehreren Fehlermeldungen.

Wenn Sie gcloud verwenden, kann die Fehlermeldung folgendermaßen lauten

Error while connecting [[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed

Wenn Sie SSH über den Browser verwenden, wird die Fehlermeldung folgendermaßen lauten

Cloud Identity-Aware Proxy Failed

Es ist kein Fehlercode vorhanden.

Fehlercodes

In der folgenden Tabelle sind häufig auftretende Fehlercodes und Nachrichten aufgeführt, die beim Konfigurieren und Anwenden von IAP zurückgegeben werden.

Fehlercode oder Fehlermeldung Beschreibung Fehlerbehebung
Fehlercode 7 Ihre OAuth-Client-ID oder Secret-Werte sind leer. Prüfen Sie, ob Ihre Client-ID und Ihr Secret für Ihre Anwendung korrekt konfiguriert sind. Rufen Sie dazu die Seite "Anmeldedaten" auf. Wenn Ihre Client-ID und Ihr Secret offenbar korrekt konfiguriert sind, rufen Sie mit der Methode GET den aktuellen Status ab und setzen mit der Methode PATCH die Client-ID und das Secret zurück:
Compute Engine API: GET, PATCH
App Engine API: GET, PATCH
Fehlercode 9 Eine OAuth-Weiterleitung wurde nicht abgeschlossen. Dies ist ein interner Fehler, der zur Überprüfung in einem Log erfasst wurde.
Fehlercode 11 Ihre OAuth-Client-ID ist falsch konfiguriert. Prüfen Sie, ob Ihre Client-ID und Ihr Secret für Ihre Anwendung korrekt konfiguriert sind. Rufen Sie dazu die Seite "Anmeldedaten" auf. Wenn Ihre Client-ID und Ihr Secret offenbar korrekt konfiguriert sind, rufen Sie mit der Methode GET den aktuellen Status ab und setzen mit der Methode PATCH die Client-ID und das Secret zurück:
Compute Engine API: GET, PATCH
App Engine API: GET, PATCH
Fehlercode 13 Ihr OIDC-Token (OpenID Connect) ist ungültig. Prüfen Sie, ob die für IAP konfigurierte Client-ID gelöscht wurde. Rufen Sie dazu die Seite "Anmeldedaten" auf.
Fehlercode 429 Ihr Projekt hat den Minutengrenzwert für Anfragen überschritten. IAP-Projekte sind auf maximal 360.000 Anfragen pro Minute beschränkt. Wenn dieser Fehler auftritt, reduzieren Sie die Anzahl der Anfragen für Ihr Projekt. Sie können sich an den Google Cloud-Support wenden, wenn Sie weitere Fragen haben.
Fehlercode 4003 Dies kann bedeuten, dass die Instanz nicht den Port überwacht, zu dem Sie eine Verbindung herstellen möchten, oder dass die Firewall geschlossen ist. Eines dieser Probleme könnte auch dazu führen, dass der anfängliche Konnektivitätstest zur VM-Instanz fehlschlägt. Prüfen Sie, ob der Überwachungsvorgang auf der VM ausgeführt wird und ob der richtige Port überwacht wird. Prüfen Sie außerdem, ob Ihre Google Cloud-Firewall ordnungsgemäß konfiguriert ist, und öffnen Sie die Firewall auf dem Port, zu dem Sie eine Verbindung herstellen.
Fehlercode 4033 Entweder haben Sie keine Zugriffsberechtigung für die Instanz oder die Instanz ist nicht vorhanden oder wurde beendet. Prüfen Sie, ob die IAM-Rolle "Nutzer IAP-gesicherter Tunnel" auf die Ressource angewendet wurde, zu der Sie eine Verbindung herstellen. Rufen Sie dazu die Seite "Identity-Aware Proxy" auf.

Wenn Sie das Problem nicht lösen können, wenden Sie sich mit der Fehlerbeschreibung und der Antwort, die Sie beim Aufruf von GET an die API erhalten, an den Kundensupport. Den Clientschlüssel können Sie dafür aus der Antwort entfernen.