Questa pagina è stata tradotta dall'API Cloud Translation.

Utilizzo di Controlli di servizio VPC con Apigee e Apigee hybrid

Questa pagina si applica ad Apigee e Apigee hybrid.

Visualizza la documentazione di Apigee Edge.

Apigee si integra con i Controlli di servizio VPC, che ti consentono di isolare le risorse dei tuoi progetti Google Cloud. In questo modo si evita la fuga/l'esfiltrazione di dati.

Questa sezione descrive come utilizzare Controlli di servizio VPC con Apigee.

Panoramica

I Controlli di servizio VPC definiscono un perimetro di servizio che funge da confine tra un progetto e altri servizi. I perimetri di servizio sono un metodo a livello di organizzazione per proteggere i servizi Google Cloud nei tuoi progetti al fine di mitigare il rischio di esfiltrazione di dati.

I controlli di servizio VPC possono anche garantire che i client all'interno di un perimetro che hanno accesso privato alle risorse non abbiano accesso a risorse non autorizzate al di fuori del perimetro.

Per un'analisi dettagliata dei vantaggi dei perimetri di servizio, consulta la panoramica dei Controlli di servizio VPC.

Quando utilizzi Controlli di servizio VPC, tieni presente che:

Sia il progetto Google Cloud sia il runtime associato sono inclusi nel perimetro dei Controlli di servizio VPC del progetto.
L'interazione tra i servizi all'interno di un perimetro può essere limitata utilizzando la funzionalità Servizi accessibili alla rete VPC.

Sia Apigee che Apigee ibrido si integrano con i Controlli di servizio VPC. Per un elenco completo dei prodotti che si integrano con i Controlli di servizio VPC, consulta Prodotti supportati.

Impatto sulla connettività a internet

Quando i Controlli di servizio VPC sono abilitati, l'accesso a internet è disabilitato: il runtime Apigee non comunicherà più con alcuna destinazione internet pubblica. Devi instradare il traffico al tuo VPC stabilendo route personalizzate. Consulta Importazione ed esportazione di route personalizzate.

Configurazione dei Controlli di servizio VPC con Apigee

La procedura generale per configurare i Controlli di servizio VPC con Apigee è la seguente:

Attiva i Controlli di servizio VPC.
Crea un nuovo perimetro di servizio.
Configura il perimetro di servizio.

Questi passaggi sono descritti in dettaglio di seguito.

Per configurare i Controlli di servizio VPC con Apigee:

Abilita Controlli di servizio VPC per la connessione in peering dalla tua rete ad Apigee eseguendo il comando seguente:
```
gcloud services vpc-peerings enable-vpc-service-controls \
  --network=SHARED_VPC_NETWORK --project=PROJECT_ID
```
Dove:
- SHARED_VPC_NETWORK è il nome della rete VPC condivisa.
- PROJECT_ID è il nome del progetto che ospita la rete VPC condivisa; non è il progetto utilizzato per creare l'organizzazione Apigee.
Questo comando abilita i Controlli di servizio VPC per il tuo progetto. Puoi eseguire questo comando più volte per attivare i Controlli di servizio VPC per più di un progetto.
Crea un nuovo perimetro come descritto nella guida rapida ai Controlli di servizio VPC. Quando crei un perimetro, scegli i progetti da aggiungere al suo interno e i servizi da proteggere.

Per Apigee e Apigee Hybrid, Google consiglia di proteggere tutti i servizi quando crei un perimetro, inclusa l'API Apigee.

Per maggiori informazioni, vedi Creazione di un perimetro di servizio.
Configura il perimetro di servizio, come descritto in Dettagli e configurazione del perimetro di servizio.

Per aggiungere un portale integrato all'interno del perimetro, vedi Aggiungere un portale integrato al perimetro.

Configurazione dei Controlli di servizio VPC con Apigee Hybrid

Apigee Hybrid supporta Controlli di servizio VPC, ma devi eseguire passaggi aggiuntivi. La procedura generale per integrare Apigee ibrido con i Controlli di servizio VPC è la seguente:

Configura la connettività privata.
Proteggi altri servizi all'interno del perimetro.
Configura un repository privato. Un repository privato è un repository che si trova all'interno del perimetro; non deve necessariamente essere un repository locale, purché si trovi all'interno del perimetro.
Esegui il push delle immagini Apigee nel tuo repository privato.
Aggiorna gli override per utilizzare il repository privato durante il processo di installazione e configurazione ibrida.

Ciascuno di questi passaggi è descritto in modo più dettagliato nella procedura seguente.

Per configurare i Controlli di servizio VPC con Apigee hybrid:

Configura indirizzi IP privati per gli host della tua rete ibrida, come descritto in Configurazione della connettività privata alle API e ai servizi Google. Ciò comporta la configurazione di route, regole firewall e voci DNS per consentire alle API di Google di accedere a questi IP privati.
Segui i passaggi descritti in Configurazione dei Controlli di servizio VPC con Apigee.

Durante questa procedura, devi assicurarti di proteggere i seguenti servizi, oltre a quelli specificati per Apigee, all'interno del perimetro:
- Anthos Service Mesh
- Cloud Monitoring (Stackdriver)
- Google Kubernetes Engine (se esegui l'applicazione su GKE)
- Google Container Registry (se lo utilizzi come repository locale)
Per aggiungere questi servizi al perimetro, segui le istruzioni riportate in Dettagli e configurazione del perimetro di servizio.

Copia le immagini Apigee nel tuo repository privato:

Scarica le immagini Apigee firmate da Docker Hub come descritto qui. Assicurati di specificare i numeri di versione più recenti.

Ad esempio:

docker pull google/apigee-installer:1.3.3
docker pull google/apigee-authn-authz:1.3.3
docker pull google/apigee-mart-server:1.3.3
docker pull google/apigee-synchronizer:1.3.3
docker pull google/apigee-runtime:1.3.3
docker pull google/apigee-hybrid-cassandra-client:1.3.3
docker pull google/apigee-hybrid-cassandra:1.3.3
docker pull google/apigee-cassandra-backup-utility:1.3.3
docker pull google/apigee-udca:1.3.3
docker pull google/apigee-stackdriver-logging-agent:1.6.8
docker pull google/apigee-prom-prometheus:v2.9.2
docker pull google/apigee-stackdriver-prometheus-sidecar:0.7.5
docker pull google/apigee-connect-agent:1.3.3
docker pull google/apigee-watcher:1.3.3
docker pull google/apigee-operators:1.3.3
docker pull google/apigee-kube-rbac-proxy:v0.4.1

Tagga le immagini.

Il seguente esempio tagga le immagini in un repository GCR con sede negli Stati Uniti:

docker tag google/apigee-installer:1.3.3 us.gcr.io/project_ID/apigee-installer:1.3.3
docker tag google/apigee-authn-authz:1.3.3 us.gcr.io/project_ID/apigee-authn-authz:1.3.3
docker tag google/apigee-mart-server:1.3.3 us.gcr.io/project_ID/apigee-mart-server:1.3.3
docker tag google/apigee-synchronizer:1.3.3 us.gcr.io/project_ID/apigee-synchronizer:1.3.3
docker tag google/apigee-runtime:1.3.3 us.gcr.io/project_ID/apigee-runtime:1.3.3
docker tag google/apigee-hybrid-cassandra-client:1.3.3 us.gcr.io/project_ID/apigee-hybrid-cassandra-client:1.3.3
docker tag google/apigee-hybrid-cassandra:1.3.3 us.gcr.io/project_ID/apigee-hybrid-cassandra:1.3.3
docker tag google/apigee-cassandra-backup-utility:1.3.3 us.gcr.io/project_ID/apigee-cassandra-backup-utility:1.3.3
docker tag google/apigee-udca:1.3.3 us.gcr.io/project_ID/apigee-udca:1.3.3
docker tag google/apigee-stackdriver-logging-agent:1.6.8 us.gcr.io/project_ID/apigee-stackdriver-logging-agent:1.6.8
docker tag google/apigee-prom-prometheus:v2.9.2 us.gcr.io/project_ID/apigee-prom-prometheus:v2.9.2
docker tag google/apigee-stackdriver-prometheus-sidecar:0.7.5 us.gcr.io/project_ID/apigee-stackdriver-prometheus-sidecar:0.7.5
docker tag google/apigee-connect-agent:1.3.3 us.gcr.io/project_ID/apigee-connect-agent:1.3.3
docker tag google/apigee-watcher:1.3.3 us.gcr.io/project_ID/apigee-watcher:1.3.3
docker tag google/apigee-operators:1.3.3 us.gcr.io/project_ID/apigee-operators:1.3.3
docker tag google/apigee-kube-rbac-proxy:v0.4.1 us.gcr.io/project_ID/apigee-kube-rbac-proxy:v0.4.1

Sebbene non sia obbligatorio, Google consiglia di includere l'ID progetto o un altro valore identificativo nel percorso del repository per ogni immagine.

Esegui il push delle immagini nel tuo repository privato.

L'esempio seguente esegue il push delle immagini in un repository GCR con sede negli Stati Uniti:

docker push us.gcr.io/project_ID/apigee-installer:1.3.3
docker push us.gcr.io/project_ID/apigee-authn-authz:1.3.3
docker push us.gcr.io/project_ID/apigee-mart-server:1.3.3
docker push us.gcr.io/project_ID/apigee-synchronizer:1.3.3
docker push us.gcr.io/project_ID/apigee-runtime:1.3.3
docker push us.gcr.io/project_ID/apigee-hybrid-cassandra-client:1.3.3
docker push us.gcr.io/project_ID/apigee-hybrid-cassandra:1.3.3
docker push us.gcr.io/project_ID/apigee-cassandra-backup-utility:1.3.3
docker push us.gcr.io/project_ID/apigee-cassandra-backup-utility:1.3.3
docker push us.gcr.io/project_ID/apigee-udca:1.3.3
docker push us.gcr.io/project_ID/apigee-stackdriver-logging-agent:1.6.8
docker push us.gcr.io/project_ID/apigee-prom-prometheus:v2.9.2
docker push us.gcr.io/project_ID/apigee-stackdriver-prometheus-sidecar:0.7.5
docker push us.gcr.io/project_ID/apigee-connect-agent1.3.3
docker push us.gcr.io/project_ID/apigee-watcher1.3.3
docker push us.gcr.io/project_ID/apigee-operators1.3.3
docker push us.gcr.io/project_ID/apigee-kube-rbac-proxy:v0.4.1

Sebbene non sia obbligatorio, Google consiglia di includere l'ID progetto o un altro valore identificativo nel percorso del repository per ogni immagine.

Aggiorna il file di override in modo che gli URL delle immagini puntino al tuo repository privato, come descritto in Specifica gli override di configurazione.

Devi modificare gli URL delle immagini per i seguenti componenti:

Nome componente (nel file di override)	URL immagine
`ao`	`your_private_repo/apigee-operators`
`authz`	`your_private_repo/apigee-authn-authz`
`cassandra`	`your_private_repo/apigee-hybrid-cassandra auth: your_private_repo/apigee-hybrid-cassandra-client backup: your_private_repo/apigee-cassandra-backup-utility restore: your_private_repo/apigee-cassandra-backup-utility`
`connectAgent`	`your_private_repo/apigee-connect-agent`
`installer`	`your_private_repo/apigee-installer`
`kubeRBACProxy`	`your_private_repo/apigee-kube-rbac-proxy`
`logger`	`your_private_repo/apigee-stackdriver-logging-agent`
`mart`	`your_private_repo/apigee-mart-server`
`metrics`	`your_private_repo/apigee-prom-prometheus sdSidecar: your_private_repo/apigee-stackdriver-prometheus-sidecar`
`runtime`	`your_private_repo/apigee-runtime`
`synchronizer`	`your_private_repo/apigee-synchronizer`
`udca`	`your_private_repo/apigee-udca fluentd: your_private_repo/apigee-stackdriver-logging-agent`
`watcher`	`your_private_repo/apigee-watcher`

Applica le modifiche utilizzando le nuove immagini in GCR, come descritto in Applica la configurazione al cluster.

Concessione dell'accesso ai perimetri ai portali integrati

VPC-SC supporta la concessione di livelli di accesso VPC-SC ai portali integrati, ma questo processo richiede passaggi aggiuntivi, come descritto in questa sezione.

Se non concedi un livello di accesso ai portali integrati, questi non sono disponibili per le organizzazioni Apigee abilitate per VPC-SC.

Concessione di un livello di accesso ai portali:

Non inserisce i portali integrati all'interno del perimetro.
Consente di accedere ai portali integrati dall'esterno del perimetro.
Consente l'esposizione dei dati Apigee protetti da Controlli di servizio VPC (come i dati delle applicazioni) agli utenti del portale al di fuori del perimetro Controlli di servizio VPC.

Per ulteriori informazioni, vedi Consentire l'accesso a risorse protette dall'esterno di un perimetro.

Prerequisiti

Prima di concedere l'accesso al perimetro a un portale integrato, devi attivare l'API Access Context Manager API per il tuo progetto, se non è già attiva. Puoi farlo nella console Cloud o utilizzando il comando gcloud services enable.

Per verificare se l'API è abilitata, esamina l'output del comando gcloud services list, come descritto nel passaggio 2: attiva le API Apigee.

Inoltre, devi disporre dell'indirizzo email del account di servizio per il progetto in cui viene utilizzato il portale. Per ottenerlo, devi disporre dell'ID progetto Google Cloud e del numero di progetto. I passaggi seguenti descrivono come ottenere questi valori:

Recupera i dettagli del progetto GCP utilizzando il comando gcloud projects list, come mostrato nell'esempio seguente:
```
gcloud projects list
```
Questo comando restituisce l'ID progetto (nella colonna PROJECT_ID) e il numero di progetto (nella colonna PROJECT_NUMBER) per ogni progetto della tua organizzazione GCP.
Identifica l'indirizzo email del account di servizio Apigee. Si tratta dello stesso account creato dal programma di installazione di Apigee quando hai eseguito il provisioning della tua organizzazione nel Passaggio 3: crea un'organizzazione.

Nota terminologica:i termini service account e service agent sono usati in modo intercambiabile.

Per ottenere questo indirizzo email, utilizza il comando iam service-accounts list, che utilizza la seguente sintassi:
```
gcloud iam service-accounts list --project GCP_PROJECT_ID
```
Ad esempio:
```
gcloud iam service-accounts list --project my-project

DISPLAY NAME                              EMAIL                                                DISABLED
Apigee default service account            service-8675309@gcp-sa-apigee.iam.gserviceaccount.com  False
Compute Engine default service account     8675309-compute@developer.gserviceaccount.com          False
```
L'account di servizio che ti interessa è quello il cui indirizzo email corrisponde al seguente formato:
service-GCP_PROJECT_NUMBER@gcp-sa-apigee.iam.gserviceaccount.com
Ad esempio:
service-8675309@gcp-sa-apigee.iam.gserviceaccount.com
Ottieni l'ID della policy (o del perimetro) utilizzando il comando access-context-manager policies list. Trasmetti l'ID organizzazione a questo comando, come mostrato nell'esempio seguente:
```
gcloud access-context-manager policies list --organization=organizations/GCP_ORG_ID
```
gcloud risponde con un elenco di criteri associati all'organizzazione specificata, ad esempio:
```
gcloud access-context-manager policies list --organization=organizations/2244340

NAME          ORGANIZATION      TITLE                 ETAG
04081981      2244340           Default policy        421924c5a97c0Icu8
```
Nota sulla terminologia: il termine norme in questo contesto è sinonimo di perimetro.

L'ID norma (noto anche come ID perimetro) di VPC-SC è l'ID del perimetro di servizio VPC-SC che funge da confine tra il tuo progetto e altri servizi. È il valore nella colonna NAME.

Passaggi per concedere l'accesso al perimetro ai portali integrati

Per concedere l'accesso perimetrale a un portale integrato:

Raccogli l'indirizzo email del account di servizio e l'ID criterio di VPC-SC, come descritto in Prerequisiti.
Crea un file di condizioni sulla macchina amministratore che specifichi l'indirizzo del account di servizio che concederà l'accesso al portale tramite il perimetro.

Il file può avere il nome che preferisci, ma deve avere l'estensione *.yaml. Ad esempio: my-portal-access-rules.yaml.
Nel file delle condizioni, aggiungi una sezione members che specifica il service account Apigee, come mostrato nell'esempio seguente:
```
- members:
  - serviceAccount:service-8675309@gcp-sa-apigee.iam.gserviceaccount.com
```
Tieni presente che è sufficiente aggiungere una sezione members; non è necessario aggiungere una sezione per il livello di accesso. Per ulteriori informazioni sulla creazione di un file di condizioni, vedi Limitare l'accesso per utente o service account.
Crea un livello di accesso con il comando access-context-manager levels create; ad esempio:
```
gcloud access-context-manager levels create ACCESS_LEVEL_ID \
  --title ACCESS_LEVEL_TITLE \
  --basic-level-spec PATH/TO/CONDITIONS_FILE.yaml \
  --policy=POLICY_ID
```
Dove:
- ACCESS_LEVEL_ID è un identificatore per il nuovo livello di accesso che viene concesso, ad esempio my-portal-access-level.
- ACCESS_LEVEL_TITLE è un titolo per il livello di accesso. Il titolo può essere qualsiasi, ma Google consiglia di assegnare un valore significativo in modo che tu e gli altri amministratori sappiate a cosa si applica. Ad esempio, My Portal Access Level.
- CONDITIONS_FILE è il percorso del file YAML che hai creato nel passaggio precedente.
- POLICY_ID è l'ID criterio o perimetro.
Ad esempio:
```
gcloud access-context-manager levels create my-portal-access-level \
  --title My Portal Access Level \
  --basic-level-spec ~/my-portal-access-rules.yaml \
  --policy=04081981
```

Aggiorna il perimetro con il nuovo livello di accesso utilizzando il comando access-context-manager perimeters update:

gcloud access-context-manager perimeters update POLICY_ID \
  --add-access-levels=ACCESS_LEVEL_ID \
  --policy=POLICY_ID