Diese Seite wurde von der Cloud Translation API übersetzt.

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

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

Probleme mit Cloud Build

Die Verwendung von Cloud Build-Ressourcen innerhalb eines VPC Service Controls-Perimeters unterliegt einigen bekannten Einschränkungen. Weitere Informationen finden Sie unter Einschränkungen bei der Verwendung von VPC Service Controls mit Cloud Build.

Das Cloud Build-Dienstkonto hat keinen Zugriff auf geschützte Ressourcen

Cloud Build verwendet das Cloud Build-Dienstkonto, um Builds in Ihrem Namen 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 VPC Service Controls-Perimeters, 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 daher Zugriff auf den VPC Service Controls-Perimeter gewähren. Fügen Sie ihn dazu entweder der Zugriffsebene oder der Regel für eingehenden Traffic hinzu.

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

Probleme mit Cloud Storage

Ablehnungen beim Targeting auf einen nicht vorhandenen Logging-Cloud Storage-Bucket

Wenn der angegebene Logging-Bucket nicht vorhanden ist, verweigert VPC Service Controls den Zugriff mit dem Grund für den Verstoß RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER.

Sie können das Log der Zugriffsverweigerung mithilfe der eindeutigen Kennung von VPC Service Controls (vpcServiceControlUniqueIdentifier) überprüfen. Das folgende Beispiellog enthält den Grund für den Verstoß 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 im Feld targetResource im Objekt egressViolations ein Ziel mit projects/0/buckets angezeigt wird, löst dies immer eine Ablehnung aus, da projects/0 nicht vorhanden ist und es als außerhalb des Dienstperimeters gilt.

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

Ein Dienstperimeter kann keine Projekte aus verschiedenen Organisationen enthalten. Ein Perimeter kann nur Projekte aus seiner übergeordneten Organisation enthalten. Wenn Sie über Projekte innerhalb eines VPC Service Controls-Perimeters, die sich in einer anderen Organisation befinden, auf Cloud Storage-Buckets zugreifen möchten, gelten gewisse Einschränkungen.

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

Um dieses Problem zu beheben, können Sie Regeln für ein- und ausgehenden Traffic erstellen.

Auf einen öffentlich zugänglichen Cloud Storage-Bucket aus einem Perimeter zugreifen

Wenn Sie versuchen, von innerhalb eines Dienstperimeters auf einen öffentlich zugänglichen Cloud Storage-Bucket zuzugreifen, blockiert VPC Service Controls Ihre Anfragen möglicherweise, indem es einen Verstoß gegen ausgehenden Traffic auslöst.

Um einen beständigen erfolgreichen Zugriff auf das Objekt bei Bedarf zu gewährleisten, 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 in einem VPC Service Controls-Perimeter befinden.

Security Command Center hat das Senden von Benachrichtigungen an Pub/Sub blockiert

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

Wir empfehlen, Security Command Center auf Organisationsebene zu aktivieren. VPC Service Controls berücksichtigt keine übergeordnete Organisation als Teil des Perimeters ihrer untergeordneten Projekte. Damit dies funktioniert, müssen Sie Perimeterzugriff auf Security Command Center gewähren.

Um dieses Problem zu umgehen, haben Sie folgende Möglichkeiten:

Verwenden Sie ein Pub/Sub-Thema in einem Projekt, das sich nicht in einem Dienstperimeter befindet.
Entfernen Sie die Pub/Sub API aus dem Dienstperimeter, bis die Benachrichtigungseinrichtung 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 hat das Scannen von Compute Engine-Ressourcen innerhalb eines Perimeters blockiert

Security Command Center scannt Compute Engine-Ressourcen in Ihren Projekten mit dem P4SA-Dienstkonto service-{project_number}@gcp-sa-computescanning.iam.gserviceaccount.com pro Produkt und Projekt. Damit Security Command Center auf Ressourcen innerhalb des Perimeters zugreifen kann, muss die P4SA Ihrer Zugriffsebene oder Regel für eingehenden Traffic hinzugefügt werden. Andernfalls wird möglicherweise der Fehler NO_MATCHING_ACCESS_LEVEL angezeigt.

Security Command Center hat das Scannen von Ressourcen innerhalb eines Dienstperimeters blockiert

Security Health Analytics scannt Ressourcen in Ihren Projekten mit dem P4SA (Dienstkonto pro Produkt und Projekt) 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 Regel für eingehenden Traffic hinzugefügt werden. Andernfalls wird der Fehler NO_MATCHING_ACCESS_LEVEL angezeigt.

Probleme mit Google Kubernetes Engine

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

Autoscaling funktioniert nicht in Perimetern mit zugänglichen und eingeschränkten Diensten

autoscaling.googleapis.com ist nicht in VPC Service Controls eingebunden und kann daher weder den eingeschränkten Diensten hinzugefügt werden noch den zugänglichen Diensten. Die autoscaling.googleapis.com API kann nicht in den zugänglichen Diensten zugelassen werden. Daher funktioniert das Autoscaling von Clustern, die sich in einem Perimeter mit aktivierten zugänglichen Diensten befinden, möglicherweise nicht.

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

Probleme mit BigQuery

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

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

Wenn Sie den Export geschützter Daten aus BigQuery in Google Drive, Google Tabellen oder Looker Studio einschränken möchten, werden Sie möglicherweise eine gewisse Abweichung vom erwarteten Verhalten feststellen. Wenn Sie eine Abfrage über die BigQuery-UI ausführen, werden die Ergebnisse im lokalen Arbeitsspeicher Ihres Computers gespeichert, z. B. im Browser-Cache. Das bedeutet, dass die Ergebnisse jetzt außerhalb von VPC Service Controls liegen. Sie können die Ergebnisse also möglicherweise in einer CSV-Datei oder in Google Drive speichern.

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 der BigQuery-Daten wird jedoch umgangen.

Schränken Sie die IAM-Berechtigungen für Nutzer ein, indem Sie die Berechtigung bigquery.tables.export entfernen, um dieses Problem zu beheben. Beachten Sie, dass dadurch alle Exportoptionen deaktiviert werden.

Probleme mit GKE Enterprise

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

Informationen zum Beheben von Fehlern im Zusammenhang mit 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.

Einrichtung des GKE Enterprise Config Controllers generiert einen Verstoß gegen ausgehenden Traffic

Das Einrichten des GKE Enterprise Config Controllers wird voraussichtlich fehlschlagen, wenn keine Konfiguration für ausgehenden Traffic vorhanden ist, die es ermöglicht, containerregistry.googleapis.com mit der Methode google.containers.registry.read in einem Projekt außerhalb des Perimeters zu erreichen.

Erstellen Sie die folgende Regel für ausgehenden Traffic, um diesen Fehler zu beheben:

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

Der Verstoß gegen ausgehenden Traffic verschwindet, nachdem Sie die Regel dem Perimeterverstoß hinzugefügt haben.

Probleme mit Container Registry

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

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

Wenn Sie den Zugriff auf Container Registry mithilfe von Regeln für eingehenden Traffic mit dem Feld identity_type auf ANY_USER_ACCOUNT oder ANY_SERVICE_ACCOUNT zugelassen haben, wird der Zugriff durch VPC Service Controls blockiert.

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

Fehler bei ausgehendem Traffic von einem Dienst-Agent beim Kopieren eines Docker-Images der Artifact Registry in ein Projekt in einem Perimeter

Wenn Sie versuchen, ein Artifact Registry-Image in ein 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 Fehler beim ausgehenden Traffic auftreten. Dieser Fehler für ausgehenden Traffic tritt normalerweise 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 Zugriff auf den Dienst storage.googleapis.com in dem Projekt gewährt, das in den VPC Service Controls-Fehlerlogs erwähnt wird.

Probleme mit Vertex AI

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

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

Wenn Sie den Zugriff auf die User-Managed Notebooks API mithilfe einer 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.