Auf dieser Seite finden Sie Lösungen für Probleme, die bei der Verwendung eines Google Cloud-Dienstes in einem VPC Service Controls-Perimeter auftreten können.
Cloud Build-Probleme
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 von VPC Service Controls mit Cloud Build.
Cloud Build-Dienstkonto für den Zugriff auf geschützte Ressourcen blockiert
Cloud Build verwendet das Cloud Build-Dienstkonto, um Builds auszuführen in Ihrem Namen. 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 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 auf den Perimeter der VPC Service Controls gewähren.
Cloud Storage-Probleme
Abweisungen bei Ausrichtung auf einen nicht vorhandenen Cloud Storage-Bucket für Logging
Wenn der angegebene Logging-Bucket nicht vorhanden ist, wird der Zugriff von VPC Service Controls mit dem Grund RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER
abgelehnt.
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 das Feld targetResource
im Objekt egressViolations
ein Ziel mit projects/0/buckets
enthält, wird immer eine Ablehnung ausgelöst, da projects/0
nicht existiert und als außerhalb des Dienstperimeters betrachtet wird.
Zugriffsverweigerungen 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. Wenn Sie von Projekten innerhalb eines VPC Service Controls-Perimeters, der sich in einer anderen Organisation befindet, auf Cloud Storage-Buckets zugreifen möchten, gelten bestimmte Einschränkungen.
Ein typisches Beispiel ist der Zugriff auf Cloud Storage-Buckets, die Google gehören. 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
.
Sie können Regeln für eingehenden und ausgehenden Traffic erstellen, um dieses Problem zu beheben.
Auf einen öffentlich zugänglichen Cloud Storage-Bucket aus einem Perimeter zugreifen
Wenn Sie versuchen, innerhalb eines Dienstperimeters auf einen öffentlich zugänglichen Cloud Storage-Bucket zuzugreifen, blockieren VPC Service Controls Ihre Anfragen möglicherweise, indem eine Ausgehende-Traffic-Verletzung auftritt.
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 dem 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 kann keine Benachrichtigung 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. VPC Service Controls berücksichtigt keine übergeordnete Organisation der untergeordneten Projekte des Perimeters. Dazu müssen Sie Perimeterzugriff auf Security Command Center.
Sie haben 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 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 (Produkt- und Projektdienstkonto) 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.
Autoscaler funktioniert in Perimetern mit zugänglichen Diensten und eingeschränkten Diensten nicht
autoscaling.googleapis.com
ist nicht integriert in
VPC Service Controls kann daher nicht den eingeschränkten Diensten hinzugefügt werden.
und auch nicht auf die
zugänglichen Dienste. Die autoscaling.googleapis.com
API kann nicht für barrierefreie Dienste zugelassen werden. 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.
BigQuery-Probleme
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 von VPC Service Controls liegen. Sie können sie also 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, 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.
Die Einrichtung des GKE Enterprise-Konfigurationscontrollers führt zu einem Verstoß gegen die ausgehenden Zugriffsregeln
Die Einrichtung des GKE Enterprise Config Controllers schlägt voraussichtlich fehl, wenn es keine ausgehende Konfiguration gibt, mit der containerregistry.googleapis.com
mit der Methode google.containers.registry.read
in einem Projekt außerhalb des Perimeter erreicht werden kann.
Um diesen Fehler zu beheben, erstellen Sie die folgende Ausgehende Regel:
From:
Identities:ANY_IDENTITY
To:
Projects =
NNNNNNNNNNNN
Service =
Service name: containerregistry.googleapis.com
Service methods:
containers.registry.read
Die Ausgehendes-Verstoß-Benachrichtigung 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 auftreten können. Ressourcen, die sich in einem VPC Service Controls-Perimeter befinden.
Container Registry API-Anfragen, 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 Container Registry mithilfe von Ingress-Regeln zugelassen haben, bei denen das Feld identity_type
auf ANY_USER_ACCOUNT
oder ANY_SERVICE_ACCOUNT
festgelegt ist, wird der Zugriff von VPC Service Controls blockiert.
Aktualisieren Sie das Feld identity_type
in der Ingress- oder Egress-Regel auf ANY_IDENTITY
, um das Problem zu beheben.
Fehler beim Senden von Daten von einem Dienst-Agenten beim Kopieren eines Docker-Images von 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-Ressourcen in einem VPC Service Controls-Perimeter auftreten können.
Von VPC Service Controls blockierte API-Anfragen für nutzerverwaltete Notebooks, die in einer Regel für ein- 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.
Aktualisieren Sie das Feld identity_type
in der Ingress- oder Egress-Regel auf ANY_IDENTITY
, um dieses Problem zu beheben.
Spanner-Probleme
Die Spanner-Datenbanksicherung wird durch den NO_MATCHING_ACCESS_LEVEL
-Verstoß des P4SA (Produkt- und Projektdienstkonto) service-
PROJECT_NUMBER@gcf-admin-robot.iam.gserviceaccount.com
blockiert.
Fügen Sie eine Regel für eingehenden Traffic mit dem oben genannten Dienst-Agent hinzu, um dieses Problem zu beheben oder einer Zugriffsebene hinzufügen.
Nächste Schritte
- Bekannte Einschränkungen bei der Verwendung von VPC Service Controls mit verschiedene Google Cloud- Dienste.
- Weitere Informationen zur Fehlerbehebung durch eindeutige VPC Service Controls-Kennungen Probleme im Zusammenhang mit Dienstperimetern.