Risolvere i problemi

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

In questa pagina sono elencati i vari problemi che potresti riscontrare durante la configurazione dei Controlli di servizio VPC.

Trovare gli errori di Controlli di servizio VPC

In questa sezione sono descritti i metodi seguenti per trovare errori VPC nei log di controllo:

Utilizzo dell'ID univoco dell'errore

Un errore generato dai Controlli di servizio VPC include un ID univoco 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 mediante l'ID univoco:

  1. In Google Cloud Console, vai alla pagina Stackdriver Logging per il progetto all'interno del perimetro di servizio che ha attivato l'errore.

    Vai alla pagina Stackdriver Logging

  2. 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:

  1. In Google Cloud Console, vai alla pagina Stackdriver Logging per il progetto all'interno del perimetro di servizio.

    Vai alla pagina Stackdriver Logging

  2. Nella casella del filtro di ricerca, inserisci quanto segue:

    protoPayload.metadata.@type:"type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
    
  3. Nel menu del selettore di base delle risorse, seleziona Risorsa controllata.

  4. Nel menu a discesa del selettore dell'intervallo di tempo, seleziona Ultime 24 ore.

  5. Facoltativo: se vuoi trovare gli errori 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 comando seguente:

    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:

    Ad esempio, per ottenere tutti gli errori dei 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 formattate stringhe data/ora. Per ulteriori informazioni sulla formattazione, consulta i formati assoluti di data/ora 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 servizi supportati dai Controlli di servizio VPC, consulta la pagina Prodotti supportati.

Il tentativo di limitare un servizio non supportato utilizzando lo strumento a riga di comando gcloud o l'API Access Context Manager comporterà un errore.

L'accesso tra progetti a dati di 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 servizi non supportati.

VPC condiviso

Quando utilizzi una rete VPC condivisa, un perimetro di servizio che include 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 condivisa 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 connessi 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 da un progetto in un perimetro per una risorsa protetta in un altro perimetro viene rifiutata, anche se di solito il livello di accesso la consente.

Supponi ad esempio 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 normalmente consente la richiesta della 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 di un altro perimetro alle risorse protette nel tuo perimetro, l'altro perimetro deve utilizzare un criterio in uscita e devi impostare un criterio in entrata nel perimetro.

  • Utilizza i bridge del perimetro. I bridge consentono a due o più progetti in perimetri diversi di effettuare richieste a qualsiasi servizio in tali 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.

Determinazione dell'errore dovuto ai controlli di servizio VPC

I Controlli di servizio VPC modificano le proprietà di Google Cloud e potrebbero avere effetti a cascata su servizi che sono difficili da sottoporre a debug se non sai cosa cercare.

Per identificare se l'errore è relativo 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 Google Cloud Console.

Considera che utilizzi indirettamente un servizio contrassegnato come servizio limitato dai controlli di servizio VPC in un progetto che si trova all'interno di un perimetro di servizio. In tal caso, i Controlli di servizio VPC possono essere in errore.

Per informazioni sui casi problematici noti, consulta le limitazioni per i servizi noti.

Di solito, i servizi propagano i messaggi di errore dalle loro dipendenze. Se riscontri uno dei seguenti errori, è 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.

Debug di una richiesta bloccata per motivi imprevisti da parte dei controlli di servizio VPC

Il log di controllo Controlli di servizio VPC è lo strumento principale per eseguire 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 all'origine della richiesta. Questi log contengono dati significativi sulle risorse richieste e sul motivo del rifiuto della richiesta.

Per ulteriori informazioni sulla visualizzazione dei log, consulta la sezione Utilizzo di Esplora log.

Nella tabella seguente sono elencati i valori di violationReason che potresti incontrare quando utilizzi i Controlli di servizio VPC.

motivo della violazione Spiegazione
RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER Le risorse elencate in resourceNames nel record del log di controllo non si trovano nello stesso perimetro di servizio.
NETWORK_NOT_IN_SAME_SERVICE_PERIMETER Le risorse corrispondenti a callerNetwork e resourceNames nel record dell'audit log non si trovano nello stesso perimetro di servizio.
NO_MATCHING_ACCESS_LEVEL

L'indirizzo IP, il requisito del dispositivo o l'identità dell'utente non corrispondono ad alcuna regola in entrata o livelli di accesso assegnati al 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 viene visualizzato come indirizzo IP interno, questa violazione potrebbe essere dovuta a un servizio Google Cloud non integrato con i Controlli di servizio VPC. Il servizio Google Cloud cerca di accedere a un servizio protetto e ha esito negativo come previsto.

SERVICE_NOT_ALLOWED_FROM_VPC Il servizio chiamato non è consentito dalla configurazione dei servizi accessibili da VPC del perimetro di servizio.

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 aiutano a comprendere le violazioni del perimetro.

Violazione 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 esistono regole di entrata o livelli di accesso corrispondenti.

Una violazione delle regole in entrata nel log di controllo 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 fuori dal 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 regole in uscita

Una violazione delle regole in uscita nel log di controllo 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 all'esterno del perimetro. Ad esempio, un client Cloud Storage chiama un comando di copia in cui un bucket si trova all'interno del perimetro e l'altro bucket è all'esterno del perimetro.

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

  • Il tipo di origine, ad esempio 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 del traffico in uscita.
  • La risorsa di destinazione al di fuori del perimetro a cui la richiesta ha tentato di accedere.

Nell'esempio di violazione delle regole del traffico in uscita riportato di seguito, la richiesta API include una risorsa del progetto projects/5678, all'interno del perimetro prod-perimeter, e un oggetto del bucket Cloud Storage external-storage-bucket, che si trova 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"
  }
]

Scenari di esempio

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

Accesso a Cloud Storage da on-premise

In questo esempio, Controlli di servizio VPC blocca una richiesta da una workstation di lavoro del dipendente (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 al di fuori del perimetro, la richiesta è bloccata.

Accesso BigQuery dalla VM all'esterno del 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 questa 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 del log di controllo:

{
 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 è incluso in callerIp. L'indirizzo IP è privato e viene fornita dalla rete per rimuoverlo. 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 progetti diversi: 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 del log di controllo:

{
 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 alcune risorse nella richiesta si trovano all'esterno di un perimetro che si applica alla richiesta. In questo caso, la risorsa è corp-resources-public.

Sposta file 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, a 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 del log di controllo:

{
 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. Si tratta di una limitazione della funzionalità attuale degli audit log per i Controlli di servizio VPC.

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

Sposta il file Cloud Storage all'esterno del 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, a 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 del log di controllo:

{
 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 contenute nel record dell'audit log). Ricorda che la richiesta proviene dall'esterno del perimetro (la VM in public-network) e che uno dei bucket esiste all'esterno del perimetro (corp-resources-public-1).

All'esterno del perimetro, si è in grado di scrivere nel bucket corp-resources-public-1, in modo che il controllo che non vada a buon fine nell'esempio precedente venga superato. Tuttavia, il controllo successivo che consente di copiare i dati non va a buon fine.

Questo esempio mostra come a volte una singola operazione utente porti a più operazioni interne che devono superare l'applicazione dei 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) cerca di copiare un set di dati BigQuery dal progetto corp-resources-private a corp-resources-public (117961063178). perimeter-network e corp-resources-private condividono un perimetro, mentre corp-resources-public esiste all'esterno 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 del log di controllo:

{
 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 (l'origine della richiesta). Ricorda che corp-resources-public non fa parte del perimetro che protegge perimeter-network. La richiesta viene rifiutata perché tenta di esfiltrare i dati verso 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. In base alla modalità di esecuzione dell'operazione, il record dell'audit log generato è diverso dal comando dell'utente originale. Inoltre, quando vengono eseguiti più controlli all'interno di un determinato servizio che potrebbero non riuscire, il record dell'audit log generato ha un aspetto diverso dal comando dell'utente originale.

Lettura del job Dataproc sul progetto

Questo esempio mostra come eseguire il debug degli errori di Controllo di servizio VPC indiretto che si verificano durante l'utilizzo di servizi di elaborazione 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 poi 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 al di fuori del perimetro.

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

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 IO che si verifica quando viene richiamato 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 esaminata.

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 del log di controllo, la methodName di Cloud Storage è elencata 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 stava tentando di accedere ai dati (in questo caso) di una risorsa nel bucket corp-resources-public-1. A causa delle limitazioni del log di controllo di Cloud Storage, non è chiaro a quale bucket di progetto corp-resources-public-1 appartenga.

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 si trova all'esterno del perimetro. Di conseguenza, l'errore è previsto.

Servizio non supportato con VIP con restrizioni

Il tentativo di accedere a un'API non supportata dai Controlli di servizio VPC ha limitato i risultati VIP in 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 sul VIP con restrizioni. Se si verifica questo errore per un servizio supportato dai controlli di servizio VPC, ti consigliamo di controllare le limitazioni note per i servizi per verificare se si tratta di una limitazione nota. In caso contrario, il problema deve essere segnalato.

Esportazione dei log nel progetto all'esterno del perimetro

In questo esempio, un'esportazione dei log è bloccata da Controlli di servizio VPC. La destinazione di esportazione, il progetto corp-resources-public, si trova all'esterno del perimetro dei Controlli di servizio VPC, mentre il sink viene creato 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 del log di controllo:

{
 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 Logging. Questo perché BigQuery è il servizio sink a 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 che utilizza un account di servizio gestito da interno a GCP, come p927005422713-439672@gcp-sa-logging.iam.gserviceaccount.com, il "progetto di rete" (in questo caso perimeter-network) della richiesta è ricavato da tale 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 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 implica nello specifico i Controlli di servizio VPC. Un errore simile viene mostrato se si verifica un errore in Identity and Access Management.

Viene generato il seguente record del log di controllo:

{
 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 è identificata come identità che tenta di eseguire l'operazione. In questo esempio, supponiamo che storage-accessing@example.iam.gserviceaccount.com disponga delle autorizzazioni IAM richieste per eseguire il comando.

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

Il record del log di controllo 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 utilizzati entrambi per completare il comando. Siccome questi progetti non condividono un perimetro, il job di estrazione 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.