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.
Probleme mit Cloud Build
Für die Verwendung von Cloud Build-Ressourcen in einem VPC Service Controls-Perimeter 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 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 Perimeter von VPC Service Controls gewähren. Dazu fügen Sie es entweder der Zugriffsebene oder der Regel für eingehenden Traffic hinzu.
Weitere Informationen finden Sie unter Cloud Build-Dienstkonto Zugriff auf den VPC Service Controls-Perimeter gewähren.
Cloud Storage-Probleme
Ablehnungen bei Ausrichtung auf einen nicht vorhandenen Cloud Storage-Logging-Bucket
Ist der angegebene Logging-Bucket nicht vorhanden, wird der Zugriff von VPC Service Controls mit dem Grund für den Verstoß RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER
verweigert.
Sie können das Log der Zugriffsverweigerung mit der eindeutigen Kennzeichnung für VPC Service Controls (vpcServiceControlUniqueIdentifier
) überprüfen. Im Folgenden finden Sie ein 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 egressViolations
-Objekt ein Ziel mit projects/0/buckets
anzeigt, löst dies immer eine Ablehnung aus, da projects/0
nicht vorhanden ist und 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 der übergeordneten Organisation enthalten. Es gibt bestimmte Einschränkungen, wenn Sie von Projekten innerhalb eines VPC Service Controls-Perimeters aus auf Cloud Storage-Buckets zugreifen möchten, die sich in einer anderen Organisation befinden.
Ein typisches Beispiel ist, wenn Sie auf Google-eigene Cloud Storage-Buckets zugreifen möchten. 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 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.
Von einem Perimeter auf einen öffentlich zugänglichen Cloud Storage-Bucket zugreifen
Wenn Sie versuchen, von einem Dienstperimeter aus auf einen öffentlich zugänglichen Cloud Storage-Bucket zuzugreifen, blockiert VPC Service Controls Ihre Anfragen unter Umständen durch einen Verstoß für ausgehenden Traffic.
Um einen konsistenten 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 in einem VPC Service Controls-Perimeter auftreten können.
Security Command Center darf 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. Eine übergeordnete Organisation wird von VPC Service Controls nicht als Teil des Perimeters ihrer untergeordneten Projekte betrachtet. Damit dies funktioniert, müssen Sie Security Command Center Perimeterzugriff gewähren.
Sie haben folgende Möglichkeiten, das Problem zu umgehen:
- 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 Einrichtung der Benachrichtigung 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 keine Compute Engine-Ressourcen innerhalb eines Perimeters scannen
Security Command Center scannt Compute Engine-Ressourcen in Ihren Projekten mit dem 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 Eingangsregel hinzugefügt werden.
Andernfalls wird der Fehler NO_MATCHING_ACCESS_LEVEL
angezeigt.
Security Command Center wird daran gehindert, Ressourcen innerhalb eines Dienstperimeters zu scannen
Security Health Analytics scannt Ressourcen in Ihren Projekten mit dem P4SA-Konto (pro Produkt, pro 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 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 innerhalb eines VPC Service Controls-Perimeters auftreten können.
Autoscaling funktioniert nicht in Perimetern mit aktivierten zugänglichen und eingeschränkten Diensten
Der autoscaling.googleapis.com
ist nicht in VPC Service Controls eingebunden und kann den eingeschränkten Diensten und den zugänglichen Diensten daher nicht hinzugefügt werden. Die autoscaling.googleapis.com
API kann nicht in den zugänglichen Diensten zugelassen werden. Daher funktioniert das Autoscaling von Clustern in einem Perimeter mit aktivierten zugänglichen Diensten möglicherweise nicht.
Wir raten davon ab, barrierefreie Dienste zu verwenden. Wenn Sie eine eingeschränkte virtuelle IP-Adresse (VIP) verwenden, legen Sie eine Ausnahme fest, damit autoscaling.googleapis.com
in einem Perimeter, der einen Cluster mit Autoscaling enthält, zur privaten VIP wechselt.
BigQuery-Probleme
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-Perimetereinschränkungen gelten nicht für den Export von BigQuery-Abfrageergebnissen
Wenn Sie versuchen, den Export geschützter Daten aus BigQuery in Google Drive, Google Tabellen oder Looker Studio einzuschränken, können Abweichungen vom erwarteten Verhalten auftreten. Wenn Sie eine Abfrage über die BigQuery-UI ausführen, werden die Ergebnisse im lokalen Arbeitsspeicher 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 umgehen, schränken Sie die IAM-Berechtigungen für Nutzer ein, indem Sie die Berechtigung bigquery.tables.export
entfernen. 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 innerhalb eines VPC Service Controls-Perimeters auftreten können.
Informationen zur Fehlerbehebung bei der Verwendung von VPC Service Controls mit Anthos Service Mesh finden Sie unter Probleme mit VPC Service Controls für verwaltetes Anthos Service Mesh beheben.
Die Einrichtung des GKE Enterprise Config Controllers verursacht einen Verstoß für ausgehenden Traffic
Die Einrichtung von GKE Enterprise Config Controller schlägt wahrscheinlich fehl, 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ß für ausgehenden Traffic verschwindet, nachdem Sie die Regel dem Perimeter hinzugefügt haben, gegen den verstoßen wurde.
Container Registry-Probleme
In diesem Abschnitt werden die Probleme aufgeführt, die bei der Verwendung von Container Registry-Ressourcen innerhalb eines VPC Service Controls-Perimeters auftreten können.
Container Registry API-Anfragen, die von VPC Service Controls blockiert werden, obwohl sie in einer Regel für eingehenden oder ausgehenden Traffic zulässig sind
Wenn Sie den Zugriff auf Container Registry mithilfe von Regeln für eingehenden Traffic zugelassen haben und das Feld identity_type
auf ANY_USER_ACCOUNT
oder ANY_SERVICE_ACCOUNT
gesetzt ist, wird der Zugriff durch VPC Service Controls blockiert.
Aktualisieren Sie das Feld identity_type
in der Regel für eingehenden oder ausgehenden Traffic auf ANY_IDENTITY
, um dieses Problem zu beheben.
Fehler bei ausgehendem Traffic von einem von Google verwalteten Dienstkonto beim Kopieren des Artifact Registry-eigenen Docker-Images in ein Projekt in einem Perimeter
Wenn Sie versuchen, ein Artifact Registry-eigenes Image in ein Projekt zu kopieren, das sich in einem VPC Service Controls-Perimeter befindet, können in den Logs des von Google verwalteten Dienstkontos cloud-cicd-artifact-registry-copier@system.gserviceaccount.com
Fehler beim ausgehenden Traffic auftreten. Dieser Ausgangsfehler 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 Dienstkonto cloud-cicd-artifact-registry-copier@system.gserviceaccount.com
Zugriff auf den Dienst storage.googleapis.com
in dem Projekt ermöglicht, 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 innerhalb eines VPC Service Controls-Perimeters auftreten können.
API-Anfragen für vom Nutzer verwaltete Notebooks, die von VPC Service Controls blockiert werden, obwohl sie in einer Regel für eingehenden oder ausgehenden Traffic zulässig sind
Wenn Sie den Zugriff auf die User-managed Notebooks API über eine Richtlinie für eingehenden Traffic gewährt und identity_type
auf 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 ausgehenden Traffic auf ANY_IDENTITY
, um dieses Problem zu beheben.
Spanner-Probleme
Die Spanner-Datenbanksicherung wird durch den NO_MATCHING_ACCESS_LEVEL
-Verstoß des produkt- und projektspezifischen Dienstkontos (service-
PROJECT_NUMBER@gcf-admin-robot.iam.gserviceaccount.com
) blockiert.
Fügen Sie zum Beheben dieses Problems eine Regel für eingehenden Traffic mit dem oben genannten Dienst-Agent hinzu oder fügen Sie sie einer Zugriffsebene hinzu.
Nächste Schritte
- Bekannte Einschränkungen bei der Verwendung von VPC Service Controls mit verschiedenen Google Cloud-Diensten
- Mithilfe der eindeutigen Kennung von VPC Service Controls Probleme im Zusammenhang mit Dienstperimetern beheben