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-Dienst, der sich in einem VPC Service Controls-Perimeter befindet.

Probleme mit Cloud Build

Die Verwendung von Cloud Build-Ressourcen innerhalb eines VPC Service Controls-Perimeters einige bekannte Einschränkungen. Weitere Informationen finden Sie unter Einschränkungen bei der Verwendung 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 auszuführen in Ihrem Namen. Wenn Sie einen Build in Cloud Build ausführen, wird in einem Mandantenprojekt außerhalb Ihres Projekts ausgeführt.

Die Worker-VMs von Cloud Build, die Build-Ausgaben generieren, befinden sich außerhalb von des VPC Service Controls-Perimeters, auch wenn sich Ihr Projekt innerhalb des des Perimeters. Damit Ihre Builds auf Ressourcen innerhalb des Perimeters zugreifen können, müssen Sie dem Cloud Build-Dienstkonto Zugriff auf die VPC Service Controls-Perimeter entweder durch Hinzufügen zum Zugriff level oder Ingress-Regel.

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

Probleme mit Cloud Storage

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

Wenn der angegebene Logging-Bucket nicht vorhanden ist, wird er von VPC Service Controls abgelehnt Zugriff mit dem Grund für den Verstoß (RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER)

Sie können das Log der Zugriffsverweigerung mithilfe von VPC Service Controls überprüfen Eindeutige Kennung (vpcServiceControlUniqueIdentifier). Im Folgenden finden Sie Beispiellog mit dem 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 angezeigt wird mit projects/0/buckets, löst dies immer eine Ablehnung als projects/0 aus. ist nicht vorhanden und wird als außerhalb des Dienstperimeters betrachtet.

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

Ein Dienstperimeter kann keine Projekte aus verschiedenen Organisationen enthalten. A Perimeter können nur Projekte aus der übergeordneten Organisation enthalten. Es gibt Einschränkungen beim Zugriff auf Cloud Storage-Buckets Projekte innerhalb eines VPC Service Controls-Perimeters, die sich in einem anderen Unternehmen.

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

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 einem Gerät aus auf einen öffentlich zugänglichen Cloud Storage-Bucket zuzugreifen, innerhalb eines Dienstperimeters möglicherweise Ihre Anfragen indem ein Verstoß für ausgehenden Traffic ausgelöst wird.

Um bei Bedarf einen beständigen erfolgreichen Zugriff auf das Objekt zu gewährleisten, haben wir sollte eine Regel für ausgehenden Traffic auf den betroffenen Dienstperimeter angewendet werden.

Probleme mit Security Command Center

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

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

Security Command Center-Benachrichtigungen in Pub/Sub veröffentlichen innerhalb eines VPC Service Controls-Perimeters schlägt fehl mit einer Verstoß gegen die Richtlinie „RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER“.

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

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

Pub/Sub-Thema in einem Projekt verwenden, das sich nicht in einem Dienst befindet des Perimeters.
Entfernen Sie die Pub/Sub API aus dem Dienstperimeter, Benachrichtigungseinrichtung abgeschlossen.

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

Security Command Center hat das Scannen von Compute Engine-Ressourcen innerhalb eines Perimeters blockiert

Security Command Center scannt Compute Engine-Ressourcen in Ihren Projekten mithilfe der Dienstkonto pro Produkt und Projekt (P4SA) service-{project_number}@gcp-sa-computescanning.iam.gserviceaccount.com In 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 (pro Produkt, Dienstkonto pro Projekt) service-org-ORGANIZATION_ID@security-center-api.iam.gserviceaccount.com Damit Security Command Center auf Ressourcen im Perimeter schützen können, muss das P4SA-Konto Ihrer Zugriffsebene oder Ihrem Ingress Regel. 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 auftreten können. Ressourcen, die sich in einem VPC Service Controls-Perimeter befinden.

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

autoscaling.googleapis.com ist nicht in VPC Service Controls kann daher nicht den eingeschränkten Diensten hinzugefügt werden. und auch nicht auf die zugänglichen Dienste. Die Verwendung des autoscaling.googleapis.com API in den zugänglichen Diensten. Dementsprechend wird der Autoscaling von Clustern in einem Perimeter mit aktivierte barrierefreie Dienste funktionieren.

Wir raten davon ab, barrierefreie Dienste zu verwenden. Bei Verwendung eingeschränkter virtueller IP-Adressen (VIP), mach eine Ausnahme, damit autoscaling.googleapis.com zu „Private VIP“ wechselt in einem Perimeter, der einen Cluster mit Autoscaling enthält.

Probleme mit BigQuery

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

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

Wenn Sie den Export geschützter Daten BigQuery in Google Drive, Google Tabellen oder Looker Studio vom erwarteten Verhalten abweichen. Wenn Sie eine Abfrage über die Über die BigQuery-Benutzeroberfläche werden die Ergebnisse im lokalen Speicher Ihres Computers gespeichert. wie dem Browser-Cache. Das bedeutet, dass die Ergebnisse jetzt außerhalb VPC Service Controls, sodass Sie die Ergebnisse evtl. in einer CSV-Datei oder Google Drive

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, wird die allgemeine Einschränkung von BigQuery-Daten umgangen.

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

Probleme mit GKE Enterprise

In diesem Abschnitt werden die Probleme aufgeführt, die bei der Verwendung von GKE Enterprise-Ressourcen, die sich in VPC Service Controls befinden des Perimeters.

Um Fehler im Zusammenhang mit der Verwendung von VPC Service Controls mit Cloud Service Mesh, siehe Probleme mit VPC Service Controls für verwaltete Cloud Service Mesh.

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

Der Einrichtungsprozess von GKE Enterprise Config Controller sollte schlagen fehl, wenn keine Konfiguration für ausgehenden Traffic vorhanden ist, die den containerregistry.googleapis.com mit der Methode google.containers.registry.read in einem Projekt außerhalb des Perimeters.

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 Verstoß hinzugefügt haben des Perimeters.

Probleme mit Container Registry

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

Von VPC Service Controls blockierte Container Registry API-Anfragen, 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 der Das Feld „identity_type“ wurde auf „ANY_USER_ACCOUNT“ oder „ANY_SERVICE_ACCOUNT“ festgelegt, Zugriff wird durch VPC Service Controls blockiert.

Um dieses Problem zu beheben, aktualisieren Sie das Feld identity_type in ANY_IDENTITY für eingehenden oder ausgehenden Traffic.

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 Ihr Projekt zu kopieren, das innerhalb eines VPC Service Controls-Perimeters können Probleme mit ausgehendem Traffic auftreten. in den Logs des Dienst-Agents cloud-cicd-artifact-registry-copier@system.gserviceaccount.com Dieser ausgehende Traffic Fehler 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 den Dienst zulässt Zugriff des Agents auf cloud-cicd-artifact-registry-copier@system.gserviceaccount.com an den Dienst storage.googleapis.com im Projekt, das im VPC Service Controls-Fehlerlogs

Probleme mit Vertex AI

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

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 Zugriff auf die User-managed Notebooks API gewährt haben mit einer Richtlinie für eingehenden Traffic und Sie haben die identity_type als ANY_USER_ACCOUNT oder ANY_SERVICE_ACCOUNT, VPC Service Controls-Blöcke auf die API zugreifen können.