Questa pagina è stata tradotta dall'API Cloud Translation.

Utilizzo dei Controlli di servizio VPC con Apigee e Apigee hybrid

Questa pagina si applica a Apigee e Apigee ibridi.

Visualizza documentazione di Apigee Edge.

Apigee si integra con il servizio VPC Controlli, che consentono di isolare le risorse dei progetti Google Cloud. Ciò aiuta a prevenire fughe/esfiltrazioni di dati.

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

Panoramica

Controlli di servizio VPC definisce 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 Google Cloud nei tuoi progetti per ridurre il rischio di esfiltrazione di dati.

I Controlli di servizio VPC possono inoltre garantire che i client all'interno di un perimetro abbiano accesso privato Le risorse non hanno accesso a risorse non autorizzate all'esterno del perimetro.

Per uno sguardo dettagliato sui vantaggi dei perimetri di servizio, Panoramica dei Controlli di servizio VPC.

Quando utilizzi Controlli di servizio VPC, tieni presente che:

Sia il progetto Google Cloud che il runtime associato sono inclusi al perimetro dei Controlli di servizio VPC di quel progetto.
L'interazione tra i servizi all'interno di un perimetro può essere limitata utilizzando Servizi accessibili dalla rete VPC funzionalità.

Sia Apigee che Apigee hybrid si integrano con i Controlli di servizio VPC. Per un l'elenco completo per i prodotti che si integrano con i Controlli di servizio VPC, 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 nessun target internet pubblico. Devi indirizzare il traffico verso in un VPC mediante la definizione di 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:

Abilitare i Controlli di servizio VPC.
Creare un nuovo perimetro di servizio.
Configurare il perimetro di servizio.

Questi passaggi sono descritti più dettagliatamente di seguito.

Per configurare i Controlli di servizio VPC con Apigee:

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

Per Apigee e Apigee hybrid, Google consiglia di proteggere tutti durante la creazione di un perimetro, tra cui l'API Apigee.

Per ulteriori informazioni, vedi Creazione di un servizio perimetrale.
Configurare il perimetro di servizio, come descritto in Dettagli dei perimetri di servizio configurazione.

Per aggiungere un portale integrato all'interno del tuo perimetro, consulta la sezione Aggiunta di un portale integrato dal portale verso il perimetro.

Configurazione dei Controlli di servizio VPC con Apigee hybrid

Apigee hybrid supporta i Controlli di servizio VPC, ma devi seguire alcuni passaggi aggiuntivi eseguire il deployment. Il processo generale per l'integrazione di Apigee hybrid con i Controlli di servizio VPC viene eseguito che segue:

Configura la connettività privata.
Proteggere i servizi aggiuntivi all'interno del perimetro.
Configura un repository privato. (un repository privato è un repository che si trova all'interno perimetro; non è necessario che sia un repository locale, purché si trovi all'interno perimeter.)
Esegui il push delle immagini Apigee nel tuo repository privato.
Aggiorna gli override per utilizzare il repository privato durante l'installazione ibrida e durante il processo di configurazione.

Ciascuno di questi passaggi è descritto più dettagliatamente nella procedura seguente.

Per configurare i Controlli di servizio VPC con Apigee hybrid:

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

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

Copia le immagini Apigee nel tuo repository privato:

Scarica le immagini Apigee firmate da Docker Hub come descritto qui Assicurati di specificare i numeri delle ultime versioni.

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.

Nell'esempio seguente vengono taggate le immagini in un repository GCR basato 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 altro che identifica il valore 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 basato 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 altro che identifica il valore nel percorso del repository per ogni immagine.

Aggiorna il file degli override per indirizzare gli URL immagine al tuo repository privato, come descritto in Specificare override della configurazione

Devi modificare gli URL immagine 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 al perimetro ai portali integrati

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

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

Concessione di un livello di accesso ai portali:

Non inserisce portali integrati all'interno del perimetro.
Consente di accedere ai portali integrati dall'esterno del perimetro.
Consente l'esposizione dei dati Apigee protetti da VPC-SC (ad esempio i dati delle applicazioni) agli utenti del portale all'esterno del perimetro VPC-SC.

Per ulteriori informazioni, consulta la sezione Consentire l'accesso alle risorse protette dall'esterno di un perimetro.

Prerequisiti

Prima di concedere l'accesso perimetrale a un portale integrato, devi abilitare Access Context Manager API per il tuo progetto, se non lo è già in un bucket con il controllo delle versioni attivo. Puoi eseguire questa operazione nella console Cloud o utilizzando il comando gcloud servicesenable.

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

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

Visualizzare i dettagli del progetto Google Cloud utilizzando il comando gcloud projects list, come nell'esempio seguente:
```
gcloud projects list
```
Questo comando restituisce l'ID progetto (nella colonna PROJECT_ID) e numero di progetto (nella colonna PROJECT_NUMBER) di ciascun progetto in Google Cloud dell'organizzazione.
Identifica l'indirizzo email dell'account di servizio Apigee. È lo stesso creato dal programma di installazione Apigee quando hai eseguito il provisioning della tua organizzazione Passaggio 3: crea un'organizzazione.

Nota terminologica: il termine account di servizio e agente di servizio 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 sia 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
Recupera l'ID criterio (o perimetro) utilizzando il comando access-context-manager policies list. Supera il Organization ID (ID organizzazione) a questo comando, come illustrato nell'esempio seguente:
```
gcloud access-context-manager policies list --organization=organizations/GCP_ORG_ID
```
gcloud risponde con un elenco di criteri associati allo organizzazione; Ad esempio:
```
gcloud access-context-manager policies list --organization=organizations/2244340

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

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

Passaggi per concedere l'accesso perimetrale ai portali integrati

Per concedere l'accesso perimetrale a un portale integrato:

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

Il file può essere qualsiasi nome tu voglia, ma deve avere un'estensione *.yaml. Per ad esempio my-portal-access-rules.yaml.
Nel file delle condizioni, aggiungi una sezione members che specifichi il servizio Apigee dell'account di servizio, come illustrato nell'esempio seguente:
```
- members:
  - serviceAccount:service-8675309@gcp-sa-apigee.iam.gserviceaccount.com
```
Tieni presente che è sufficiente aggiungere una sezione members. non c'è bisogno di aggiungere del livello di accesso. Per ulteriori informazioni sulla creazione di un file di condizioni, consulta Limita l'accesso per un account utente o di servizio.
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 del nuovo livello di accesso attualmente in corso concesso; ad esempio my-portal-access-level.
- ACCESS_LEVEL_TITLE è un titolo per il livello di accesso. Il titolo può essere tutto ciò che desideri, ma Google consiglia di assegnargli un valore significativo in modo che tu e gli altri amministratori saprete a cosa si applica. Ad esempio: Livello di accesso al mio portale.
- CONDITIONS_FILE è il percorso del file YAML che hai creato nella precedente passaggio.
- POLICY_ID è l'ID del criterio o del 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 access-context-manager perimeters update :

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

Ad esempio:

gcloud access-context-manager perimeters update 04081981 \
  --add-access-levels=my-portal-access-level \
  --policy=04081981

Risoluzione dei problemi

Verifica quanto segue:

Se l'API Access Context Manager non è abilitata per il tuo progetto Google Cloud, gcloud ti chiede di abilitarla quando provi a elencare o impostare criteri.
Assicurati di utilizzare l'ID organizzazione GCP e non Apigee. Organization ID (ID organizzazione) quando ricevi i dettagli sull'organizzazione.
Alcuni comandi descritti in questa sezione richiedono autorizzazioni elevate. Ad esempio, per ottenere sugli account di servizio per un progetto, devi essere un proprietario del progetto.
Per verificare che l'account di servizio esista, esegui iam service-accounts describe , come illustrato nell'esempio seguente:
```
gcloud iam service-accounts describe service-8675309@gcp-sa-apigee.iam.gserviceaccount.com
```
gcloud risponde fornendo informazioni sull'account di servizio, incluse le informazioni sul il nome visualizzato e l'ID progetto a cui appartiene. Se l'account di servizio non esiste, gcloud risponde con un errore NOT_FOUND.

Limitazioni

Le integrazioni Apigee con Controlli di servizio VPC hanno le seguenti limitazioni:

La configurazione dei portali integrati richiede passaggi aggiuntivi.
Devi eseguire il deployment dei portali Drupal all'interno del perimetro di servizio.