Questa pagina è stata tradotta dall'API Cloud Translation.

Risolvere i problemi comuni di Controlli di servizio VPC con i servizi Google Cloud

Questa pagina fornisce soluzioni ai problemi che potresti riscontrare durante l'utilizzo di un servizio Google Cloud 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 presenta alcune limitazioni note. Per ulteriori informazioni, consulta Limitazioni dell'utilizzo di Controlli di servizio VPC con Cloud Build.

Accesso all'account di servizio Cloud Build bloccato per le risorse protette

Cloud Build utilizza l'account di servizio Cloud Build per eseguire le build per tuo conto. Per impostazione predefinita, quando esegui una build su Cloud Build, la build viene eseguita in un progetto tenant esterno al tuo progetto.

Le VM worker di Cloud Build che generano gli output di compilazione non rientrano nel perimetro di Controlli di servizio VPC, anche se il progetto è al suo interno. Pertanto, affinché le build possano accedere alle risorse all'interno del perimetro, devi concedere all'account di servizio Cloud Build l'accesso al perimetro di Controlli di servizio VPC aggiungendolo al livello di accesso o alla regola di ingresso.

Per ulteriori informazioni, consulta Concedere all'account di servizio Cloud Build l'accesso al Controlli di servizio VPC Controls.

Problemi di Cloud Storage

Rifiuti 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 del rifiuto di 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 un target con projects/0/buckets, viene sempre attivato un rifiuto perché projects/0 non esiste ed è considerato al di fuori del perimetro di servizio.

Rifiuti di 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 i progetti della relativa organizzazione principale. Esistono determinate limitazioni quando vuoi accedere ai bucket Cloud Storage da progetti all'interno di un perimetro Controlli di servizio VPC che si trova in un'altra organizzazione.

Un esempio tipico è quando vuoi accedere ai bucket Cloud Storage di proprietà di Google. Poiché il tuo progetto e il progetto di proprietà di Google contenente il bucket di destinazione non si trovano nello stesso perimetro, 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 di ingresso e uscita.

Accesso a un bucket Cloud Storage accessibile pubblicamente da un perimetro

Se stai tentando di accedere a un bucket Cloud Storage accessibile pubblicamente da un perimetro di servizio, Controlli di servizio VPC potrebbe bloccare le tue richieste generando una violazione di uscita.

Per garantire un accesso coerente e corretto all'oggetto in base alle esigenze, dobbiamo 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 all'interno di un perimetro di Controlli di servizio VPC.

Impossibile inviare notifiche da Security Command Center a Pub/Sub

Il tentativo di pubblicare notifiche di Security Command Center in un argomento Pub/Sub all'interno di un perimetro di Controlli di servizio VPC non va a buon fine con una violazione RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER.

Ti consigliamo di attivare Security Command Center a livello di organizzazione. Controlli di servizio VPC non considera un'organizzazione principale come parte del perimetro dei suoi progetti secondari. Affinché questa operazione funzioni, devi concedere l'accesso al perimetro a Security Command Center.

Come soluzione alternativa, puoi procedere nel seguente modo:

Utilizzare 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 fino al completamento della configurazione della notifica.

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

Impedimento della scansione delle risorse Compute Engine all'interno di un perimetro da parte di Security Command Center

Security Command Center analizza le risorse Compute Engine nei tuoi progetti utilizzando l'account di servizio 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, il P4SA deve essere aggiunto al livello di accesso o alla regola di ingresso. In caso contrario, potresti visualizzare un errore NO_MATCHING_ACCESS_LEVEL.

Security Command Center non è stato in grado di eseguire la scansione delle risorse all'interno di un perimetro di servizio

Security Health Analytics esegue la scansione delle risorse nei tuoi progetti utilizzando l'account di servizio 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, l'account P4SA deve essere aggiunto al livello di accesso o alla regola di ingresso. In caso contrario, visualizzerai l'errore NO_MATCHING_ACCESS_LEVEL.

Problemi di Google Kubernetes Engine

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

Il gestore della scalabilità automatica non funziona nei perimetri con servizi accessibili e servizi con limitazioni abilitati

autoscaling.googleapis.com non è integrato con i Controlli di servizio VPC, pertanto non può essere aggiunto ai servizi con limitazioni né ai servizi accessibili. Non è possibile consentire l'APIautoscaling.googleapis.com nei servizi accessibili. Di conseguenza, il gestore della scalabilità automatica dei cluster esistenti in un perimetro con servizi accessibili abilitati potrebbe non funzionare.

Ti sconsigliamo di utilizzare servizi accessibili. Quando utilizzi un IP virtuale (VIP) soggetto a restrizioni, fai un'eccezione per autoscaling.googleapis.com per passare a un VIP privato in un perimetro che contiene un cluster con la scalabilità automatica.

Problemi con BigQuery

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

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

Se stai tentando di limitare l'esportazione di dati protetti da BigQuery a Google Drive, Fogli Google o Looker Studio, potresti notare alcune deviazioni dal comportamento previsto. Quando esegui una query dall'UI di BigQuery, i risultati vengono archiviati nella memoria locale della tua macchina, ad esempio nella cache del browser. Ciò significa che i risultati ora non sono più inclusi in Controlli di servizio VPC, quindi puoi eventualmente salvarli in un file CSV o su Google Drive.

In questo scenario, Controlli di servizio VPC funziona 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 viene 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 relativi a GKE Enterprise

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

Per risolvere i problemi relativi all'utilizzo di Controlli di servizio VPC con Cloud Service Mesh, consulta Risolvere i problemi di Controlli di servizio VPC per Cloud Service Mesh gestito.

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

È previsto che la procedura di configurazione di Config Controller di GKE Enterprise non vada a buon fine se non è presente una configurazione di uscita che consenta di raggiungerecontainerregistry.googleapis.com con il metodogoogle.containers.registry.read in un progetto esterno al perimetro.

Per risolvere questo errore, crea la seguente regola di 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 aver aggiunto la regola al perimetro violato.

Problemi di Container Registry

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

Richieste dell'API Container Registry bloccate da Controlli di servizio VPC nonostante siano consentite in una regola di traffico in entrata o in uscita

Se hai consentito l'accesso a Container Registry utilizzando regole di ingresso con il campo identity_type impostato su ANY_USER_ACCOUNT o ANY_SERVICE_ACCOUNT, l'accesso viene bloccato da Controlli di servizio VPC.

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

Errori di esportazione da un agente di servizio durante la copia dell'immagine Docker di proprietà di Artifact Registry in un progetto in un perimetro

Quando provi a copiare un'immagine di proprietà di Artifact Registry nel tuo progetto che si trova all'interno di un perimetro di Controlli di servizio VPC, potresti riscontrare errori di uscita nei log dell'agente di serviziocloud-cicd-artifact-registry-copier@system.gserviceaccount.com. Questo errore di uscita si verifica in genere quando il criterio del perimetro è in modalità di prova.

Puoi risolvere il problema creando una regola di uscita che consenta all'agente di servizio cloud-cicd-artifact-registry-copier@system.gserviceaccount.com di accedere al servizio storage.googleapis.com nel progetto indicato nei log di errore di Controlli di servizio VPC.

Problemi di Vertex AI

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

Richieste dell'API Notebooks gestite dall'utente bloccate da Controlli di servizio VPC nonostante siano consentite in una regola di traffico in entrata o in uscita

Se hai consentito l'accesso all'API Notebooks gestiti dall'utente utilizzando un policy di ingresso e hai impostato identity_type su ANY_USER_ACCOUNT o ANY_SERVICE_ACCOUNT, Controlli di servizio VPC blocca l'accesso all'API.