Risolvi i problemi comuni dei Controlli di servizio VPC con i servizi Google Cloud services

Questa pagina fornisce alcune soluzioni ai problemi che potresti riscontrare quando utilizzi un servizioGoogle Cloud che si trova all'interno di un perimetro di Controlli di servizio VPC.

Problemi di Cloud Build

L'utilizzo delle risorse Cloud Build all'interno di un perimetro dei Controlli di servizio VPC ha alcune limitazioni note. Per ulteriori informazioni, scopri le limitazioni dell'utilizzo dei Controlli di servizio VPC con Cloud Build.

Il service account Cloud Build non può accedere alle risorse protette

Cloud Build utilizza il service account Cloud Build per eseguire le build per tuo conto. Per impostazione predefinita, quando una build su Cloud Build viene eseguita in un progetto tenant al di fuori del progetto.

Le VM worker di Cloud Build che generano output di build si trovano al di fuori del perimetro dei Controlli di servizio VPC, anche se il progetto si trova all'interno del perimetro. Affinché le build possano accedere alle risorse all'interno del perimetro, devi perciò concedere al service account Cloud Build l'accesso al perimetro dei Controlli di servizio VPC aggiungendolo al livello di accesso o alla regola in entrata.

Per ulteriori informazioni, consulta Concedere al service account Cloud Build l'accesso al perimetro dei Controlli di servizio VPC.

Problemi di Cloud Storage

Negazioni quando si sceglie come target un bucket Cloud Storage di logging inesistente

Se il bucket di log specificato non esiste, i Controlli di servizio VPC negano l'accesso con il motivo della violazione RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER.

Puoi esaminare il log della negazione dell'accesso utilizzando l'identificatore univoco dei Controlli di servizio VPC (vpcServiceControlUniqueIdentifier). Di seguito è riportato un log di esempio con il motivo della violazione RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER:

"serviceName": "storage.googleapis.com",
"methodName": "google.storage.buckets.update",
"resourceName": "projects/325183452875",
"metadata": {
  "violationReason": "RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER",
  ...
  "egressViolations": [
    {
      "sourceType": "Resource",
      "targetResource": "projects/0/buckets/this-bucket-does-not-exist",
      "source": "projects/325183452875/buckets/bucket-in-same-project",
      "servicePerimeter": "accessPolicies/875573620132/servicePerimeters/prod_perimeter"
    }]}

Se il campo targetResource nell'oggetto egressViolations mostra una destinazione con projects/0/buckets, viene sempre attivata una negazione perché projects/0 non esiste ed è considerato al di fuori del perimetro di servizio.

Negazioni durante l'accesso ai bucket Cloud Storage pubblici di proprietà di Google

Un perimetro di servizio non può contenere progetti di organizzazioni diverse. Un perimetro può contenere solo progetti della rispettiva organizzazione padre. Esistono alcune limitazioni per accedere ai bucket Cloud Storage da progetti all'interno di un perimetro dei Controlli di servizio VPC che si trova in un'altra organizzazione.

Un esempio tipico è quando occorre accedere ai bucket Cloud Storage di proprietà di Google. Poiché il tuo progetto e quello di proprietà di Google che contiene il bucket di destinazione non si trovano nello stesso perimetro, i Controlli di servizio VPC negano la richiesta con il motivo della violazione RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER.

Per risolvere il problema, puoi creare regole in entrata e in uscita.

Accesso a un bucket Cloud Storage accessibile pubblicamente da un perimetro

Se provi ad accedere a un bucket Cloud Storage accessibile pubblicamente da un perimetro di servizio, i Controlli di servizio VPC potrebbero bloccare le tue richieste generando una violazione in uscita.

Per garantire che l'accesso all'oggetto riesca in modo coerente in base alle necessità, occorre applicare una regola in uscita al perimetro di servizio interessato.

Problemi di Security Command Center

Questa sezione elenca i problemi che potresti riscontrare durante l'utilizzo delle risorse di Security Command Center che si trovano all'interno di un perimetro dei Controlli di servizio VPC.

Security Command Center non può inviare notifiche a Pub/Sub

Il tentativo di pubblicare notifiche di Security Command Center in un argomento Pub/Sub all'interno di un perimetro dei Controlli di servizio VPC non riesce e viene segnalata la violazione RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER.

Ti consigliamo di attivare Security Command Center a livello di organizzazione. I Controlli di servizio VPC non considerano un'organizzazione padre come parte del perimetro dei progetti secondari. Affinché questa operazione riesca, devi consentire a Security Command Center di accedere al perimetro.

Per risolvere il problema, puoi procedere in uno dei seguenti modi:

  • Utilizza un argomento Pub/Sub in un progetto che non si trova in un perimetro di servizio.
  • Rimuovi l'API Pub/Sub dal perimetro di servizio finché la configurazione delle notifiche non è completata.

Per ulteriori informazioni sull'attivazione delle notifiche di Security Command Center inviate a un argomento Pub/Sub, scopri come attivare le notifiche sui risultati per Pub/Sub.

Security Command Center non può eseguire la scansione delle risorse Compute Engine all'interno di un perimetro

Security Command Center esegue la scansione delle risorse Compute Engine nei progetti utilizzando il service account per prodotto e per progetto (P4SA) service-{project_number}@gcp-sa-computescanning.iam.gserviceaccount.com. Affinché Security Command Center possa accedere alle risorse all'interno del perimetro, è necessario aggiungere l'account P4SA al livello di accesso o alla regola in entrata. In caso contrario, potresti visualizzare un errore NO_MATCHING_ACCESS_LEVEL.

Security Command Center non può eseguire la scansione delle risorse all'interno di un perimetro di servizio

Security Health Analytics esegue la scansione delle risorse nei progetti utilizzando il service account P4SA (per prodotto, per progetto) service-org-ORGANIZATION_ID@security-center-api.iam.gserviceaccount.com. Affinché Security Command Center possa accedere alle risorse all'interno del perimetro, è necessario aggiungere l'account P4SA al livello di accesso o alla regola in entrata. In caso contrario, vedrai l'errore NO_MATCHING_ACCESS_LEVEL.

Problemi di Google Kubernetes Engine

Questa sezione elenca i problemi che potresti riscontrare durante l'utilizzo delle risorse Google Kubernetes Engine all'interno di un perimetro dei Controlli di servizio VPC.

Il gestore della scalabilità automatica non funziona nei perimetri in cui sono abilitati servizi accessibili e servizi limitati

autoscaling.googleapis.com non è integrato con i Controlli di servizio VPC, perciò non può essere aggiunto ai servizi limitati né a quelli accessibili. Non è possibile consentire l'API autoscaling.googleapis.com nei servizi accessibili. Di conseguenza, il gestore della scalabilità automatica dei cluster all'interno di un perimetro in cui sono abilitati servizi accessibili potrebbe non funzionare.

Sconsigliamo l'utilizzo di servizi accessibili. Quando utilizzi un IP virtuale (VIP) limitato, crea un'eccezione per autoscaling.googleapis.com in modo che vada al VIP privato in un perimetro che contiene un cluster con scalabilità automatica.

Problemi di BigQuery

Questa sezione elenca i problemi che potresti riscontrare durante l'utilizzo delle risorse BigQuery che si trovano all'interno di un perimetro dei Controlli di servizio VPC.

Le limitazioni del perimetro dei Controlli di servizio VPC non si applicano all'esportazione dei risultati delle query BigQuery

Se stai tentando di limitare l'esportazione di dati protetti da BigQuery a Google Drive, Fogli Google o Looker Studio, potresti notare alcune differenze rispetto al comportamento previsto. Quando esegui una query dall'interfaccia utente BigQuery, i risultati vengono archiviati nella memoria locale della macchina, ad esempio nella cache del browser. Ciò significa che i risultati saranno posizionati al di fuori dei Controlli di servizio VPC, perciò potresti salvarli in un file CSV o su Google Drive.

In questo scenario, i Controlli di servizio VPC funzionano come previsto, poiché il risultato viene esportato dalla macchina locale che si trova al di fuori del perimetro di servizio, ma la limitazione complessiva dei dati BigQuery verrebbe aggirata.

Per risolvere il problema, limita le autorizzazioni IAM per gli utenti rimuovendo l'autorizzazione bigquery.tables.export. Tieni presente che questa operazione disattiva tutte le opzioni di esportazione.

Problemi di GKE Enterprise

Questa sezione elenca i problemi che potresti riscontrare durante l'utilizzo delle risorse GKE Enterprise che si trovano all'interno di un perimetro dei Controlli di servizio VPC.

Per risolvere gli errori relativi all'utilizzo dei Controlli di servizio VPC con Cloud Service Mesh, scopri come risolvere i problemi dei Controlli di servizio VPC per Cloud Service Mesh gestito.

La configurazione di Config Controller di GKE Enterprise genera una violazione in uscita

È previsto che la configurazione di Config Controller di GKE Enterprise non riesca se non esiste una configurazione in uscita che consenta di raggiungere containerregistry.googleapis.com con il metodo google.containers.registry.read in un progetto al di fuori del perimetro.

Per risolvere questo errore, crea la seguente regola in uscita:

From:
  Identities:ANY_IDENTITY
To:
  Projects =
    NNNNNNNNNNNN
  Service =
  Service name: containerregistry.googleapis.com
  Service methods:
    containers.registry.read

La violazione in uscita scompare dopo che hai aggiunto la regola al perimetro violato.

Problemi di Container Registry

Questa sezione elenca i problemi che potresti riscontrare durante l'utilizzo delle risorse Container Registry che si trovano all'interno di un perimetro dei Controlli di servizio VPC.

Le richieste API Container Registry vengono bloccate dai Controlli di servizio VPC nonostante siano consentite in una regola in entrata o in uscita

Se hai consentito l'accesso a Container Registry utilizzando regole in entrata impostando il campo identity_type su ANY_USER_ACCOUNT o ANY_SERVICE_ACCOUNT, l'accesso viene bloccato dai Controlli di servizio VPC.

Per risolvere il problema, aggiorna il campo identity_type impostandolo su ANY_IDENTITY nella regola in entrata o in uscita.

Errori in uscita da un service agent durante la copia dell'immagine Docker di proprietà di Artifact Registry in un progetto all'interno di un perimetro

Se tenti di copiare un'immagine di proprietà di Artifact Registry nel tuo progetto all'interno di un perimetro dei Controlli di servizio VPC, potresti riscontrare errori in uscita nei log del service agent cloud-cicd-artifact-registry-copier@system.gserviceaccount.com. Questo errore in uscita si verifica in genere quando la policy del perimetro è in modalità dry run.

Puoi risolvere il problema creando una regola in uscita che consenta al service agent cloud-cicd-artifact-registry-copier@system.gserviceaccount.com di accedere al servizio storage.googleapis.com nel progetto menzionato nei log degli errori dei Controlli di servizio VPC.

Problemi di Vertex AI

Questa sezione elenca i problemi che potresti riscontrare durante l'utilizzo delle risorse Vertex AI che si trovano all'interno di un perimetro dei Controlli di servizio VPC.

Le richieste API Notebooks gestite dagli utenti vengono bloccate dai Controlli di servizio VPC nonostante siano consentite in una regola in entrata o in uscita

Se hai consentito l'accesso all'API Notebooks gestita dall'utente utilizzando una policy in entrata e hai impostato identity_type su ANY_USER_ACCOUNT o ANY_SERVICE_ACCOUNT, i Controlli di servizio VPC bloccano l'accesso all'API.

Per risolvere il problema, aggiorna il campo identity_type impostandolo su ANY_IDENTITY nella regola in entrata o in uscita.

Problemi di Spanner

Il backup del database Spanner viene bloccato dalla violazione NO_MATCHING_ACCESS_LEVEL del service account per prodotto e per progetto (P4SA) service-PROJECT_NUMBER@gcf-admin-robot.iam.gserviceaccount.com.

Per risolvere il problema, aggiungi una regola in entrata con il service agent indicato in precedenza o aggiungila a un livello di accesso.

Problemi di AlloyDB per PostgreSQL

Se il cluster AlloyDB per PostgreSQL è protetto da una chiave CMEK, potresti riscontrare errori in entrata nei log dei service agent service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com e service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com.

Per risolvere il problema, aggiungi una regola in entrata che permetta ai service agent di accedere al servizio cloudkms.googleapis.com nel progetto indicato nei log degli errori dei Controlli di servizio VPC.

Passaggi successivi