Fehlerbehebung

Auf dieser Seite werden verschiedene Probleme aufgeführt, die beim Konfigurieren von VPC Service Controls auftreten können.

VPC Service Controls-Fehler ermitteln

In diesem Abschnitt werden zwei Methoden zum Ermitteln von VPC-Fehlern in Ihren Audit-Logs beschrieben: Eindeutige ID eines Fehlers verwenden oder Metadaten zur Identifizierung von Fehlern verwenden.

Eindeutige ID des Fehlers verwenden

Ein von VPC Service Controls generierter Fehler enthält eine eindeutige ID, mit der relevante Audit-Logs identifiziert werden.

Für dieses Verfahren werden Begriffe aus der Logging-Dokumentation verwendet. Weitere Informationen finden Sie unter Einfache Logfilter.

So erhalten Sie Informationen zu einem Fehler anhand der eindeutigen ID:

  1. Wechseln Sie in der Cloud Console zur Seite Stackdriver Logging für das Projekt innerhalb des Dienstperimeters, das den Fehler ausgelöst hat.

    Zur Seite "Stackdriver Logging"

  2. Geben Sie im Suchfilterfeld die eindeutige ID des Fehlers ein.

Logs mit Metadaten filtern

Mit Cloud Logging können Sie Fehler ermitteln, die im Zusammenhang mit VPC Service Controls aufgetreten sind.

Console

Für dieses Verfahren werden Begriffe aus der Logging-Dokumentation verwendet. Weitere Informationen finden Sie unter Einfache Logfilter.

So können Sie die VPC Service Controls-Fehler der letzten 24 Stunden in Logging abrufen:

  1. Wechseln Sie in der Google Cloud Console zur Seite Stackdriver Logging für das Projekt innerhalb des Dienstperimeters.

    Zur Seite "Stackdriver Logging"

  2. Geben Sie folgenden Wert in das Suchfilterfeld ein:

    protoPayload.metadata.@type:"type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
    
  3. Wählen Sie im einfachen Ressourcen-Auswahlmenü die Option Geprüfte Ressource aus.

  4. Wählen Sie im Drop-down-Menü für die Zeitraumauswahl die Option Letzte 24 Stunden aus.

  5. Wenn Sie die VPC Service Controls-Fehler aus einem anderen Zeitraum abrufen möchten, können Sie den gewünschten Zeitraum im entsprechenden Drop-down-Menü auswählen.

gcloud

Führen Sie den folgenden Befehl aus, um die VPC Service Controls-Fehler der letzten 24 Stunden abzurufen:

gcloud logging read 'protoPayload.metadata.@type:"type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"'

Der Befehl read ist standardmäßig auf die letzten 24 Stunden beschränkt. Wenn Sie VPC Service Controls-Logs für einen anderen Zeitraum abrufen möchten, können Sie einen der folgenden Befehle verwenden.

So grenzen Sie die Logs relativ zum aktuellen Datum ein:

gcloud logging read \
  'protoPayload.metadata.@type:"type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"' \
  --freshness=DURATION

Wobei:

So rufen Sie beispielsweise alle VPC Service Controls-Fehler ab, die in der letzten Woche aufgetreten sind:

gcloud logging read \
  'protoPayload.metadata.@type:"type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"' \
  --freshness=7d

So beschränken Sie die Logs auf einen bestimmten Zeitraum:

gcloud logging read \
  'protoPayload.metadata.@type:"type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata" AND
  timestamp>="DATETIME" AND
  timestamp<="DATETIME"'

Hierbei gilt:

  • DATETIME (Datum/Uhrzeit) ist ein formatierter Datum/Uhrzeit-String. Weitere Informationen zur Formatierung finden Sie unter Absolute Datums-/Uhrzeitformate für gcloud.

So rufen Sie beispielsweise alle VPC Service Controls-Fehler ab, die zwischen dem 22. März 2019 und dem 26. März 2019 aufgetreten sind:

gcloud logging read \
  'protoPayload.metadata.@type:"type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata" AND
  timestamp>="2019-03-22T23:59:59Z" AND
  timestamp<="2019-03-26T00:00:00Z"'

Nicht unterstützte Dienste

Weitere Informationen zu Produkten und Diensten, die von VPC Service Controls unterstützt werden, finden Sie auf der Seite Unterstützte Produkte.

Der Versuch, einen nicht unterstützten Dienst mit dem gcloud-Befehlszeilentool oder der Access Context Manager API einzuschränken, führt zu einem Fehler.

Der projektübergreifende Zugriff auf Daten von unterstützten Diensten wird von VPC Service Controls blockiert. Außerdem können Sie die eingeschränkte VIP verwenden, um den Aufruf nicht unterstützter Dienste durch Workloads zu blockieren.

Freigegebene VPC

Wenn Sie eine freigegebene VPC verwenden, muss ein Dienstperimeter, der Projekte eines freigegebenen VPC-Netzwerks enthält, auch das Projekt enthalten, das das Netzwerk hostet. Wenn Projekte, die zu einem freigegebenen VPC-Netzwerk gehören, nicht im gleichen Perimeter wie das Hostprojekt sind, funktionieren Dienste möglicherweise nicht wie erwartet oder werden komplett blockiert.

Sorgen Sie dafür, dass sich der Host des freigegebenen VPC-Netzwerks im gleichen Dienstperimeter befinden wie Projekte, die mit dem Netzwerk verbunden sind.

Anfragen zwischen Perimetern

Normalerweise werden Zugriffsebenen verwendet, um Anfragen von außerhalb eines Dienstperimeters für geschützte Ressourcen innerhalb eines Perimeters zuzulassen.

Anfragen von einem Projekt in einem Perimeter für eine geschützte Ressource in einem anderen Perimeter werden jedoch abgelehnt, auch wenn eine Zugriffsebene die Anfrage normalerweise zulassen würde.

Beispiel: Projekt A in Perimeter 1 fragt eine Ressource von Projekt B an. Die Ressource in Projekt B ist durch Perimeter 2 geschützt. Da Projekt A sich in einem Perimeter befindet, wird die Anfrage auch dann abgelehnt, wenn die Zugriffsebene für Perimeter 2 normalerweise die Anfrage für die geschützte Ressource zulässt.

Es gibt zwei Möglichkeiten, Anfragen zwischen Perimetern zu vereinfachen:

  • Verwenden Sie Perimeter-Bridges. Mit Bridges können zwei oder mehr Projekte in verschiedenen Perimetern Anfragen an alle Dienste in diesen Projekten senden. Diese Anfragen sind auch dann erlaubt, wenn die Dienste durch die Perimeter geschützt sind.

  • Sorgen Sie dafür, dass sowohl der anfragende Dienst als auch die Zielressource durch die Perimeter geschützt sind. In diesem Szenario ist der Vorgang erfolgreich, da keine Dienste geschützt sind.

Bestimmen, ob ein Fehler auf VPC Service Controls zurückzuführen ist

VPC Service Controls ändert bestimmte grundlegende Attribute von Google Cloud. Diese Auswirkungen zeigen sich möglicherweise über mehrere Dienste hinweg, sodass die Fehlerbehebung schwierig sein kann, wenn Sie nicht wissen, worauf Sie achten müssen.

Damit Sie feststellen können, ob ein Fehler mit VPC Service Controls zusammenhängt, müssen Sie prüfen, ob Sie VPC Service Controls aktiviert und auf die Projekte und Dienste angewendet haben, die Sie verwenden möchten. Dies können Sie über das gcloud-Befehlszeilentool oder die Cloud Console prüfen.

Wenn Sie einen Dienst verwenden (möglicherweise indirekt über einen anderen Dienst), der von VPC Service Controls in einem Projekt innerhalb eines Dienstperimeters als eingeschränkter Dienst markiert wurde, ist VPC Service Controls möglicherweise für den Fehler verantwortlich.

Informationen zu bekannten Problemfällen finden Sie unter Bekannte Diensteinschränkungen.

Normalerweise geben Dienste Fehlermeldungen von ihren Abhängigkeiten weiter. Wenn einer der folgenden Fehler auftritt, weist dies auf ein Problem mit VPC Service Controls hin.

  • Cloud Storage: 403: Request violates VPC Service Controls.

  • BigQuery: 403: VPC Service Controls: Request is prohibited by organization's policy.

  • Weitere Dienste: 403: Request is prohibited by organization's policy.

Fehlerbehebung, wenn eine Anfrage aus nicht vorhersehbaren Gründen von VPC Service Controls blockiert wurde

Das VPC Service Controls-Audit-Log ist das primäre Tool, um herauszufinden, warum eine Anfrage von VPC Service Controls blockiert wurde.

Wenn der Zugriff unerwartet verweigert wurde, können Sie in der Regel die Audit-Logs im Projekt untersuchen, aus dem die Anfrage gestellt wurde. Diese Logs enthalten umfassende Daten zu den angeforderten Ressourcen und dem Grund für die Ablehnung der Anfrage.

Weitere Informationen zum Aufrufen von Logs finden Sie unter Logs ansehen.

Die folgende Tabelle enthält die violationReason-Werte, die bei der Verwendung von VPC Service Controls auftreten können.

Fehlerursache Erklärung
RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER Die im Audit-Logeintrag unter resourceNames aufgeführten Ressourcen befinden sich nicht im selben Dienstperimeter.
NETWORK_NOT_IN_SAME_SERVICE_PERIMETER Die Ressourcen, die im Audit-Logeintrag den Werten callerNetwork und resourceNames entsprechen, befinden sich nicht im selben Dienstperimeter.
NO_MATCHING_ACCESS_LEVEL

Die IP-Adresse, die im Audit-Logeintrag dem Wert callerIp entspricht, stimmt mit keinem der IP-Bereiche auf Zugriffsebenen überein, die dem Dienstperimeter zugewiesen sind.

Beispielszenarien

In den folgenden Beispielen werden häufige Szenarien beschrieben, die bei der Verwendung von VPC Service Controls auftreten können.

Cloud Storage-Zugriff aus lokaler Umgebung

In diesem Beispiel wird eine Anfrage von einer Mitarbeiter-Workstation (durch callerIp identifiziert) zu einem Cloud Storage-Bucket im Projekt corp-storage von VPC Service Controls blockiert.

Die Anfrage generiert den folgenden Audit-Logeintrag:

{
 insertId:  "222lvajc6f7"
 logName:  "projects/corp-storage/logs/cloudaudit.googleapis.com%2Fpolicy"
 protoPayload: {
  @type:  "type.googleapis.com/google.cloud.audit.AuditLog"
  authenticationInfo: {
   principalEmail:  "someone@google.com"
  }
  metadata: {
   @type:  "type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
   resourceNames: [
    0:  "projects/_"
   ]
   violationReason:  "NO_MATCHING_ACCESS_LEVEL"
  }
  methodName:  "google.storage.NoBillingOk"
  requestMetadata: {
   callerIp:  "b1d5:d26d:5b17:43fe:d358:586b:db59:9617"
   destinationAttributes: {
   }
   requestAttributes: {
   }
  }
  resourceName:  "projects/690885588241"
  serviceName:  "storage.googleapis.com"
  status: {
   code:  7
   details: [
    0: {
     @type:  "type.googleapis.com/google.rpc.PreconditionFailure"
     violations: [
      0: {
       type:  "VPC_SERVICE_CONTROLS"
      }
     ]
    }
   ]
   message:  "Request is prohibited by organization's policy"
  }
 }
 receiveTimestamp:  "2018-11-27T21:40:43.823209571Z"
 resource: {
  labels: {
   method:  "google.storage.NoBillingOk"
   project_id:  "corp-storage"
   service:  "storage.googleapis.com"
  }
  type:  "audited_resource"
 }
 severity:  "ERROR"
 timestamp:  "2018-11-27T21:40:42.973784140Z"
}

Das Projekt corp-storage ist in einem Dienstperimeter enthalten. Die Mitarbeiter-Workstation gehört nicht zu einem Netzwerk innerhalb dieses Perimeters. Die Anfrage wird blockiert, da sich die Mitarbeiter-Workstation außerhalb des Perimeters befindet.

BigQuery-Zugriff von einer VM außerhalb des Projekts

In diesem Beispiel versucht eine VM aus dem Projekt 458854174376 (data-collector), eine BigQuery-Abfrage für ein Dataset im Projekt 798816221974 (corp-resources-protected) auszuführen. Der Zugriff wird verweigert.

Die VM führt folgende Abfrage aus:

bq --project=corp-resources-protected query 'select count(*) from babynames.yob2000'

Die Abfrage gibt Folgendes zurück:

BigQuery error in query operation: VPC Service Controls: Request is
prohibited by organization's policy. Operation ID:
33643962-6a0f-4091-9283-bcdf7e9271f0

Der folgende Audit-Logeintrag wird generiert:

{
 insertId:  "1ei551d2pdq"
 logName:  "projects/corp-resources-protected/logs/cloudaudit.googleapis.com%2Fpolicy"
 protoPayload: {
  @type:  "type.googleapis.com/google.cloud.audit.AuditLog"
  authenticationInfo: {
   principalEmail:  "714877721106-compute@example.gserviceaccount.com"
  }
  metadata: {
   @type:  "type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
   resourceNames: [
    0:  "projects/1004338142803"
   ]
   violationReason:  "NETWORK_NOT_IN_SAME_SERVICE_PERIMETER"
  }
  methodName:  "bigquery.googleapis.com/bigquery.jobs.create"
  requestMetadata: {
   callerIp:  "10.105.0.2"
   callerNetwork:  "//compute.googleapis.com/projects/ameet-dataflow/global/networks/__unknown__"
   destinationAttributes: {
   }
   requestAttributes: {
   }
  }
  resourceName:  "projects/1004338142803"
  serviceName:  "bigquery.googleapis.com"
  status: {
   code:  7
   details: [
    0: {
     @type:  "type.googleapis.com/google.rpc.PreconditionFailure"
     violations: [
      0: {
       type:  "VPC_SERVICE_CONTROLS"
      }
     ]
    }
   ]
   message:  "Request is prohibited by organization's policy"
  }
 }
 receiveTimestamp:  "2018-11-28T23:06:13.579882505Z"
 resource: {
  labels: {
   method:  "bigquery.googleapis.com/bigquery.jobs.create"
   project_id:  "corp-resources-protected"
   service:  "bigquery.googleapis.com"
  }
  type:  "audited_resource"
 }
 severity:  "ERROR"
 timestamp:  "2018-11-28T23:06:12.799656975Z"
}

Die violationReason in diesem Beispiel lautet NETWORK_NOT_IN_SAME_SERVICE_PERIMETER. Neben callerNetwork wird callerIp aufgeführt. Die IP-Adresse ist privat und das Netzwerk wird zur Unterscheidung angegeben. Die relevanten Ressourcen sind an zwei Stellen aufgelistet: VpcServiceControlAuditMetadata.resourceNames und requestMetadata.callerNetwork (das Projekt, dem das Netzwerk angehört).

Das Problem besteht darin, dass sich das Projekt corp-resources-protected in einem Dienstperimeter befindet und sich das Projekt data-collector, das das Netzwerk enthält, zu dem die VM gehört, nicht in einem Perimeter befindet. Der Zugriff wird in diesem Fall erwartungsgemäß verweigert.

Projektübergreifende BigQuery-Abfrage

In diesem Beispiel versucht eine VM aus dem Projekt perimeter-network, die BigQuery-Instanzen von zwei verschiedenen Projekten abzufragen: corp-resources-protected, das sich im gleichen Dienstperimeter befindet wie perimeter-network, und corp-resources-public, das sich nicht im gleichen Perimeter befindet.

Die VM führt den folgenden Befehl aus:

bq query --use_legacy_sql=false \
  'select count(priv.name),count(pub.name) from \
  `corp-resources-protected.babynames.yob2000` as priv, \
  `corp-resources-public.babynames.yob2000` as pub'

Die Abfrage gibt Folgendes zurück:

BigQuery error in query operation: Error processing job
'example:bqjob_r211e6f6eec928ffb_000001675c996aa8_1': VPC Service Controls:
Request is prohibited by organization's policy. Operation ID:
dc4fc177-4850-4fc5-b2e7-8c33f302149a

Der folgende Audit-Logeintrag wird generiert:

{
 insertId:  "17kg4exd24ag"
 logName:  "projects/perimeter-network/logs/cloudaudit.googleapis.com%2Fpolicy"
 protoPayload: {
  @type:  "type.googleapis.com/google.cloud.audit.AuditLog"
  authenticationInfo: {
  }
  metadata: {
   @type:  "type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
   resourceNames: [
    0:  "projects/117961063178"
    1:  "projects/690885588241"
   ]
   violationReason:  "RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER"
  }
  methodName:  "bigquery.googleapis.com/bigquery.tables.getData"
  requestMetadata: {
   callerIp:  "130.211.225.66"
   callerNetwork:  "//compute.googleapis.com/projects/perimeter-network/global/networks/__unknown__"
   destinationAttributes: {
   }
   requestAttributes: {
   }
  }
  resourceName:  "projects/927005422713"
  serviceName:  "bigquery.googleapis.com"
  status: {
   code:  7
   details: [
    0: {
     @type:  "type.googleapis.com/google.rpc.PreconditionFailure"
     violations: [
      0: {
       type:  "VPC_SERVICE_CONTROLS"
      }
     ]
    }
   ]
   message:  "Request is prohibited by organization's policy"
  }
 }
 receiveTimestamp:  "2018-11-28T20:48:51.384237810Z"
 resource: {
  labels: {
   method:  "bigquery.googleapis.com/bigquery.tables.getData"
   project_id:  "perimeter-network"
   service:  "bigquery.googleapis.com"
  }
  type:  "audited_resource"
 }
 severity:  "ERROR"
 timestamp:  "2018-11-28T20:48:50.561884949Z"
}

Bei der Betrachtung von callerNetwork und VpcServiceControlAuditMetadata.resourceNames sehen wir drei Projekte: perimeter-network, 117961063178 (corp-resources-public) und 690885588241 (corp-resources-protected). corp-resources-public befindet sich, wie oben beschrieben, nicht im gleichen Dienstperimeter wie perimeter-network und corp-resources-protected.

Die violationReason RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER gibt an, dass sich eine Ressource in der Anfrage außerhalb eines Perimeters befindet, der für die Anfrage gilt. Das ist in diesem Fall corp-resources-public.

Cloud Storage-Datei wird von einer VM innerhalb des Perimeters verschoben

In diesem Beispiel wird von einer VM im Projekt perimeter-network ein Befehl ausgeführt, um eine Datei von einem Cloud Storage-Bucket im Projekt corp-resources-protected in einen anderen Bucket im Projekt corp-resources-public zu verschieben.

Die VM führt den folgenden Befehl aus:

gsutil mv gs://corp-resources-private-1/yob2000.txt gs://corp-resources-public-1/babynames/

Der Befehl gibt Folgendes zurück:

Copying gs://corp-resources-private-1/yob2000.txt [Content-Type=text/plain]...
AccessDeniedException: 403 Request violates VPC Service Controls.

Der folgende Audit-Logeintrag wird generiert:

{
 insertId:  "1xxnssmd2hqo"
 logName:  "projects/perimeter-network/logs/cloudaudit.googleapis.com%2Fpolicy"
 protoPayload: {
  @type:  "type.googleapis.com/google.cloud.audit.AuditLog"
  authenticationInfo: {
   principalEmail:  "storage-accessing@example.iam.gserviceaccount.com"
  }
  metadata: {
   @type:  "type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
   resourceNames: [
    0:  "projects/_/buckets/corp-resources-public-1"
   ]
   violationReason:  "NETWORK_NOT_IN_SAME_SERVICE_PERIMETER"
  }
  methodName:  "google.storage.BillingRequiredRead"
  requestMetadata: {
   callerIp:  "130.211.225.66"
   callerNetwork:  "//compute.googleapis.com/projects/perimeter-network/global/networks/__unknown__"
   destinationAttributes: {
   }
   requestAttributes: {
   }
  }
  resourceName:  "projects/927005422713"
  serviceName:  "storage.googleapis.com"
  status: {…}
 }
 receiveTimestamp:  "2018-11-28T00:45:31.531623485Z"
 resource: {
  labels: {
   method:  "google.storage.BillingRequiredRead"
   project_id:  "perimeter-network"
   service:  "storage.googleapis.com"
  }
  type:  "audited_resource"
 }
 severity:  "ERROR"
 timestamp:  "2018-11-28T00:45:31.351140381Z"
}

In diesem Fall enthält das Log nicht so klare Informationen, da die aufgelistete Methode BillingRequiredRead und die durchgeführte Aktion move lautet. Dies ist eine Einschränkung der derzeitigen Audit-Logfunktionalität von VPC Service Controls.

Obwohl die Ursache des Fehlers weniger eindeutig ist, zeigt dieser Audit-Logeintrag, dass sich eine Ressource in der Anfrage außerhalb eines Perimeters befindet, der für die Anfrage gilt. Das ist in diesem Fall corp-resources-public.

Cloud Storage-Datei wird von einer VM außerhalb des Perimeters verschoben

In diesem Beispiel wird von einer VM im Projekt public-network ein Befehl ausgeführt, um eine Datei von einem Cloud Storage-Bucket im Projekt corp-resources-protected in einen anderen Bucket im Projekt corp-resources-public zu verschieben.

corp-resources-protected wird durch einen Dienstperimeter geschützt. public-network und corp-resources-public befinden sich außerhalb des Perimeters.

Die VM führt den folgenden Befehl aus:

gsutil mv gs://corp-resources-private-1/yob2000.txt gs://corp-resources-public-1/babynames/

Der Befehl gibt Folgendes zurück:

Copying gs://corp-resources-private-1/yob2000.txt [Content-Type=text/plain]...
AccessDeniedException: 403 Request violates VPC Service Controls.

Der folgende Audit-Log-Eintrag wird generiert:

{
 insertId:  "10moqhsch9v"
 logName:  "projects/corp-resources-private/logs/cloudaudit.googleapis.com%2Fpolicy"
 protoPayload: {
  @type:  "type.googleapis.com/google.cloud.audit.AuditLog"
  authenticationInfo: {
   principalEmail:  "user@example.biz"
  }
  metadata: {
   @type:  "type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
   resourceNames: [
    0:  "projects/_/buckets/corp-resources-private-1/objects/yob2000.txt"
    1:  "projects/_/buckets/corp-resources-public-1/objects/out.txt"
   ]
   violationReason:  "RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER"
  }
  methodName:  "google.storage.Write"
  requestMetadata: {
   callerIp:  "2620:15c:2c4:203:63d6:5eb8:418d:c034"
   destinationAttributes: {
   }
   requestAttributes: {
   }
  }
  resourceName:  "projects/1004338142803"
  serviceName:  "storage.googleapis.com"
  status: {
   code:  7
   details: [
    0: {
     @type:  "type.googleapis.com/google.rpc.PreconditionFailure"
     violations: [
      0: {
       type:  "VPC_SERVICE_CONTROLS"
      }
     ]
    }
   ]
   message:  "Request is prohibited by organization's policy"
  }
 }
 receiveTimestamp:  "2018-11-30T16:34:46.948010626Z"
 resource: {
  labels: {
   method:  "google.storage.Write"
   project_id:  "corp-resources-private"
   service:  "storage.googleapis.com"
  }
  type:  "audited_resource"
 }
 severity:  "ERROR"
 timestamp:  "2018-11-30T16:34:46.898098978Z"
}

In diesem Beispiel weist das Audit-Log darauf hin, dass das Kopieren von Daten über die Grenze eines Dienstperimeters hinweg nicht möglich ist (beide Ressourcen werden im Audit-Logeintrag genannt). Die Anfrage stammt von außerhalb des Perimeters (von der VM in public-network) und einer der Buckets befindet sich außerhalb des Perimeters (corp-resources-public-1).

Der Schreibvorgang in den Bucket corp-resources-public-1 von außerhalb des Perimeters kann ausgeführt werden. Die Prüfung, die im vorherigen Beispiel den Fehler ausgelöst hat, wird hier also bestanden. Bei der nachfolgenden Prüfung des eigentlichen Kopiervorgangs wird jedoch ein Fehler ausgegeben.

Dieses Beispiel zeigt, dass ein einzelner Nutzervorgang manchmal mehrere interne Vorgänge nach sich zieht, die eine Prüfung anhand der Regeln von VPC Service Controls bestehen müssen.

BigQuery-Dataset wird von einer VM innerhalb des Perimeters kopiert

In diesem Beispiel versucht eine VM im Projekt 927005422713 (perimeter-network), ein BigQuery-Dataset aus dem Projekt corp-resources-private in das Projekt corp-resources-public (117961063178) zu kopieren. perimeter-network und corp-resources-private teilen sich einen Perimeter, corp-resources-public befindet sich außerhalb des Perimeters.

Die VM führt den folgenden Befehl aus:

bq cp corp-resources-private:babynames.yob2000 \
  corp-resources-public:babynames.yob2000

Der Befehl gibt Folgendes zurück:

BigQuery error in cp operation: VPC Service Controls: Request is prohibited by
organization's policy. Operation ID: c00dbc44-460f-4bd0-9d09-cda98ac800f9

Der folgende Audit-Log-Eintrag wird generiert:

{
 insertId:  "146o5fd2hbp"
 logName:  "projects/perimeter-network/logs/cloudaudit.googleapis.com%2Fpolicy"
 protoPayload: {
  @type:  "type.googleapis.com/google.cloud.audit.AuditLog"
  authenticationInfo: {
  }
  metadata: {
   @type:  "type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
   resourceNames: [
    0:  "projects/117961063178"
   ]
   violationReason:  "RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER"
  }
  methodName:  "bigquery.googleapis.com/bigquery.tables.get"
  requestMetadata: {
   callerIp:  "131.201.221.16"
   callerNetwork:  "//compute.googleapis.com/projects/perimeter-network/global/networks/__unknown__"
   destinationAttributes: {
   }
   requestAttributes: {
   }
  }
  resourceName:  "projects/927005422713"
  serviceName:  "bigquery.googleapis.com"
  status: {
   code:  7
   details: [
    0: {
     @type:  "type.googleapis.com/google.rpc.PreconditionFailure"
     violations: [
      0: {
       type:  "VPC_SERVICE_CONTROLS"
      }
     ]
    }
   ]
   message:  "Request is prohibited by organization's policy"
  }
 }
 receiveTimestamp:  "2018-11-28T00:27:05.688803777Z"
 resource: {
  labels: {
   method:  "bigquery.googleapis.com/bigquery.tables.get"
   project_id:  "perimeter-network"
   service:  "bigquery.googleapis.com"
  }
  type:  "audited_resource"
 }
 severity:  "ERROR"
 timestamp:  "2018-11-28T00:27:05.378584819Z"
}

Aufgrund von Einschränkungen des Logging-Mechanismus und der verteilten Architektur von BigQuery liegt in diesem Beispiel keine einzelne zugrunde liegende API-Aktion vor, die alle an dieser Anfrage beteiligten Ressourcen aufzeigt.

Der Audit-Logeintrag zeigt, dass der Vorgang fehlgeschlagen ist, weil BigQuery über das Netzwerk im Projekt perimeter-network (die Quelle der Anfrage) auf das Zielprojekt (corp-resources-public) zugreifen muss, um die Daten zu kopieren. corp-resources-public befindet sich jedoch außerhalb des Perimeters, mit dem perimeter-network geschützt wird. Die Anfrage wird als Versuch, Daten an corp-resources-public zu übertragen, verweigert.

Das Beispiel veranschaulicht, dass ein allgemeiner Vorgang wie das Kopieren von Daten mehrere Datenzugriffsversuche von verschiedenen Speichersystemen auslösen kann, etwa Cloud Storage, BigQuery und Bigtable. Je nachdem, wie der Vorgang ausgeführt wird, kann der dabei erstellte Audit-Logeintrag vom ursprünglichen Nutzerbefehl abweichen, insbesondere wenn innerhalb eines Diensts mehrere Prüfungen durchgeführt werden und fehlschlagen können.

Dataproc-Job liest aus Projekt

In diesem Beispiel wird gezeigt, wie Sie indirekte VPC Service Controls-Fehler beheben, die auftreten, wenn Sie Datenverarbeitungsdienste wie Dataproc verwenden.

In diesem Beispiel wird ein Dataproc-Cluster in einem Projekt ausgeführt, das durch VPC Service Controls geschützt wird. Hello-world.py ist ein PySpark-Job, der versucht, auf Daten im Cloud Storage-Bucket innerhalb des Perimeters zuzugreifen und sie dann in einen Bucket außerhalb des Perimeters zu schreiben. Dieser Vorgang sollte von VPC Service Controls blockiert werden.

Hello-world.py wird mit dem folgenden Befehl ausgeführt:

gcloud dataproc jobs submit pyspark hello-world.py --cluster test-cluster-new2

Der Befehl gibt Folgendes zurück:

Job [50f16ca8-5102-442b-a545-eed5e4f5f5da] submitted.
Waiting for job output...
18/11/29 00:31:34 INFO org.spark_project.jetty.util.log: Logging initialized @2552ms
18/11/29 00:31:34 INFO org.spark_project.jetty.server.Server: jetty-9.3.z-SNAPSHOT
18/11/29 00:31:34 INFO org.spark_project.jetty.server.Server: Started @2640ms
18/11/29 00:31:34 INFO org.spark_project.jetty.server.AbstractConnector: Started ServerConnector@1f1c18ec{HTTP/1.1,[http/1.1]}{0.0.0.0:4040}
18/11/29 00:31:34 INFO com.google.cloud.hadoop.fs.gcs.GoogleHadoopFileSystemBase: GHFS version: 1.6.4-hadoop2
18/11/29 00:31:35 INFO org.apache.hadoop.yarn.client.RMProxy: Connecting to ResourceManager at test-cluster-new2-m/10.246.0.3:8032
18/11/29 00:31:37 INFO org.apache.hadoop.yarn.client.api.impl.YarnClientImpl: Submitted application application_1522454176466_0005
Traceback (most recent call last):
  File "/tmp/50f16ca8-5102-442b-a545-eed5e4f5f5da/hello-world.py", line 8, in <module>
    lear.saveAsTextFile("gs://corp-resources-public-1/out.txt")
  File "/usr/lib/spark/python/lib/pyspark.zip/pyspark/rdd.py", line 1553, in saveAsTextFile
  File "/usr/lib/spark/python/lib/py4j-0.10.4-src.zip/py4j/java_gateway.py", line 1133, in __call__
  File "/usr/lib/spark/python/lib/py4j-0.10.4-src.zip/py4j/protocol.py", line 319, in get_return_value
py4j.protocol.Py4JJavaError: An error occurred while calling o49.saveAsTextFile.
: java.io.IOException: Error accessing: bucket: corp-resources-public-1, object: out.txt
    at com.google.cloud.hadoop.gcsio.GoogleCloudStorageImpl.wrapException(GoogleCloudStorageImpl.java:1767)
$sp(PairRDDFunctions.scala:961)

 (truncated)

Caused by: com.google.api.client.googleapis.json.GoogleJsonResponseException: 403 Forbidden
{
  "code" : 403,
  "errors" : [ {
    "domain" : "global",
    "message" : "Request violates VPC Service Controls.",
    "reason" : "vpcServiceControls"
  } ],
  "message" : "Request violates VPC Service Controls."
}
    at com.google.api.client.googleapis.json.GoogleJsonResponseException.from(GoogleJsonResponseException.java:145)

 (truncated)

18/11/29 00:31:43 INFO org.spark_project.jetty.server.AbstractConnector: Stopped Spark@1f1c18ec{HTTP/1.1,[http/1.1]}{0.0.0.0:4040}
ERROR: (gcloud.dataproc.jobs.submit.pyspark) Job [50f16ca8-5102-442b-a545-eed5e4f5f5da] entered state [ERROR] while waiting for [DONE].

Achten Sie auf die E/A-Ausnahme, die beim Aufruf von saveAsTextFile auftritt. Cloud Storage gibt einen 403-Fehler mit der Meldung Request violates VPC Service Controls zurück. Der Fehler weist darauf hin, dass der Cloud Storage-Audit-Logvorgang überprüft werden sollte.

In den Audit-Logs für das Projekt perimeter-network, in dem der Befehl ausgeführt wurde, liegt ein Audit-Logeintrag für den Vorgang saveAsTextFile vor:

{
 insertId:  "qdj1o9d1run"
 logName:  "projects/corp-resources-private/logs/cloudaudit.googleapis.com%2Fpolicy"
 protoPayload: {
  @type:  "type.googleapis.com/google.cloud.audit.AuditLog"
  authenticationInfo: {
   principalEmail:  "1004338142803-compute@example.gserviceaccount.com"
  }
  metadata: {
   @type:  "type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
   resourceNames: [
    0:  "projects/_/buckets/corp-resources-public-1/objects/out.txt"
   ]
   violationReason:  "RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER"
  }
  methodName:  "google.storage.BillingRequiredRead"
  requestMetadata: {
   callerIp:  "10.246.0.3"
   callerNetwork:  "//compute.googleapis.com/projects/corp-resources-private/global/networks/__unknown__"
   destinationAttributes: {
   }
   requestAttributes: {
   }
  }
  resourceName:  "projects/1004338142803"
  serviceName:  "storage.googleapis.com"
  status: {
   code:  7
   details: [
    0: {
     @type:  "type.googleapis.com/google.rpc.PreconditionFailure"
     violations: [
      0: {
       type:  "VPC_SERVICE_CONTROLS"
      }
     ]
    }
   ]
   message:  "Request is prohibited by organization's policy"
  }
 }
 receiveTimestamp:  "2018-11-29T00:31:43.666227930Z"
 resource: {
  labels: {
   method:  "google.storage.BillingRequiredRead"
   project_id:  "corp-resources-private"
   service:  "storage.googleapis.com"
  }
  type:  "audited_resource"
 }
 severity:  "ERROR"
 timestamp:  "2018-11-29T00:31:43.608250320Z"
}

Aufgrund von Audit-Logeinschränkungen wird der methodName für Cloud Storage als Read aufgelistet, obwohl es sich um einen write-Vorgang handelt. Der Audit-Logeintrag zeigt, dass der Vorgang fehlgeschlagen ist, da ein Netzwerk in Projekt corp-resources-private versucht hat, auf die Daten einer Ressource im Bucket corp-resources-public-1 zuzugreifen (in diesem Fall per Schreibzugriff). Aufgrund der Einschränkungen des Audit-Logs von Cloud Storage kann nicht eindeutig festgestellt werden, welchem Projekt der Bucket corp-resources-public-1 angehört.

Mit dem folgenden Befehl wird das Projekt ermittelt, das corp-resources-public-1 enthält:

gsutil --debug ls -L -b gs://corp-resources-public-1 2>&1 | grep projectNumber

Der Befehl gibt Folgendes zurück:

projectNumber: u'117961063178'

117961063178 ist das Projekt corp-resources-public, das sich außerhalb des Perimeters befindet. Deshalb schlägt der Vorgang erwartungsgemäß fehl.

Nicht unterstützter Dienst mit eingeschränkter VIP

Der versuchte Zugriff auf eine API, die von der eingeschränkten VIP von VPC Service Controls nicht unterstützt wird, führt zu einem 404-Fehler. Da Cloud DNS derzeit z. B. nicht von VPC Service Controls unterstützt wird, ist die Cloud DNS API nicht verfügbar, wenn Sie die eingeschränkte VIP verwenden.

Der folgende beispielhafte Befehl wird ausgeführt:

gcloud dns managed-zones list

Der Befehl gibt Folgendes zurück:

ERROR: (gcloud.dns.managed-zones.list) Project [corp-resources-private] not found: <!DOCTYPE html>
<html lang=en>
  <meta charset=utf-8>
  <meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
  <title>Error 404 (Not Found)!!1</title>
  <style>
    *{margin:0;padding:0}html,code{font:15px/22px arial,sans-serif}html{background:#fff;color:#222;padding:15px}body{margin:7% auto 0;max-width:390px;min-height:180px;padding:30px 0 15px}* > body{background:url(//www.google.com/images/errors/robot.png) 100% 5px no-repeat;padding-right:205px}p{margin:11px 0 22px;overflow:hidden}ins{color:#777;text-decoration:none}a img{border:0}@media screen and (max-width:772px){body{background:none;margin-top:0;max-width:none;padding-right:0}}#logo{background:url(//www.google.com/images/branding/googlelogo/1x/googlelogo_color_150x54dp.png) no-repeat;margin-left:-5px}@media only screen and (min-resolution:192dpi){ #logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) no-repeat 0% 0%/100% 100%;-moz-border-image:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) 0}}@media only screen and (-webkit-min-device-pixel-ratio:2){ #logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) no-repeat;-webkit-background-size:100% 100%}}#logo{display:inline-block;height:54px;width:150px}
  </style>
  <a href=//www.google.com/><span id=logo aria-label=Google></span></a>
  <p><b>404.</b> <ins>That's an error.</ins>
  <p>The requested URL <code>/dns/v1/projects/corp-resources-private/managedZones</code> was not found on this server.  <ins>That's all we know.</ins>

Dieser Fehlertyp wird für Dienste erwartet, die nicht von VPC Service Controls unterstützt werden und über die eingeschränkte VIP nicht verfügbar sind. Wenn dieser Fehler jedoch für einen Dienst auftritt, der von VPC Service Controls unterstützt wird, sollten Sie die bekannten Diensteinschränkungen für diesen Dienst aufrufen und nachsehen, ob diese Einschränkung genannt wird. Wenn dies nicht der Fall ist, sollten Sie das Problem melden.

Logexport in ein Projekt außerhalb des Perimeters

In diesem Beispiel wird ein Logexport von VPC Service Controls blockiert. Das Exportziel, Projekt corp-resources-public, befindet sich außerhalb des Perimeters von VPC Service Controls, und die Senke wird im Projekt perimeter-network innerhalb des Perimeters erstellt.

Der folgende beispielhafte Befehl wird ausgeführt:

gcloud logging sinks describe example-sink

Der Befehl gibt Folgendes zurück:

destination: bigquery.googleapis.com/projects/corp-resources-public/datasets/logs
filter: |-
  resource.type="audited_resource"
  resource.labels.service="bigquery.googleapis.com"
name: example-sink
outputVersionFormat: V2
writerIdentity: serviceAccount:p927005422713-439672@gcp-sa-logging.iam.gserviceaccount.com

Der folgende Audit-Log-Eintrag wird generiert:

{
 insertId:  "e5i2i8cbqw"
 logName:  "projects/perimeter-network/logs/cloudaudit.googleapis.com%2Fpolicy"
 protoPayload: {
  @type:  "type.googleapis.com/google.cloud.audit.AuditLog"
  authenticationInfo: {
   principalEmail:  "p927005422713-439672@gcp-sa-logging.iam.gserviceaccount.com"
  }
  metadata: {
   @type:  "type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
   resourceNames: [
    0:  "corp-resources-public"
   ]
   violationReason:  "RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER"
  }
  methodName:  "google.cloud.bigquery.v2.TableDataService.InsertAll"
  requestMetadata: {
   callerIp:  "2002:a49:8c51::"
   destinationAttributes: {
   }
   requestAttributes: {
   }
  }
  resourceName:  "projects/927005422713"
  serviceName:  "bigquery.googleapis.com"
  status: {
   code:  7
   details: [
    0: {
     @type:  "type.googleapis.com/google.rpc.PreconditionFailure"
     violations: [
      0: {
       type:  "VPC_SERVICE_CONTROLS"
      }
     ]
    }
   ]
   message:  "Request is prohibited by organization's policy"
  }
 }
 receiveTimestamp:  "2018-11-29T17:32:19.287138882Z"
 resource: {
  labels: {
   method:  "google.cloud.bigquery.v2.TableDataService.InsertAll"
   project_id:  "perimeter-network"
   service:  "bigquery.googleapis.com"
  }
  type:  "audited_resource"
 }
 severity:  "ERROR"
 timestamp:  "2018-11-29T17:32:19.054662413Z"
}

Der Audit-Log-Eintrag wird für BigQuery generiert, nicht für Logging. Das liegt daran, dass BigQuery der Senkendienst ist, in den Logging zu schreiben versucht.

Der Export schlägt fehl, weil sich corp-resources-public außerhalb des Perimeters befindet, mit dem perimeter-network geschützt wird.

Dieses Beispiel veranschaulicht Folgendes: Wenn ein Google Cloud-Dienst ein GCP-internes verwaltetes Dienstkonto wie p927005422713-439672@gcp-sa-logging.iam.gserviceaccount.com verwendet, um einen anderen Google Cloud-Dienst aufzurufen, wird das "Netzwerkprojekt" der Anfrage (in diesem Fall perimeter-network) von dieser Identität abgeleitet. Dieselbe Identität stellt auch die Logexport-Ressource dar.

Dies ist ein gängiges Muster in Google Cloud, das für zahlreiche Fälle von Dienst-zu-Dienst-Interaktionen gilt.

BigQuery-Extraktion in Cloud Storage

In diesem Beispiel wird die Fehlerbehebung für fehlgeschlagene BigQuery-Extraktionen in Cloud Storage beschrieben.

Die Projekte corp-resources-private und perimeter-network werden durch einen Dienstperimeter geschützt. Das Projekt corp-resources-public befindet sich außerhalb des Perimeters.

Der folgende Befehl wird ausgeführt:

bq extract babynames.yob2000

Der Befehl gibt Folgendes zurück:

gs://corp-resources-public-1/export.txt
Waiting on bqjob_r47ee34109d02b41_000001676b27157c_1 ... (1s) Current status: DONE
BigQuery error in extract operation: Error processing job 'corp-resources-private:bqjob_r47ee34109d02b41_000001676b27157c_1': Access
Denied: BigQuery BigQuery: Permission denied while writing data.

In diesem Fall verweist der Fehler nicht ausdrücklich auf VPC Service Controls – bei einem Problem mit Identity and Access Management würde ein ähnlicher Fehler ausgegeben werden.

Der folgende Audit-Logeintrag wird generiert:

{
 insertId:  "4gbh6pe8jld7"
 logName:  "projects/corp-resources-private/logs/cloudaudit.googleapis.com%2Fdata_access"
 protoPayload: {
  @type:  "type.googleapis.com/google.cloud.audit.AuditLog"
  authenticationInfo: {
   principalEmail:  "storage-accessing@example.iam.gserviceaccount.com"
  }
  methodName:  "jobservice.jobcompleted"
  requestMetadata: {
   callerIp:  "10.5.0.4"
   callerNetwork:  "//compute.googleapis.com/projects/perimeter-network/global/networks/__unknown__"
   callerSuppliedUserAgent:  "google-api-python-client/1.6.5 (gzip),gzip(gfe)"
   destinationAttributes: {
   }
   requestAttributes: {
   }
  }
  resourceName:  "projects/corp-resources-private/jobs/bqjob_r47ee34109d02b41_000001676b27157c_1"
  serviceData: {
   @type:  "type.googleapis.com/google.cloud.bigquery.logging.v1.AuditData"
   jobCompletedEvent: {
    eventName:  "extract_job_completed"
    job: {
     jobConfiguration: {
      extract: {
       destinationUris: [
        0:  "gs://corp-resources-public-1/export.txt"
       ]
       sourceTable: {
        datasetId:  "babynames"
        projectId:  "corp-resources-private"
        tableId:  "yob2000"
       }
      }
     }
     jobName: {
      jobId:  "bqjob_r47ee34109d02b41_000001676b27157c_1"
      location:  "US"
      projectId:  "corp-resources-private"
     }
     jobStatistics: {
      createTime:  "2018-12-01T19:03:03.908Z"
      endTime:  "2018-12-01T19:03:05.494Z"
      startTime:  "2018-12-01T19:03:04.013Z"
     }
     jobStatus: {
      additionalErrors: [
       0: {
        code:  7
        message:  "Access Denied: BigQuery BigQuery: Permission denied while writing data."
       }
      ]
      error: {
       code:  7
       message:  "Access Denied: BigQuery BigQuery: Permission denied while writing data."
      }
      state:  "DONE"
     }
    }
   }
  }
  serviceName:  "bigquery.googleapis.com"
  status: {
   code:  7
   message:  "Access Denied: BigQuery BigQuery: Permission denied while writing data."
  }
 }
 receiveTimestamp:  "2018-12-01T19:03:05.532169998Z"
 resource: {
  labels: {
   project_id:  "corp-resources-private"
  }
  type:  "bigquery_resource"
 }
 severity:  "ERROR"
 timestamp:  "2018-12-01T19:03:05.503Z"
}

In diesem Audit-Logeintrag wird storage-accessing@example.iam.gserviceaccount.com als Identität ermittelt, die den Vorgang auszuführen versucht. Wir gehen in diesem Beispiel davon aus, dass storage-accessing@example.iam.gserviceaccount.com die erforderlichen IAM-Berechtigungen zum Ausführen des Befehls hat.

Da das Problem nicht auf die IAM-Berechtigungen zurückzuführen ist, sollten wir als Nächstes prüfen, ob VPC Service Controls-Fehler vorliegen.

Der Audit-Logeintrag für den Zieldienst (Cloud Storage) enthält detaillierte Informationen zu den Fehlerursachen:

{
 insertId:  "1bq397kcfj1"
 logName:  "projects/corp-resources-private/logs/cloudaudit.googleapis.com%2Fpolicy"
 protoPayload: {
  @type:  "type.googleapis.com/google.cloud.audit.AuditLog"
  authenticationInfo: {
   principalEmail:  "storage-accessing@example.iam.gserviceaccount.com"
  }
  metadata: {
   @type:  "type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
   resourceNames: [
    0:  "projects/1004338142803"
    1:  "projects/_/buckets/corp-resources-public-1"
   ]
   violationReason:  "RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER"
  }
  methodName:  "google.storage.BillingRequiredRead"
  requestMetadata: {
   callerIp:  "10.5.0.4"
   callerNetwork:  "//compute.googleapis.com/projects/perimeter-network/global/networks/__unknown__"
   destinationAttributes: {
   }
   requestAttributes: {
   }
  }
  resourceName:  "projects/1004338142803"
  serviceName:  "storage.googleapis.com"
  status: {
   code:  7
   details: [
    0: {
     @type:  "type.googleapis.com/google.rpc.PreconditionFailure"
     violations: [
      0: {
       type:  "VPC_SERVICE_CONTROLS"
      }
     ]
    }
   ]
   message:  "Request is prohibited by organization's policy"
  }
 }
 receiveTimestamp:  "2018-12-01T19:03:05.617451586Z"
 resource: {
  labels: {
   method:  "google.storage.BillingRequiredRead"
   project_id:  "corp-resources-private"
   service:  "storage.googleapis.com"
  }
  type:  "audited_resource"
 }
 severity:  "ERROR"
 timestamp:  "2018-12-01T19:03:05.420005215Z"
}

Aus diesem Log geht hervor, dass beide Projekte, 1004338142803 (corp-resources-private-1) und corp-resources-public, verwendet werden, um den Befehl abzuschließen. Da diese Projekte nicht dem gleichen Perimeter angehören, schlägt der Extraktionsjob fehl.

Dieses Beispiel zeigt, dass die Audit-Logs bei komplexen Vorgängen mit mehreren Diensten nützliche Fehlerbehebungsdaten zum Quell- und zum Zieldienst enthalten können.