Risolvere i problemi comuni

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

Comportamento imprevisto delle norme basate sugli ambiti

Potresti notare alcune violazioni impreviste dei Controlli di servizio VPC che con ambito adeguato. È noto che se non disponi di un criterio di accesso a livello di organizzazione, potresti riscontrare alcuni problemi imprevisti con i criteri di accesso basati sugli ambiti.

Per risolvere il problema, crea un criterio di accesso a livello di organizzazione utilizzando il seguente comando:

gcloud access-context-manager policies create --organization <var>ORGANIZATION_ID</var> --title <var>POLICY_TITLE</var>

Sostituisci quanto segue:

  • ORGANIZATION_ID: l'ID organizzazione.
  • POLICY_TITLE: un titolo leggibile per i criteri di accesso.

Per ulteriori informazioni, vedi Creare un criterio di accesso.

VPC condiviso

Quando si utilizza un VPC condiviso, un perimetro di servizio che include progetti che appartengono in una rete VPC condiviso 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. come progetto host, i servizi potrebbero non funzionare come previsto o essere bloccati del tutto.

Assicurati che l'host della rete VPC condiviso si trovi nello stesso perimetro di servizio del ai progetti connessi alla rete.

Impossibile aggiungere una rete VPC

Quando provi ad aggiungere una rete VPC, può verificarsi il seguente errore a un perimetro di servizio:

ERROR: (gcloud.access-context-manager.perimeters.update) PERMISSION_DENIED: Permission 'compute.networks.get' denied on resource '//compute.googleapis.com/projects/PROJECT_NAME/global/networks/VPC_NETWORK_NAME' (or it may not exist)

Questo errore si verifica per uno dei seguenti motivi:

  • La rete VPC non esiste.
  • La rete VPC esiste, ma non ha una subnet.
  • Il chiamante non dispone dell'autorizzazione richiesta.

Per risolvere il problema, completa i seguenti passaggi:

  1. Verifica se la rete VPC specificata nel messaggio di errore esiste visualizzando reti nel tuo progetto.

    • Prima di verificare la rete VPC, assicurati che L'API Compute Engine è abilitata nel progetto associato alla chiamata API svolgendo i seguenti passaggi:

      1. Nella console Google Cloud, vai alla pagina API e servizi.
        Vai su API e servizi

      2. Nella pagina API e servizi, verifica se l'API Compute Engine è elencata.

      3. Se manca l'API Compute Engine, abilitala.
        Attivare l'API

  2. Verifica se esiste almeno una subnet nella rete VPC la visualizzazione subnet. Se non sono presenti subnet, aggiungi una subnet alla rete VPC.

  3. Verifica se il chiamante dispone della seguente autorizzazione sul progetto host del Rete VPC: compute.networks.get. Questa autorizzazione ti consente per visualizzare le reti VPC in un progetto.

    • Chiedi all'amministratore dell'organizzazione proprietaria del progetto host di alla rete VPC per concedere al chiamante un ruolo IAM con l'autorizzazione compute.networks.get per il progetto host. Ad esempio, il ruolo Visualizzatore rete Compute.

      Per ulteriori informazioni sulla concessione dei ruoli, consulta Gestire l'accesso alle app.

Assicurati di leggere le limitazioni associate all'utilizzo delle reti VPC nei perimetri di servizio.

Richieste tra perimetri

Normalmente, i livelli di accesso vengono utilizzati per consentire le richieste provenienti dall'esterno di un servizio per 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 un livello di accesso normalmente consente la richiesta.

Ad esempio, supponiamo che il progetto A nel perimetro 1 richieda una risorsa dal progetto B. La risorsa nel progetto B è protetta dal perimetro 2. Perché il Progetto A è attivo un perimetro, anche se un livello di accesso per il perimetro 2 consente per la risorsa protetta, la richiesta è stata rifiutata.

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

  • Utilizza i criteri di traffico in uscita e in entrata. Per consentire le richieste da un altro perimetro alle risorse protette nel tuo perimetro, l'altro perimetro deve utilizzare un criterio di uscita e devi impostare un criterio di ingresso nel tuo perimetro.

  • Utilizza i bridge perimetrali. I bridge consentono a due o più progetti in perimetri diversi di effettuare richieste a qualsiasi servizio nei progetti. Queste richieste sono consentite anche se sono protetti dai rispettivi perimetri.

  • Assicurati che sia il servizio richiedente sia la risorsa di destinazione siano non protetti dai perimetri. In questo scenario, l'operazione riesce perché i servizi non sono protetti.

L'indirizzo email non è valido o non esiste

Quando aggiorni un perimetro che contiene un principale eliminato, potresti visualizzare il messaggio di errore The email address is invalid or non-existent.

Per risolvere il problema, puoi eseguire una delle seguenti operazioni:

  • Rimuovi l'indirizzo email non valido dal perimetro, inclusi i livelli di accesso e le regole di ingresso e uscita.

    Puoi utilizzare la console Google Cloud o Google Cloud CLI.

  • Eseguire un'operazione collettiva (Solo Google Cloud CLI) se l'indirizzo email si trova in entrambi, la procedura di prova e il perimetro in modalità di applicazione forzata.

    1. Visualizza tutti i perimetri:
      gcloud access-context-manager perimeters list --format=list \
   --policy=<POLICY_NAME> > my-perimeters.yaml

    1. Rimuovi l'indirizzo email non valido dal file my-perimeters.yaml e salvalo come my-perimeters-updated.yaml.

    2. Sostituisci tutti i perimetri:

      gcloud access-context-manager perimeters replace-all --format=list \
    --source-file=my-perimeters-updated.yaml \
    --policy=<POLICY_NAME>

Violazioni delle regole in entrata e in uscita

Il log di controllo contiene informazioni sulle violazioni delle regole di ingresso e di uscita che ti aiutano a comprendere le violazioni del perimetro.

Violazione della regola in entrata

Una violazione della regola in entrata indica che un client API al di fuori del perimetro ha tentato di accedere a una risorsa all'interno del perimetro. Il perimetro di servizio rifiuta in quanto non esistono regole in entrata o livelli di accesso corrispondenti.

Una violazione della regola di ingresso 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 al di fuori del perimetro ha provato ad accedere.

Nel seguente esempio di violazione della regola di ingresso, un client API esterno al 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"
  }
]

Per risolvere il problema, crea una regola di ingresso per il tuo perimetro. Per saperne di più sulle regole in entrata, consulta Regole in entrata riferimento.

Violazione delle regole in uscita

Una violazione delle regole di uscita nel log di controllo indica uno dei seguenti eventi:

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

Il perimetro di servizio rifiuta la richiesta perché non esistono dati in uscita corrispondenti le regole del caso. Una violazione delle regole in uscita nell'audit log 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 rilevato un traffico in uscita violazione delle norme.
  • Il perimetro che ha rilevato una violazione in uscita.
  • La risorsa di destinazione al di fuori del perimetro a cui ha tentato di accedere la richiesta.

Nel seguente esempio di violazione delle regole in uscita, la richiesta API include una da projects/5678, che si trova all'interno del perimetro prod-perimeter, e un oggetto dal bucket Cloud Storage external-storage-bucket, che è fuori dal 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"
  }
]

Per risolvere il problema, crea una regola in uscita per il tuo perimetro. Per ulteriori informazioni sulle regole in uscita, consulta Regole in uscita riferimento.

Richieste di debug bloccate dai Controlli di servizio VPC

Il log di controllo dei Controlli di servizio VPC è lo strumento principale per eseguire il debug di una richiesta bloccata dai Controlli di servizio VPC.

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

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

NETWORK_NOT_IN_SAME_SERVICE_PERIMETER

Il motivo di questo problema 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 determina una violazione del traffico in uscita. Crea una regola in uscita per risolvere il problema.
  • Un client in una rete VPC esterna a un perimetro di servizio tenta di accedere a un progetto protetto dal perimetro di servizio. Questa richiesta comporta una violazione del traffico in entrata. Crea una regola in entrata per risolvere il problema.

Il client potrebbe inviare la richiesta da una VM Compute Engine o Google Kubernetes Engine o da una rete on-premise tramite Cloud Interconnect o una 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 esterno al perimetro:

Una violazione in uscita dovuta a 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 del 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 una violazione del traffico in entrata si verifica quando un client esterno il perimetro tenta di accedere a un progetto all'interno del perimetro:

Una violazione di accesso dovuta a NETWORK_NOT_IN_SAME_SERVICE_PERIMETER.

Ecco un esempio di violazione del traffico 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.

Risoluzione

Per risolvere il problema, crea una regola di ingresso o uscita per il tuo perimetro.

RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER

Questo problema si verifica quando una singola richiesta accede a più risorse, ma queste non si trovano nello stesso perimetro di servizio. Questo problema si verifica indipendentemente dove si trova il client e se quest'ultimo ha accesso alle risorse.

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

Una violazione in uscita dovuta al fatto che un client accede alle risorse da un progetto esterno perimetrale.

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

Una violazione in uscita dovuta a un client che accede alle risorse da progetti che sono 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 del 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.

Risoluzione

Per risolvere il problema, crea una regola in uscita per il perimetro.

NO_MATCHING_ACCESS_LEVEL

Questo problema si verifica quando l'indirizzo IP, il requisito del dispositivo o l'identità dell'utente. non corrisponde ad alcuna regola in entrata o livello di accesso assegnato 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 nessuno degli intervalli CIDR definiti 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 che non integrati con i Controlli di servizio VPC. Il motivo potrebbe essere che Il servizio Google Cloud tenta di accedere a un servizio protetto e non riesce, previsto.

Per risolvere il problema, ti consigliamo di creare una regola di ingresso anziché un livello di accesso, in quanto una regola di ingresso fornisce un controllo dell'accesso granulare.

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

Una violazione del traffico in entrata dovuta a NO_MATCHING_ACCESS_LEVEL.

Ecco un esempio di violazione di Ingress:

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.

    Se utilizzi un servizio Google Cloud che non tramite Controlli di servizio VPC assistenza, gli indirizzi email appartengono al dominio google.com vengono oscurati e sostituiti con google-internal. google-internal si riferisce alle identità interne di proprietà di Google.

  • <PUBLIC_IP_ADDRESS> è l'indirizzo IP dell'utente che chiama. 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 a partire da 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 Google Cloud da una rete VPC. Il client potrebbe inviare la richiesta da una VM Compute Engine o Google Kubernetes Engine o da una rete on-premise tramite Cloud Interconnect o una VPN configurata utilizzando una rete VPC.

Per risolvere il problema, assicurati che il servizio chiamato sia consentito dal VPC accessibile del perimetro di servizio.

Scenari di esempio

I seguenti esempi riguardano i problemi che potresti riscontrare durante l'utilizzo di 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 un dipendente (identificata da callerIp) a un bucket Cloud Storage nel progetto corp-storage.

La richiesta genera il seguente record di audit log:

{
 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. Il dipendente la workstation non fa parte di nessuna rete all'interno di quel perimetro. Poiché la workstation dei dipendenti è esterna al perimetro. La richiesta è bloccata.

Accesso a 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 la richiesta 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 di 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@developer.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, il valore violationReason NETWORK_NOT_IN_SAME_SERVICE_PERIMETER. callerNetwork è incluso oltre a callerIp. L'indirizzo IP è privato e la rete viene fornita per chiarire la situazione. Le risorse pertinenti in discussione 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 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 appartenente 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 di 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"
}

Esaminando 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 qualche risorsa nella richiesta si trova al di fuori di un perimetro che si applica alla richiesta. In questo caso, la risorsa è corp-resources-public.

Spostare il file Cloud Storage all'interno del perimetro

In questo esempio, una VM nel progetto perimeter-network utilizza un comando per spostare 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:

gcloud storage 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 un limite di L'attuale funzionalità di audit log dei Controlli di servizio VPC.

Anche se il motivo non è chiaro, questo record del log di controllo indica che qualche risorsa nella richiesta non rientra in un perimetro che si applica alla richiesta. In questo caso, la risorsa è corp-resources-public.

Spostare il file di Cloud Storage al di fuori 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.

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

La VM utilizza il seguente comando:

gcloud storage 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 di 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 i dati oltre il confine di un perimetro di servizio (entrambe le risorse sono nel record dell'audit log). Ricorda che la richiesta ha origine dall'esterno del perimetro (la VM in public-network) e che uno dei bucket esista al di fuori del perimetro (corp-resources-public-1).

Dall'esterno del perimetro, è possibile scrivere nel bucket corp-resources-public-1, quindi il controllo non è riuscito nel passaggi precedenti. Tuttavia, il controllo successivo per copiare effettivamente i dati non va a buon fine.

Questo esempio mostra come a volte un'operazione di un singolo utente genera 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) tenta di copiare un set di dati BigQuery dal progetto corp-resources-private al progetto corp-resources-public (117961063178). perimeter-network e corp-resources-private condividono un perimetro, mentre corp-resources-public si trova 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 di 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 un'unica azione API sottostante che mostri tutte le risorse in gioco in questa richiesta a causa delle limitazioni del meccanismo di registrazione 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 si trova al di fuori del perimetro che protegge perimeter-network. La richiesta viene rifiutata come tentativo di esfiltrare dati in corp-resources-public.

Questo esempio illustra che un'operazione concettuale, come la copia di dati, può attivare più tentativi di accesso ai dati da diversi sistemi di archiviazione, come Cloud Storage, BigQuery Bigtable. A seconda della modalità di esecuzione dell'operazione, il record del log di controllo generato è diverso dal comando utente originale. Inoltre, quando più i controlli interni a un determinato servizio vengono eseguiti e potrebbero non andare a buon fine, l'audit generato il record di log ha un aspetto diverso dal comando utente originale.

Lettura dei job Dataproc dal progetto

Questo esempio mostra come eseguire il debug degli errori indiretti di Controlli di servizio VPC che quando si utilizzano servizi di elaborazione dati come Dataproc.

In questo esempio, un cluster Dataproc è in esecuzione in un progetto protette dai Controlli di servizio VPC. Hello-world.py è un job pyspark che tenta di accedere ai dati del bucket Cloud Storage all'interno del perimetro e poi li scrive in un altro bucket esistente al di fuori del perimetro. I Controlli di servizio VPC bloccano l'operazione che scrive i dati in un bucket al di fuori del perimetro.

Il seguente comando viene utilizzato per eseguire Hello-world.py:

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

Prendi nota dell'eccezione IO 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 di audit log di Cloud Storage deve essere rivista.

Negli audit log per il progetto perimeter-network, in cui è stato inserito il comando eseguito, esiste un record di audit log 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@developer.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 delle limitazioni degli audit log, methodName per Cloud Storage è indicato come Read, anche se in realtà si tratta di un'operazione write. Il controllo record di log indica che l'operazione non è riuscita perché una rete nel progetto corp-resources-private stava tentando di accedere ai dati (scrivendo, in questo case) 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 del progetto appartiene corp-resources-public-1.

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

gcloud storage ls gs://corp-resources-public-1 --buckets --log-http 2>&1 | grep projectNumber

Il comando restituisce il seguente output: "projectNumber": "117961063178",

117961063178 è il progetto corp-resources-public, che si trova al di fuori del perimetro. Pertanto, l'errore è previsto.

Errore dovuto a servizi non supportati

Alcuni servizi Google Cloud dipendono da altri servizi Google Cloud dell'implementazione. Se un servizio non supportato, come App Engine viene utilizzato all'interno di un progetto protetto da un perimetro, le risorse del servizio potrebbero non essere accessibili.

Per informazioni sui casi problematici noti, consulta Limitazioni note dei servizi.

Servizio non supportato con VIP con limitazioni

Il tentativo di accedere a un'API non supportata dal VIP soggetto a restrizioni di Controlli di servizio VPC genera un errore 403. Ad esempio, i Controlli di servizio VPC non supportano App Engine, pertanto l'API amministratore di App Engine non è disponibile quando si utilizza il VIP limitato.

Ad esempio, supponiamo che venga utilizzato il seguente comando per elencare tutte App Engine all'interno di un perimetro di servizio:

gcloud app services list

Il comando restituisce il seguente output:

ERROR: (gcloud.app.services.list) User [***] does not have permission to access apps instance [***] (or it may not exist): <!DOCTYPE html>
<html lang=en>
  <meta charset=utf-8>
  <meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
  <title>Error 403 (Forbidden)!!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>403.</b> <ins>That's an error.</ins>
  <p>Your client does not have permission to get URL <code>/v1/apps/***/services</code> from this server.  <ins>That's all we know.</ins>

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

Esportazione dei log nel progetto all'esterno del perimetro

In questo esempio, un'esportazione dei log è bloccata dai Controlli di servizio VPC. La destinazione di esportazione, il progetto corp-resources-public, non si trova in Perimetro dei Controlli di servizio VPC, mentre il sink viene creato nel progetto perimeter-network, che si trova 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 di 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 del log di controllo viene generato per BigQuery, non per logging. Questo perché BigQuery è il sink in cui Logging sta tentando di scrivere.

L'esportazione non riesce perché corp-resources-public esiste all'esterno del perimetro che protegge perimeter-network.

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

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 è protetto 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 riguarda in modo specifico i Controlli di servizio VPC. Un errore simile viene visualizzato in caso di errore di 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 di audit log, storage-accessing@example.iam.gserviceaccount.com è identificato come l'identità che tenta di eseguire l'operazione. In questo esempio, assumere che storage-accessing@example.iam.gserviceaccount.com abbia le autorizzazioni IAM necessarie per eseguire il comando.

Poiché il problema non è le autorizzazioni IAM, il passaggio successivo è verifica la presenza di errori dei 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 entrambi utilizzati per completarlo. Poiché questi progetti non condividono un perimetro, il job di estrazione non va a buon fine.

Questo esempio mostra che in operazioni complesse con più servizi, i log di controllo per i servizi di origine e di destinazione potrebbero contenere dati utili per il debug.

Accesso perimetrale tramite gateway Cloud NAT

In questo esempio, supponiamo che il progetto A dell'organizzazione A non sia configurato in nessuna perimetrale. Il progetto B è protetto da un perimetro in un'altra organizzazione. Le risorse private nel progetto A utilizzano il gateway Cloud NAT per raggiungere API e servizi internet e di Google. Un livello di accesso è configurato nel progetto B per consentire l'accesso in base agli indirizzi IP del gateway esterno del progetto A.

Una VM appartenente al progetto A (che può essere un nodo Google Kubernetes Engine) tenta di accedere a una risorsa protetta nel progetto B, ma la connessione non riesce, e nel progetto B viene generato il seguente record di audit log:

{
  "protoPayload": {
    "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
    "status": {
      "code": 7,
      "message": "Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier: kmpY9Fgfuhgi2NE90lURjFWuiS1nGRqxCw4L12HdW8h46Un__-_LZw",
      "details": [
        {
          "@type": "type.googleapis.com/google.rpc.PreconditionFailure",
          "violations": [
            {
              "type": "VPC_SERVICE_CONTROLS",
              "description": "kmpY9Fgfuhgi2NE90lURjFWuiS1nGRqxCw4L12HdW8h46Un__-_LZw"
            }
          ]
        }
      ]
    },
    "authenticationInfo": {
      "principalEmail": "my-user@example.iam.gserviceaccount.com",
      "serviceAccountKeyName": "//iam.googleapis.com/projects/my-project/serviceAccounts/my-user@example.iam.gserviceaccount.com/keys/<code><var>ACCOUNT_KEY</var></code>"
    },
    "requestMetadata": {
      "callerIp": "gce-internal-ip",
      "requestAttributes": {},
      "destinationAttributes": {}
    },
    "serviceName": "cloudfunctions.googleapis.com",
    "methodName": "google.cloud.functions.v1.CloudFunctionsService.ListFunctions",
    "resourceName": "<code><var>PROJECT_ID_1</var></code>",
    "metadata": {
      "violationReason": "NETWORK_NOT_IN_SAME_SERVICE_PERIMETER",
      "resourceNames": [
        "projects/<code><var>PROJECT_ID_2</var></code>/locations/-"
      ],
      "securityPolicyInfo": {
        "servicePerimeterName": "accessPolicies/<code><var>ACCESS_POLICY</var></code>/servicePerimeters/us_sandbox",
        "organizationId": "<code><var>ORGANIZATION_ID</var></code>"
      },
      "deviceState": "Unknown",
      "vpcServiceControlsUniqueId": "kmpY9Fgfuhgi2NE90lURjFWuiS1nGRqxCw4L12HdW8h46Un__-_LZw",
      "ingressViolations": [
        {
          "targetResource": "projects/<code><var>PROJECT_ID_1</var></code>",
          "servicePerimeter": "accessPolicies/<code><var>ACCESS_POLICY</var></code>/servicePerimeters/<code><var>PERIMETER_NAME</var></code>",
          "source": "<code><var>PROJECT_ID_2</var></code>"
        }
      ],
      "@type": "type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
    }
  },
  "insertId": "tzf7fd103i",
  "resource": {
    "type": "audited_resource",
    "labels": {
      "service": "cloudfunctions.googleapis.com",
      "method": "google.cloud.functions.v1.CloudFunctionsService.ListFunctions",
      "project_id": "<code><var>PROJECT_ID_2</var></code>"
    }
  },
  "timestamp": "2024-04-02T19:56:10.770681816Z",
  "severity": "ERROR",
  "logName": "projects/<code><var>PROJECT_ID_2</var></code>/logs/cloudaudit.googleapis.com%2Fpolicy",
  "receiveTimestamp": "2024-04-02T19:56:11.463811603Z"
}

La risorsa callerIp non registra un indirizzo IP esterno. Invece di all'indirizzo IP esterno del gateway Cloud NAT, la risorsa callerIp mostra gce-internal-ip.

Il campo callerIp viene oscurato in gce-internal-ip quando le richieste provengono da un altro progetto o da un'altra organizzazione e la fonte La VM di Compute Engine non ha un indirizzo IP esterno.

Cloud NAT un'integrazione con l'accesso privato Google che abilita automaticamente l'accesso privato Google sulla subnet della risorsa, e mantiene interno il traffico verso le API e i servizi Google, anziché il routing a internet utilizzando il gateway Cloud NAT esterno Indirizzo IP.

In questo caso, poiché il traffico viene instradato all'interno della rete Google interna, Il campo RequestMetadata.caller_ip dell'oggetto AuditLog è oscurato in gce-internal-ip. Per risolvere il problema, invece di utilizzare Cloud NAT indirizzo IP esterno del gateway nel livello di accesso per la lista consentita basata su IP, configurare una regola in entrata da consentire dall'account del progetto o di servizio.

Passaggi successivi