Häufige Probleme mit VPC Service Controls bei Google Cloud-Diensten beheben

Auf dieser Seite finden Sie Lösungen für Probleme, die bei der Verwendung eines Dienstes vonGoogle Cloud innerhalb eines VPC Service Controls-Perimeters auftreten können.

Cloud Build-Probleme

Für die Verwendung von Cloud Build-Ressourcen innerhalb eines VPC Service Controls-Perimeters gelten einige bekannte Einschränkungen. Weitere Informationen finden Sie unter Einschränkungen bei der Verwendung von VPC Service Controls mit Cloud Build.

Cloud Build-Dienstkonto kann nicht auf geschützte Ressourcen zugreifen

Cloud Build verwendet das Cloud Build-Dienstkonto, um Builds für Sie auszuführen. Wenn Sie einen Build in Cloud Build ausführen, wird er standardmäßig in einem Mandantenprojekt außerhalb Ihres Projekts ausgeführt.

Die Worker-VMs von Cloud Build, die Build-Ausgaben generieren, befinden sich außerhalb des Perimeters von VPC Service Controls, auch wenn sich Ihr Projekt innerhalb des Perimeters befindet. Damit Ihre Builds auf Ressourcen innerhalb des Perimeters zugreifen können, müssen Sie dem Cloud Build-Dienstkonto Zugriff auf den VPC Service Controls-Perimeter gewähren, indem Sie es entweder der Zugriffsebene oder der Regel für eingehenden Traffic hinzufügen.

Weitere Informationen finden Sie unter Dem Cloud Build-Dienstkonto Zugriff auf den Perimeter der VPC Service Controls gewähren.

Cloud Storage-Probleme

Ablehnungen bei Ausrichtung auf einen nicht vorhandenen Cloud Storage-Bucket für das Logging

Wenn der angegebene Logging-Bucket nicht vorhanden ist, lehnt VPC Service Controls den Zugriff mit der Verstoßursache RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER ab.

Sie können das Log der Zugriffsverweigerung anhand der eindeutigen VPC Service Controls-ID (vpcServiceControlUniqueIdentifier) aufrufen. Das folgende Beispiel zeigt ein Log mit der Verstoßursache RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER:

"serviceName": "storage.googleapis.com",
"methodName": "google.storage.buckets.update",
"resourceName": "projects/325183452875",
"metadata": {
  "violationReason": "RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER",
  ...
  "egressViolations": [
    {
      "sourceType": "Resource",
      "targetResource": "projects/0/buckets/this-bucket-does-not-exist",
      "source": "projects/325183452875/buckets/bucket-in-same-project",
      "servicePerimeter": "accessPolicies/875573620132/servicePerimeters/prod_perimeter"
    }]}

Wenn das Feld targetResource im Objekt egressViolations ein Ziel mit projects/0/buckets enthält, wird immer eine Ablehnung ausgelöst, da projects/0 nicht vorhanden ist und als außerhalb des Dienstperimeters betrachtet wird.

Verweigerungen beim Zugriff auf öffentliche Cloud Storage-Buckets von Google

Ein Dienstperimeter kann keine Projekte aus verschiedenen Organisationen enthalten. Ein Perimeter kann nur Projekte aus der übergeordneten Organisation enthalten. Es gibt bestimmte Einschränkungen, wenn Sie von Projekten innerhalb eines VPC Service Controls-Perimeters, der sich in einer anderen Organisation befindet, auf Cloud Storage-Buckets zugreifen möchten.

Ein typisches Beispiel ist der Zugriff auf Google-eigene Cloud Storage-Buckets. Da sich Ihr Projekt und das Google-Projekt, das den Ziel-Bucket enthält, nicht im selben Perimeter befinden, lehnt VPC Service Controls die Anfrage mit der Verstoßursache RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER ab.

Sie können dieses Problem beheben, indem Sie Regeln für eingehenden und ausgehenden Traffic erstellen.

Auf einen öffentlich zugänglichen Cloud Storage-Bucket innerhalb eines Perimeters zugreifen

Wenn Sie versuchen, von einem Dienstperimeter aus auf einen öffentlich zugänglichen Cloud Storage-Bucket zuzugreifen, blockiert VPC Service Controls Ihre Anfragen möglicherweise durch einen Verstoß gegen die Regel für ausgehenden Traffic.

Damit der Zugriff auf das Objekt bei Bedarf immer erfolgreich ist, sollten wir eine Regel für ausgehenden Traffic auf den betroffenen Dienstperimeter anwenden.

Probleme mit Security Command Center

In diesem Abschnitt werden die Probleme aufgeführt, die bei der Verwendung von Security Command Center-Ressourcen auftreten können, die sich innerhalb eines VPC Service Controls-Perimeters befinden.

Security Command Center kann keine Benachrichtigungen an Pub/Sub senden

Der Versuch, Security Command Center-Benachrichtigungen in einem Pub/Sub-Thema innerhalb eines VPC Service Controls-Perimeters zu veröffentlichen, schlägt mit einem RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER-Verstoß fehl.

Wir empfehlen, Security Command Center auf Organisationsebene zu aktivieren. Bei VPC Service Controls wird eine übergeordnete Organisation nicht als Teil des Perimeters der untergeordneten Projekte betrachtet. Damit das funktioniert, müssen Sie Security Command Center Zugriff auf den Perimeter gewähren.

Zur Umgehung dieses Problems haben Sie folgende Möglichkeiten:

  • Verwenden Sie ein Pub/Sub-Thema in einem Projekt, das sich nicht in einem Serviceperimeter befindet.
  • Entfernen Sie die Pub/Sub API aus dem Dienstperimeter, bis die Einrichtung der Benachrichtigungen abgeschlossen ist.

Weitere Informationen zum Aktivieren von Security Command Center-Benachrichtigungen, die an ein Pub/Sub-Thema gesendet werden, finden Sie unter Ergebnisbenachrichtigungen für Pub/Sub aktivieren.

Security Command Center kann Compute Engine-Ressourcen innerhalb eines Perimeters nicht scannen

Security Command Center scannt Compute Engine-Ressourcen in Ihren Projekten mit dem P4SA (Per-Project-Per-Product Service Account) service-{project_number}@gcp-sa-computescanning.iam.gserviceaccount.com. Damit Security Command Center auf Ressourcen innerhalb des Perimeters zugreifen kann, muss das P4SA Ihrer Zugriffsebene oder Eingangsregel hinzugefügt werden. Andernfalls wird möglicherweise ein NO_MATCHING_ACCESS_LEVEL-Fehler angezeigt.

Security Command Center kann keine Ressourcen innerhalb eines Dienstperimeters scannen

Security Health Analytics scannt Ressourcen in Ihren Projekten mit dem P4SA (Per-Project-Per-Product Service Account) service-org-ORGANIZATION_ID@security-center-api.iam.gserviceaccount.com. Damit Security Command Center auf Ressourcen innerhalb des Perimeters zugreifen kann, muss das P4SA-Konto Ihrer Zugriffsebene oder Eingangsregel hinzugefügt werden. Andernfalls wird der Fehler NO_MATCHING_ACCESS_LEVEL angezeigt.

Google Kubernetes Engine-Probleme

In diesem Abschnitt werden die Probleme aufgeführt, die bei der Verwendung von Google Kubernetes Engine-Ressourcen innerhalb eines VPC Service Controls-Perimeters auftreten können.

Autoscaler funktioniert nicht in Perimetern, in denen zugängliche Dienste und eingeschränkte Dienste aktiviert sind

Der Dienst autoscaling.googleapis.com ist nicht in VPC Service Controls eingebunden und kann daher weder zu den eingeschränkten noch zu den zugänglichen Diensten hinzugefügt werden. Es ist nicht möglich, die autoscaling.googleapis.com API in den zugänglichen Diensten zuzulassen. Daher funktioniert der Autoscaler von Clustern, die in einem Perimeter mit aktivierten zugänglichen Diensten vorhanden sind, möglicherweise nicht.

Wir raten davon ab, barrierefreie Dienste zu verwenden. Wenn Sie eine eingeschränkte virtuelle IP-Adresse (VIP) verwenden, erstellen Sie eine Ausnahme für autoscaling.googleapis.com, um in einem Perimeter, der einen Cluster mit Autoscaling enthält, zur privaten VIP zu wechseln.

Probleme mit BigQuery

In diesem Abschnitt werden die Probleme aufgeführt, die bei der Verwendung von BigQuery-Ressourcen innerhalb eines VPC Service Controls-Perimeters auftreten können.

Perimeterbeschränkungen von VPC Service Controls gelten nicht für den Export von BigQuery-Abfrageergebnissen

Wenn Sie versuchen, den Export geschützter Daten aus BigQuery nach Google Drive, Google Sheets oder Looker Studio einzuschränken, kann es zu Abweichungen vom erwarteten Verhalten kommen. Wenn Sie eine Abfrage über die BigQuery-Benutzeroberfläche ausführen, werden die Ergebnisse im lokalen Speicher Ihres Computers gespeichert, z. B. im Browsercache. Das bedeutet, dass sich die Ergebnisse jetzt außerhalb von VPC Service Controls befinden und Sie sie möglicherweise in einer CSV-Datei oder in Google Drive speichern können.

In diesem Szenario funktioniert VPC Service Controls wie vorgesehen, da das Ergebnis von einem lokalen Computer exportiert wird, der sich außerhalb des Dienstperimeters befindet. Die allgemeine Einschränkung von BigQuery-Daten wird jedoch umgangen.

Um dieses Problem zu beheben, schränken Sie die IAM-Berechtigungen für Nutzer ein, indem Sie die Berechtigung bigquery.tables.export entfernen. Dadurch werden alle Exportoptionen deaktiviert.

GKE Enterprise-Probleme

In diesem Abschnitt werden die Probleme aufgeführt, die bei der Verwendung von GKE Enterprise-Ressourcen auftreten können, die sich in einem VPC Service Controls-Perimeter befinden.

Informationen zur Fehlerbehebung bei der Verwendung von VPC Service Controls mit Cloud Service Mesh finden Sie unter Probleme mit VPC Service Controls für verwaltetes Cloud Service Mesh beheben.

Beim Einrichten des GKE Enterprise Config Controller wird ein Verstoß beim ausgehenden Traffic generiert

Die Einrichtung von GKE Enterprise Config Controller schlägt fehl, wenn es keine Konfiguration für ausgehenden Traffic gibt, die es ermöglicht, containerregistry.googleapis.com mit der Methode google.containers.registry.read in einem Projekt außerhalb des Perimeters zu erreichen.

Sie beheben diesen Fehler, indem Sie folgende Regel für ausgehenden Traffic erstellen:

From:
  Identities:ANY_IDENTITY
To:
  Projects =
    NNNNNNNNNNNN
  Service =
  Service name: containerregistry.googleapis.com
  Service methods:
    containers.registry.read

Der Verstoß gegen die Ausgangsregeln verschwindet, nachdem Sie die Regel dem betroffenen Perimeter hinzugefügt haben.

Container Registry-Probleme

In diesem Abschnitt werden die Probleme aufgeführt, die bei der Verwendung von Container Registry-Ressourcen auftreten können, die sich in einem VPC Service Controls-Perimeter befinden.

Container Registry API-Anfragen werden von VPC Service Controls blockiert, obwohl sie in einer Regel für eingehenden oder ausgehenden Traffic zugelassen sind

Wenn Sie den Zugriff auf Container Registry über Eingangsregeln mit dem Feld identity_type auf ANY_USER_ACCOUNT oder ANY_SERVICE_ACCOUNT festgelegt haben, wird der Zugriff durch VPC Service Controls blockiert.

Aktualisieren Sie das Feld identity_type in der Regel für eingehenden oder für ausgehenden Traffic auf ANY_IDENTITY, um dieses Problem zu beheben.

Ausgangsfehler eines Dienst-Agents beim Kopieren eines Docker-Images, das zu Artifact Registry gehört, in ein Projekt in einem Perimeter

Wenn Sie versuchen, ein Bild, das zu Artifact Registry gehört, in Ihr Projekt zu kopieren, das sich in einem VPC Service Controls-Perimeter befindet, können in den Logs des Dienst-Agents cloud-cicd-artifact-registry-copier@system.gserviceaccount.com Ausgaberichtlinienfehler auftreten. Dieser Fehler für ausgehenden Traffic tritt in der Regel auf, wenn sich die Perimeterrichtlinie im Probelaufmodus befindet.

Sie können dieses Problem beheben, indem Sie eine Regel für ausgehenden Traffic erstellen, die dem Dienst-Agent cloud-cicd-artifact-registry-copier@system.gserviceaccount.com den Zugriff auf den Dienst storage.googleapis.com im Projekt ermöglicht, das in den VPC Service Controls-Fehlerlogs angegeben ist.

Vertex AI-Probleme

In diesem Abschnitt werden die Probleme aufgeführt, die bei der Verwendung von Vertex AI-Ressourcen auftreten können, die sich in einem VPC Service Controls-Perimeter befinden.

API-Anfragen für nutzerverwaltete Notebooks werden von VPC Service Controls blockiert, obwohl sie in einer Regel für ein- oder ausgehenden Traffic zugelassen sind

Wenn Sie den Zugriff auf die nutzerverwaltete Notebooks API über eine Richtlinie für eingehenden Traffic zugelassen und identity_type als ANY_USER_ACCOUNT oder ANY_SERVICE_ACCOUNT festgelegt haben, blockiert VPC Service Controls den Zugriff auf die API.

Aktualisieren Sie das Feld identity_type in der Regel für eingehenden oder für ausgehenden Traffic auf ANY_IDENTITY, um dieses Problem zu beheben.

Probleme mit Cloud Spanner

Die Sicherung der Cloud Spanner-Datenbank wird durch den NO_MATCHING_ACCESS_LEVEL-Verstoß des P4SA (Per-Product-Per-Project Service Account) service-PROJECT_NUMBER@gcf-admin-robot.iam.gserviceaccount.com blockiert.

Um dieses Problem zu beheben, fügen Sie eine Eingangsregel mit dem oben genannten Dienst-Agent hinzu oder fügen Sie ihn einer Zugriffsebene hinzu.

Probleme mit AlloyDB for PostgreSQL

Wenn Ihr AlloyDB for PostgreSQL-Cluster durch einen CMEK geschützt ist, können in den Logs von Dienst-Agents service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com und service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com Fehler für eingehenden Traffic auftreten.

Zur Behebung dieses Problems fügen Sie eine Regel für eingehenden Traffic mit dem Zugriff der oben genannten Dienst-Agents auf den cloudkms.googleapis.com-Dienst im Projekt hinzu, das in den VPC Service Controls-Fehlerlogs angegeben ist.

Nächste Schritte