Risolvere i problemi

Questa pagina elenca vari problemi che potresti riscontrare durante la configurazione dei Controlli di servizio VPC.

Trovare gli errori di Controlli di servizio VPC

Questa sezione descrive i seguenti metodi per individuare gli errori VPC nei log di controllo:

Utilizzare l'ID univoco dell'errore

Un errore generato dai Controlli di servizio VPC include un ID univoco che viene utilizzato per identificare gli audit log pertinenti.

Questa procedura utilizza i termini della documentazione di Logging. Per ulteriori informazioni, consulta Filtri di log di base.

Per ottenere informazioni su un errore utilizzando l'ID univoco:

Nella console Google Cloud, vai alla pagina Cloud Logging per il progetto all'interno del perimetro di servizio che ha attivato l'errore.

Vai a Cloud Logging
Nella casella del filtro di ricerca, inserisci l'ID univoco dell'errore.

Filtrare i log utilizzando i metadati

Per trovare errori relativi ai Controlli di servizio VPC, utilizza Cloud Logging.

Console

Questa procedura utilizza i termini della documentazione di Logging. Per ulteriori informazioni, consulta Filtri di log di base.

Per ottenere le ultime 24 ore di errori dei Controlli di servizio VPC in Logging:

Nella console Google Cloud, vai alla pagina Cloud Logging per il progetto all'interno del perimetro di servizio.

Vai a Cloud Logging

Nella casella del filtro di ricerca, inserisci quanto segue:

protoPayload.metadata.@type:"type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"

Nel menu del selettore di base delle risorse, seleziona Risorsa controllata.
Nel menu a discesa del selettore dell'intervallo di tempo, seleziona Ultime 24 ore.
(Facoltativo) Se vuoi trovare gli errori di Controlli di servizio VPC che si sono verificati durante un periodo diverso, utilizza il menu a discesa del selettore dell'intervallo di tempo.

gcloud

Per ottenere le ultime 24 ore di errori dei Controlli di servizio VPC, utilizza il seguente comando:
```
gcloud logging read 'protoPayload.metadata.@type:"type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"'
```
Per impostazione predefinita, il comando read è limitato alle ultime 24 ore. Per ottenere i log di Controlli di servizio VPC per un periodo diverso, utilizza uno dei seguenti comandi:
Per limitare i log in base alla data corrente:
```
gcloud logging read \
'protoPayload.metadata.@type:"type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"' \
  --freshness=DURATION
```
Dove:
- DURATION è un periodo di tempo formattato. Per ulteriori informazioni sulla formattazione, consulta i formati relativi a durata/ora per gcloud.
Ad esempio, per ottenere tutti gli errori di Controlli di servizio VPC che si sono verificati nell'ultima settimana:
```
gcloud logging read \
'protoPayload.metadata.@type:"type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"' \
  --freshness=7d
```

Per limitare i log a un periodo di tempo specifico:

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

Dove:

START_DATETIME e END_DATETIME sono stringhe di data/ora formattate. Per ulteriori informazioni sulla formattazione, consulta i formati di data/ora assoluti per gcloud.

Ad esempio, per ottenere tutti gli errori di Controlli di servizio VPC che si sono verificati tra il 22 e il 26 marzo 2019:

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"'

Servizi non supportati

Per ulteriori informazioni sui prodotti e i servizi supportati dai Controlli di servizio VPC, consulta la pagina Prodotti supportati.

Attenzione: sebbene sia possibile abilitare i servizi non supportati per accedere ai dati dei prodotti e servizi supportati, ti consigliamo di non farlo. Potrebbero verificarsi problemi imprevisti durante il tentativo di accedere a un servizio supportato utilizzando un servizio non supportato, specialmente all'interno dello stesso progetto.

I servizi non supportati potrebbero non funzionare affatto se abilitati in un progetto protetto dai Controlli di servizio VPC, in particolare quando i servizi di archiviazione a basso livello come Cloud Storage o Pub/Sub sono soggetti a limitazioni. Ti consigliamo di eseguire il deployment di servizi non supportati in progetti esterni ai perimetri. Per consentire a questi servizi di accedere ai dati nelle risorse all'interno di un perimetro, crea un livello di accesso che includa l'account di servizio per quel servizio e applicalo ai perimetri in base alle necessità.

Il tentativo di limitare un servizio non supportato utilizzando lo strumento a riga di comando gcloud o l'API Gestore contesto accesso comporterà un errore.

L'accesso tra progetti ai dati dei servizi supportati verrà bloccato dai Controlli di servizio VPC. Inoltre, il VIP con restrizioni può essere utilizzato per bloccare la capacità dei carichi di lavoro di chiamare i servizi non supportati.

VPC condiviso

Quando utilizzi un VPC condiviso, un perimetro di servizio che include i progetti che appartengono a una rete VPC condivisa deve includere anche il progetto che ospita la rete. Quando i progetti che appartengono a una rete VPC condiviso non si trovano nello stesso perimetro del progetto host, i servizi potrebbero non funzionare come previsto o essere bloccati completamente.

Assicurati che l'host di rete VPC condiviso si trovi nello stesso perimetro di servizio dei progetti collegati alla rete.

Richieste tra perimetri

Di solito, i livelli di accesso vengono utilizzati per consentire le richieste esterne a un perimetro di servizio per le risorse protette all'interno di un perimetro.

Tuttavia, una richiesta proveniente da un progetto in un perimetro per una risorsa protetta in un altro perimetro viene rifiutata, anche se in genere un livello di accesso consente la richiesta.

Ad esempio, supponiamo che il progetto A nel perimetro 1 richieda una risorsa al progetto B. La risorsa nel progetto B è protetta dal perimetro 2. Poiché il progetto A si trova in un perimetro, anche se un livello di accesso per il perimetro 2 consente di norma la richiesta per la risorsa protetta, la richiesta viene rifiutata.

Utilizza uno dei seguenti approcci per facilitare le richieste tra i perimetri:

Utilizza criterio in uscita e criterio in entrata. Per consentire le richieste da un altro perimetro alle risorse protette nel perimetro, l'altro perimetro deve utilizzare un criterio in uscita e devi impostare un criterio in entrata nel tuo perimetro.
Utilizza i bridge del perimetro. I bridge consentono a due o più progetti in perimetri diversi di effettuare richieste a qualsiasi servizio in quei progetti. Queste richieste sono consentite anche se i servizi sono protetti dai perimetri.
Assicurati che sia il servizio richiedente sia la risorsa di destinazione non siano protetti dai perimetri. In questo scenario, l'operazione ha esito positivo perché i servizi non sono protetti.

Determinare se un errore è dovuto a Controlli di servizio VPC

I Controlli di servizio VPC modificano le proprietà di Google Cloud e potrebbero avere effetti a cascata sui servizi di cui è difficile eseguire il debug se non sai cosa cercare.

Per identificare se l'errore è correlato ai Controlli di servizio VPC, controlla se hai abilitato i Controlli di servizio VPC e lo hai applicato ai progetti e ai servizi che stai tentando di utilizzare. Puoi verificare se i progetti e i servizi sono protetti dai Controlli di servizio VPC tramite lo strumento a riga di comando gcloud o la console Google Cloud.

Tieni presente che, indirettamente, utilizzi un servizio contrassegnato come servizio limitato dai Controlli di servizio VPC in un progetto all'interno di un perimetro di servizio. In tal caso, i Controlli di servizio VPC possono essere in colpa.

Per informazioni sui casi noti noti, consulta la sezione Limitazioni dei servizi noti.

In genere, i servizi propagano i messaggi di errore dalle loro dipendenze. Si verifica uno dei seguenti errori, che indica un problema con Controlli di servizio VPC.

Cloud Storage: 403: Request violates VPC Service Controls.
BigQuery: 403: VPC Service Controls: Request is prohibited by organization's policy.
Altri servizi: 403: Request is prohibited by organization's policy.

Violazioni delle regole in entrata e in uscita

Il log di controllo contiene informazioni sulle violazioni delle regole in entrata e in uscita che ti consentono di comprendere le violazioni dei perimetri.

Violazione della regola Ingress

Una violazione della regola in entrata indica che un client API all'esterno del perimetro ha tentato di accedere a una risorsa all'interno del perimetro. Il perimetro di servizio rifiuta la richiesta poiché non sono presenti regole di accesso o livelli di accesso corrispondenti.

Una violazione delle regole in entrata nell'audit log contiene i seguenti dettagli:

Il nome del perimetro in cui si è verificata la violazione della regola in entrata.
La risorsa all'interno del perimetro a cui il client API esterno al perimetro ha provato ad accedere.

Nel seguente esempio di violazione della regola in entrata, un client API all'esterno del perimetro tenta di accedere al bucket Cloud Storage prod-protected-storage-bucket all'interno del perimetro prod-perimeter.

ingressViolations: [
  0: {
    targetResource: "projects/1234/buckets/prod-protected-storage-bucket"
    servicePerimeter: "accessPolicies/123456789/servicePerimeters/prod-perimeter"
  }
]

Violazione delle regole in uscita

Una violazione delle regole in uscita nell'audit log indica uno dei seguenti eventi:

Un client API all'interno del perimetro ha tentato di accedere a una risorsa all'esterno del perimetro.
Una richiesta API che coinvolge una risorsa all'interno del perimetro e una risorsa esterna al perimetro. Ad esempio, un client Cloud Storage che chiama un comando copia in cui un bucket si trova all'interno del perimetro e l'altro è fuori dal perimetro.

Il perimetro di servizio rifiuta la richiesta perché non ci sono regole in uscita corrispondenti. Una violazione delle regole in uscita nell'audit log include i seguenti dettagli:

Il tipo di origine, come rete o risorsa.
L'origine, ovvero una risorsa o una rete, il cui perimetro ha riscontrato una violazione in uscita.
Il perimetro che ha riscontrato una violazione in uscita.
La risorsa di destinazione al di fuori del perimetro a cui la richiesta ha tentato di accedere.

Nel seguente esempio di violazione della regola di traffico in uscita, la richiesta API include una risorsa del progetto/5678, all'interno del perimetro prod-perimeter, e un oggetto del bucket Cloud Storage external-storage-bucket, all'esterno del perimetro.

egressViolations: [
  0: {
    sourceType: "Resource"
    source: "projects/5678"
    targetResource: "projects/4321/buckets/external-storage-bucket/objects/corp-resources.json"
    servicePerimeter: "accessPolicies/123456789/servicePerimeters/prod-perimeter"
  }
]

Richieste di debug bloccate dai Controlli di servizio VPC

L'audit log dei Controlli di servizio VPC è lo strumento principale per il debug di una richiesta bloccata da Controlli di servizio VPC.

Quando l'accesso è stato bloccato in modo imprevisto, consulta gli audit log nel progetto protetto dal perimetro di servizio. Questi log contengono dati significativi sulle risorse richieste e sul motivo per cui la richiesta è stata rifiutata. Per informazioni sui log di controllo, vedi Diagnosticare i problemi utilizzando lo strumento per la risoluzione dei problemi.

Le seguenti sezioni elencano i valori violationReason che potresti incontrare quando utilizzi i Controlli di servizio VPC.

NETWORK_NOT_IN_SAME_SERVICE_PERIMETER

Il motivo potrebbe essere uno dei seguenti:

Un client in una rete VPC all'interno di un perimetro di servizio tenta di accedere a un progetto che non si trova nello stesso perimetro. Questa richiesta genera una violazione in uscita. Crea una regola in uscita per risolvere il problema.
Un client in una rete VPC esterno a un perimetro di servizio tenta di accedere a un progetto protetto dal perimetro di servizio. Questa richiesta genera una violazione in entrata. Crea una regola in entrata per risolvere il problema.

Il client potrebbe inviare la richiesta da una VM di Compute Engine o Google Kubernetes Engine oppure da una rete on-premise tramite Cloud Interconnect o una rete VPN configurata utilizzando una rete VPC.

Il seguente diagramma mostra che si verifica una violazione in uscita quando un client in una rete VPC all'interno di un perimetro di servizio tenta di accedere a un progetto all'esterno del perimetro:

Una violazione in uscita a causa di NETWORK_NOT_IN_SAME_SERVICE_PERIMETER.

Ecco un esempio di violazione in uscita:

egressViolations: [
{
  servicePerimeter: "accessPolicies/<POLICY_NAME>/servicePerimeters/<PERIMETER_NAME>"
  source: "projects/<NETWORK_PROJECT_NUMBER>"
  sourceType: "Network"
  targetResource: "projects/<RESOURCE_PROJECT_NUMBER>"
}
]

Dove:

<POLICY_NAME> è il nome numerico del criterio di accesso.
<PERIMETER_NAME> è il nome del perimetro di servizio.
<NETWORK_PROJECT_NUMBER> è il numero del progetto Google Cloud che contiene la tua rete VPC.
<RESOURCE_PROJECT_NUMBER> è il numero del progetto Google Cloud che contiene la risorsa.

Il seguente diagramma mostra che si verifica una violazione in entrata quando un client all'esterno del perimetro tenta di accedere a un progetto all'interno del perimetro:

Una violazione in entrata dovuta a NETWORK_NOT_IN_SAME_SERVICE_PERIMETER.

Ecco un esempio di violazione in entrata:

ingressViolations: [
{
          targetResource: "projects/<RESOURCE_PROJECT_NUMBER>",
      source: "projects/<NETWORK_PROJECT_NUMBER>"
          servicePerimeter: "accessPolicies/<POLICY_NAME>/servicePerimeters/<PERIMETER_NAME>"
}
]

Dove:

<RESOURCE_PROJECT_NUMBER> è il numero del progetto Google Cloud che contiene la risorsa.
<NETWORK_PROJECT_NUMBER> è il numero del progetto Google Cloud che contiene la tua rete VPC.
<POLICY_NAME> è il nome numerico del criterio di accesso.
<PERIMETER_NAME> è il nome del perimetro di servizio.

RISORSE_NOT_IN_SAME_SERVICE_PERIMETER

Questo problema si verifica quando una singola richiesta accede a più risorse, ma le risorse non si trovano nello stesso perimetro di servizio. Questo problema si verifica a prescindere dalla posizione del client e dal fatto che il client abbia accesso alle risorse. Per risolvere il problema, crea una regola in uscita.

Il seguente diagramma mostra un client che accede alle risorse da un progetto al di fuori del perimetro e da un progetto all'interno del perimetro di servizio:

Una violazione in uscita dovuta a un client che accede alle risorse da un progetto al di fuori del perimetro.

Il seguente diagramma mostra un client che accede alle risorse da progetti che si trovano in due diversi perimetri di servizio ma i perimetri non comunicano tra loro:

Una violazione in uscita a causa di un client che accede alle risorse dei progetti che si trovano in due diversi perimetri di servizio.

Ecco un esempio di violazione in uscita:

egressViolations: [
{
  servicePerimeter: "accessPolicies/<POLICY_NAME>/servicePerimeters/<PERIMETER_NAME>"
  source: "projects/<RESOURCE_PROJECT_INSIDE_THIS_PERIMETER>"
  sourceType: "Resource"
  targetResource: "projects/<RESOURCE_PROJECT_OUTSIDE_THIS-PERIMETER>"
}
]

Dove:

<POLICY_NAME> è il nome numerico del criterio di accesso.
<PERIMETER_NAME> è il nome del perimetro di servizio.
<RESOURCE_PROJECT_INSIDE_THIS_PERIMETER> è il numero del progetto Google Cloud all'interno del perimetro.
<RESOURCE_PROJECT_OUTSIDE_THIS_PERIMETER> è il numero del progetto Google Cloud esterno al perimetro.

NO_MATCHING_ACCESS_LEVEL

Questo problema si verifica quando l'indirizzo IP, il requisito del dispositivo o l'identità dell'utente non corrispondono alle regole in entrata o ai livelli di accesso assegnati al perimetro. Ciò significa che un client che non fa parte della rete Google Cloud tenta di accedere alle risorse di rete di Google Cloud dall'esterno del perimetro. Ad esempio, l'indirizzo IP corrispondente al campo callerIp del record di controllo non corrisponde a nessun intervallo CIDR definito nei livelli di accesso per il perimetro di servizio.

Se l'indirizzo IP del chiamante non è presente o è visualizzato come indirizzo IP interno, la violazione potrebbe essere dovuta a un servizio Google Cloud non integrato con i Controlli di servizio VPC. Il motivo potrebbe essere che il servizio Google Cloud tenta di accedere a un servizio protetto e non funziona, come previsto.

Per risolvere questo problema, ti consigliamo di creare una regola in entrata anziché un livello di accesso, perché quest'ultima offre un controllo dell'accesso granulare.

Il seguente diagramma mostra un client che tenta di accedere alle risorse dall'esterno del perimetro:

Una violazione in entrata dovuta a NO_MATCHING_ACCESS_LEVEL.

Ecco un esempio di violazione in entrata:

authenticationInfo: {
  principalEmail: "EMAIL"
}
requestMetadata: {
callerIp: "<PUBLIC_IP_ADDRESS>"
deviceState: "Cross Organization"
}
ingressViolations: [
        {
          targetResource: "projects/<RESOURCE_PROJECT_NUMBER>",
          servicePerimeter: "accessPolicies/<POLICY_NAME>/servicePerimeters/<PERIMETER-NAME>"
        }
  ]

Dove:

<EMAIL> è l'indirizzo email dell'account di servizio o dell'utente autenticato.
<PUBLIC_IP_ADDRESS> è l'indirizzo IP del chiamante. Per un chiamante da Internet, si tratta dell'indirizzo IPv4 o IPv6 pubblico.
<RESOURCE_PROJECT_NUMBER> è il numero del progetto Google Cloud che contiene la risorsa.
<POLICY_NAME> è il nome numerico del criterio di accesso.
<PERIMETER_NAME> è il nome del perimetro di servizio.

Tieni presente che in questo caso, metadata.accessLevels potrebbe essere ancora presente poiché questi livelli di accesso potrebbero non essere specificati nel perimetro violato.

SERVICE_NOT_ALLOWED_FROM_VPC

Questo problema si verifica quando un client tenta di accedere alle risorse di Google Cloud da una rete VPC. Il client potrebbe inviare la richiesta da una VM di Compute Engine o Google Kubernetes Engine oppure da una rete on-premise tramite Cloud Interconnect o una rete VPN configurata utilizzando una rete VPC.

Per risolvere il problema, assicurati che il servizio chiamato sia consentito dalla configurazione dei servizi accessibili da VPC del perimetro di servizio.

Scenari di esempio

I seguenti esempi trattano i problemi che potresti riscontrare durante l'utilizzo dei Controlli di servizio VPC.

Accesso a Cloud Storage da on-premise
Accesso a BigQuery da una VM esterna al progetto
Query BigQuery tra progetti
Spostare il file Cloud Storage all'interno del perimetro
Spostare il file Cloud Storage all'esterno del perimetro
Copia del set di dati BigQuery dalla VM all'interno del perimetro
Lettura del job Dataproc dal progetto
Servizio non supportato con VIP con restrizioni
Esportazione dei log nel progetto al di fuori del perimetro
Estrazione di BigQuery in Cloud Storage

Accesso a Cloud Storage da on-premise

In questo esempio, i Controlli di servizio VPC bloccano una richiesta da una workstation del personale (identificata da callerIp) a un bucket Cloud Storage nel progetto corp-storage.

La richiesta genera il seguente record del log di controllo:

{
 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"
}

Il progetto corp-storage è incluso in un perimetro di servizio. La workstation del dipendente non fa parte di alcuna rete all'interno di quel perimetro. Poiché la workstation del dipendente esiste all'esterno del perimetro, la richiesta è bloccata.

Accesso a BigQuery da una VM esterna al progetto

In questo esempio, una VM che appartiene al progetto 458854174376 (data-collector) tenta di eseguire una query BigQuery su un set di dati nel progetto 798816221974 (corp-resources-protected) e viene rifiutata.

La VM utilizza la seguente query:

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

La query restituisce il seguente output:

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

Viene generato il seguente record dell'audit log:

{
 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"
}

In questo esempio, violationReason è NETWORK_NOT_IN_SAME_SERVICE_PERIMETER. callerNetwork è in aggiunta a callerIp. L'indirizzo IP è privato e viene fornita la rete per distinguerlo. Le risorse pertinenti in questione sono elencate in due posizioni: VpcServiceControlAuditMetadata.resourceNames e requestMetadata.callerNetwork (il progetto proprietario della rete).

Il problema è che il progetto corp-resources-protected si trova all'interno di un perimetro di servizio, mentre data-collector, il progetto che include la rete a cui appartiene la VM, non lo è. In questo caso, l'accesso viene negato come previsto.

Query BigQuery tra progetti

In questo esempio, una VM che appartiene al progetto perimeter-network tenta di eseguire query sulle istanze BigQuery di due diversi progetti: corp-resources-protected, che si trova nello stesso perimetro di servizio di perimeter-network, e corp-resources-public, che non lo è.

La VM utilizza il seguente comando:

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'

La query restituisce il seguente output:

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

Viene generato il seguente record dell'audit log:

{
 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"
}

Guardando callerNetwork e VpcServiceControlAuditMetadata.resourceNames, possiamo vedere tre progetti: perimeter-network, 117961063178 (corp-resources-public) e 690885588241 (corp-resources-protected). Ricorda che corp-resources-public non si trova nello stesso perimetro di servizio di perimeter-network e corp-resources-protected.

violationReason, RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER indica che la risorsa all'interno della richiesta si trova all'esterno di un perimetro che si applica alla richiesta. In questo caso, la risorsa è corp-resources-public.

Sposta il file di Cloud Storage all'interno del perimetro

In questo esempio, una VM nel progetto perimeter-network utilizza un comando per spostare un file da un bucket Cloud Storage, situato nel progetto corp-resources-protected, in un altro bucket, situato nel progetto corp-resources-public.

La VM utilizza il seguente comando:

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

Il comando restituisce il seguente output:

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

Viene generato il seguente record dell'audit log:

{
 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 questo caso, il log è meno chiaro perché il metodo elencato è BillingRequiredRead e l'azione intrapresa è move. Questo è un limite della funzionalità attuale degli audit log di Controlli di servizio VPC.

Sebbene il motivo sia meno chiaro, questo record del log di controllo indica che alcune risorse nella richiesta si trovano al di fuori di un perimetro che si applica alla richiesta. In questo caso, la risorsa è corp-resources-public.

Sposta il file di Cloud Storage fuori dal perimetro

In questo esempio, una VM nel progetto public-network utilizza un comando per spostare un file da un bucket Cloud Storage, situato nel progetto corp-resources-protected, in un altro bucket, situato nel progetto corp-resources-public.

corp-resources-protected è protetto da un perimetro di servizio. public-network e corp-resources-public esistono al di fuori del perimetro.

La VM utilizza il seguente comando:

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

Il comando restituisce il seguente output:

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

Viene generato il seguente record dell'audit log:

{
 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 questo esempio, l'audit log indica che non è possibile copiare dati lungo il confine di un perimetro di servizio (entrambe le risorse sono incluse nel record di audit log). Ricorda che la richiesta proviene dall'esterno del perimetro (la VM in public-network) e che uno dei bucket esiste al di fuori del perimetro (corp-resources-public-1).

All'esterno del perimetro, è possibile scrivere nel bucket corp-resources-public-1, quindi il controllo non riuscito nell'esempio precedente viene superato. Tuttavia, il controllo successivo per copiare i dati non va a buon fine.

Questo esempio mostra come a volte una singola operazione utente generi più operazioni interne che devono superare l'applicazione di Controlli di servizio VPC.

Copia del set di dati BigQuery dalla VM all'interno del perimetro

In questo esempio, una VM nel progetto 927005422713 (perimeter-network) tenta di copiare un set di dati BigQuery dal progetto corp-resources-private in corp-resources-public (117961063178). perimeter-network e corp-resources-private condividono un perimetro, mentre corp-resources-public esiste al di fuori del perimetro.

La VM utilizza il seguente comando:

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

Il comando restituisce il seguente output:

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

Viene generato il seguente record dell'audit log:

{
 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"
}

In questo esempio, non esiste una singola azione API sottostante che mostri tutte le risorse in gioco in questa richiesta a causa delle limitazioni del meccanismo di logging e dell'architettura distribuita di BigQuery.

Il record del log di controllo indica che l'operazione non è riuscita perché per copiare i dati, BigQuery deve accedere al progetto di destinazione (corp-resources-public) utilizzando la rete nel progetto perimeter-network (origine della richiesta). Ricorda che corp-resources-public non rientra nel perimetro che protegge perimeter-network. La richiesta viene rifiutata come tentativo di esfiltrazione dei dati in corp-resources-public.

Questo esempio illustra che un'operazione concettuale, come la copia dei dati, può attivare più tentativi di accesso ai dati da diversi sistemi di archiviazione, come Cloud Storage, BigQuery e Bigtable. A seconda di come viene eseguita l'operazione, il record di log di controllo generato differisce dal comando utente originale. Inoltre, quando vengono effettuati più controlli all'interno di un determinato servizio e questi ultimi potrebbero non superare il controllo, il record del log di controllo generato ha un aspetto diverso dal comando utente originale.

Lettura del job Dataproc dal progetto

Questo esempio mostra come eseguire il debug degli errori dei Controlli di servizio VPC indiretti che si verificano durante l'utilizzo di servizi di elaborazione dei dati come Dataproc.

In questo esempio, un cluster Dataproc è in esecuzione in un progetto protetto da Controlli di servizio VPC. Hello-world.py è un job pyspark che tenta di accedere ai dati dal bucket Cloud Storage all'interno del perimetro e di scriverli in un altro bucket esistente al di fuori del perimetro. Controlli di servizio VPC blocca l'operazione che scrive i dati in un bucket all'esterno del perimetro.

Per eseguire Hello-world.py, viene utilizzato il seguente comando:

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

Il comando restituisce il seguente output:

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].

Nota l'eccezione I/O che si verifica quando viene chiamato il metodo saveAsTextFile. Cloud Storage restituisce un errore 403 con il messaggio Request violates VPC Service Controls. L'errore indica che l'operazione del log di controllo di Cloud Storage deve essere rivista.

Negli audit log per il progetto perimeter-network, in cui è stato eseguito il comando, è presente un record del log di controllo per l'operazione saveAsTextFile:

{
 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"
}

A causa di limitazioni degli audit log, methodName per Cloud Storage è elencato come Read anche se in realtà è un'operazione di write. Il record del log di controllo indica che l'operazione non è riuscita perché una rete nel progetto corp-resources-private ha tentato di accedere ai dati (scrittura, in questo caso) di una risorsa nel bucket corp-resources-public-1. A causa delle limitazioni dell'audit log di Cloud Storage, non è chiaro a quale bucket di progetto appartiene corp-resources-public-1.

Per identificare il progetto che contiene corp-resources-public-1, utilizza il comando seguente:

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

Il comando restituisce il seguente output:

projectNumber: u'117961063178'

117961063178 è il progetto corp-resources-public, che è periferico. Pertanto, l'errore è previsto.

Servizio non supportato con VIP con restrizioni

Il tentativo di accedere a un'API non supportata dai Controlli di servizio VPC limita i risultati VIP con un errore 404. Ad esempio, Controlli di servizio VPC non supporta Cloud DNS, l'API Cloud DNS non è disponibile quando si utilizza il VIP con restrizioni.

Ad esempio, supponiamo che venga utilizzato il seguente comando:

gcloud dns managed-zones list

Il comando restituisce il seguente output:

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>

Questo tipo di errore è previsto per i servizi non supportati dai Controlli di servizio VPC e non disponibili nel VIP con restrizioni. Se questo errore si verifica per un servizio supportato dai Controlli di servizio VPC, ti consigliamo di controllare le limitazioni di servizio note per il servizio per verificare se si tratta di una limitazione nota. In caso contrario, il problema deve essere segnalato.

Esportazione di log nel progetto all'esterno del perimetro

In questo esempio, un'esportazione dei log è bloccata dai Controlli di servizio VPC. La destinazione dell'esportazione, il progetto corp-resources-public, non rientra nel perimetro dei Controlli di servizio VPC, mentre viene creato il sink nel progetto perimeter-network, all'interno del perimetro.

Ad esempio, supponiamo che venga utilizzato il seguente comando:

gcloud logging sinks describe example-sink

Il comando restituisce il seguente output:

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

Viene generato il seguente record dell'audit log:

{
 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"
}

Il record dell'audit log viene generato per BigQuery, non per il logging. Questo perché BigQuery è il servizio sink di cui Logging sta tentando di scrivere.

L'esportazione non riesce perché corp-resources-public esiste al di fuori del perimetro che protegge perimeter-network.

Questo esempio mostra che nei casi in cui un servizio Google Cloud chiama un altro utente utilizzando un account di servizio gestito interno a Google Cloud, come p927005422713-439672@gcp-sa-logging.iam.gserviceaccount.com, il "progetto di rete" (in questo caso, perimeter-network) della richiesta deriva da questa identità. La stessa identità rappresenta la risorsa di esportazione del log stessa.

Questo pattern è comune in Google Cloud e si applica a numerosi casi di interazione tra servizi.

Estrazione di BigQuery in Cloud Storage

Questo esempio descrive come eseguire il debug delle estrazioni di BigQuery non riuscite in Cloud Storage.

In questo esempio, corp-resources-private e perimeter-network sono progetti protetti da un perimetro di servizio. corp-resources-public è un progetto che esiste al di fuori del perimetro.

Supponiamo che sia stato utilizzato il seguente comando:

bq extract babynames.yob2000

Il comando restituisce il seguente output:

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 questo caso, l'errore non implicita in modo specifico Controlli di servizio VPC. Un errore simile viene visualizzato in caso di errore di Identity and Access Management.

Viene generato il seguente record dell'audit log:

{
 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 questo record del log di controllo, l'identità storage-accessing@example.iam.gserviceaccount.com viene identificata come l'identità che tenta di eseguire l'operazione. In questo esempio, supponiamo che storage-accessing@example.iam.gserviceaccount.com abbia le autorizzazioni IAM richieste per eseguire il comando.

Poiché le autorizzazioni IAM non sono il problema, il passaggio successivo consiste nel verificare la presenza di errori relativi ai Controlli di servizio VPC.

Il record dell'audit log per il servizio di destinazione (Cloud Storage) contiene i motivi dettagliati dell'errore:

{
 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"
}

Da questo log è chiaro che i due progetti 1004338142803 (corp-resources-private-1) e corp-resources-public vengono entrambi utilizzati per completare il comando. Poiché questi progetti non condividono un perimetro, l'estrazione del job non riesce.

Questo esempio illustra che, in operazioni multiservizio complesse, gli audit log per i servizi di origine e di destinazione potrebbero contenere dati di debug utili.