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 progetti Google Cloud. Ciò aiuta a prevenire fughe/esfiltrazioni di dati.
Questa sezione descrive come utilizzare i 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 progetti al fine di mitigare il rischio di esfiltrazione di dati.
I Controlli di servizio VPC possono inoltre garantire che i client all'interno di un perimetro con 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 che 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 in rete VPC.
Apigee e Apigee hybrid 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 viene disabilitato: il runtime Apigee non comunicherà più con alcuna destinazione internet pubblica. Devi instradare il traffico al tuo VPC stabilendo route personalizzate. Vedi Importazione ed esportazione di route personalizzate.
Configurazione dei Controlli di servizio VPC con Apigee
La procedura generale per la configurazione dei Controlli di servizio VPC con Apigee è la seguente:
- Abilitare i Controlli di servizio VPC.
- Crea un nuovo perimetro di servizio.
- Configura 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 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 abilitare 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 all'interno del perimetro 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, consulta la pagina sulla 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 Aggiunta di un portale integrato al perimetro.
Configurazione dei Controlli di servizio VPC con Apigee hybrid
Apigee hybrid supporta i Controlli di servizio VPC, ma devi eseguire alcuni passaggi aggiuntivi. La procedura generale per integrare Apigee hybrid con i Controlli di servizio VPC è la seguente:
- Configura la connettività privata.
- Proteggi i servizi aggiuntivi all'interno del perimetro.
- Configura un repository privato. Un repository privato è un repository privato all'interno del perimetro. Non è necessario che sia un repository locale.
- 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 maggiore dettaglio nella procedura seguente.
Per configurare i Controlli di servizio VPC con Apigee hybrid:
- Configura gli indirizzi IP privati per gli host di rete ibridi, come descritto in Configurare la 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 la procedura descritta in Configurare i Controlli di servizio VPC con Apigee.
Durante questo processo, devi assicurarti di proteggere i seguenti servizi oltre a quelli specificati 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 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.
Nell'esempio seguente le immagini vengono taggate 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
Anche se non è obbligatorio, Google consiglia di includere l'ID progetto o 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 a 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
Anche se non è obbligatorio, Google consiglia di includere l'ID progetto o altro valore identificativo nel percorso del repository per ogni immagine.
-
-
Aggiorna il file di override in modo che gli URL immagine indirizzino al repository privato, come descritto in Specificare gli override di 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-utilityconnectAgent
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-sidecarruntime
your_private_repo/apigee-runtime
synchronizer
your_private_repo/apigee-synchronizer
udca
your_private_repo/apigee-udca
fluentd: your_private_repo/apigee-stackdriver-logging-agentwatcher
your_private_repo/apigee-watcher
- Applica le modifiche utilizzando le nuove immagini in GCR, come descritto in Applicare la configurazione al cluster.
Concessione dell'accesso al perimetro da parte dei portali integrati
VPC-SC supporta la concessione dei 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 consente di posizionare i portali integrati all'interno del perimetro.
- Consente l'accesso ai portali integrati dall'esterno del perimetro.
- Consente l'esposizione dei dati Apigee protetti da VPC-SC (come i dati delle applicazioni) agli utenti del portale al di fuori del perimetro VPC-SC.
Per maggiori informazioni, consulta 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 è già
abilitato. Puoi farlo nella console Cloud o utilizzando il comando gcloud services allow.
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 in cui viene utilizzato il portale. Per ottenerlo, sono necessari l'ID e il numero del progetto Google Cloud. I passaggi seguenti spiegano come ottenere questi valori:
- Ottieni i dettagli del progetto Google Cloud utilizzando il comando gcloud projects list, come illustrato nell'esempio seguente:
gcloud projects list
Questo comando restituisce l'ID progetto (nella colonna
PROJECT_ID
) e il numero del progetto (nella colonnaPROJECT_NUMBER
) per ogni progetto nell'organizzazione Google Cloud. -
Identifica l'indirizzo email dell'account di servizio Apigee. Si tratta dello stesso account creato dal programma di installazione Apigee quando hai eseguito il provisioning dell'organizzazione nel Passaggio 3: crea un'organizzazione.
Per ottenere questo indirizzo email, usa il comando
iam service-accounts list
, che ha 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 account8675309
-compute@developer.gserviceaccount.com FalseL'account di servizio desiderato è 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
. Passa 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 ETAG04081981
2244340
Default policy
421924c5a97c0Icu8L'ID criterio di VPC-SC (noto anche come ID perimetro) è l'ID del perimetro di servizio VPC-SC che funge da confine tra il 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:
- Recupera l'indirizzo email dell'account di servizio e l'ID criterio di VPC-SC, come descritto nella sezione Prerequisiti.
-
Crea un file delle condizioni sulla macchina di amministrazione che specifichi l'indirizzo dell'account di servizio che concederà l'accesso al portale attraverso il perimetro.
Il file può essere qualsiasi nome tu voglia, ma deve avere l'estensione
*.yaml
. Ad esempio,my-portal-access-rules.yaml
. -
Nel file delle condizioni, aggiungi una sezione
members
che specifichi l'account di servizio Apigee, come mostrato nell'esempio seguente:- members: - serviceAccount:
service-
8675309
@gcp-sa-apigee.iam.gserviceaccount.comTieni presente che è sufficiente aggiungere una sezione
members
; non è necessario aggiungere una sezione per il livello di accesso. Per maggiori informazioni sulla creazione di un file delle condizioni, consulta Limitare l'accesso in base all'utente o all'account 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 che viene concesso, ad esempio
my-portal-access-level
. - ACCESS_LEVEL_TITLE è un titolo per il livello di accesso. Puoi scegliere qualsiasi titolo, ma Google consiglia di assegnargli un valore significativo in modo che tu e gli altri amministratori possiate sapere a cosa si applica. Ad esempio, Livello di accesso al mio portale.
- CONDITIONS_FILE è il percorso del file YAML che hai creato nel passaggio precedente.
- 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
- ACCESS_LEVEL_ID è un identificatore del nuovo livello di accesso che viene concesso, ad esempio
- 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
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 i criteri. - Assicurati di utilizzare l'ID organizzazione GCP e non l'ID organizzazione Apigee quando ricevi dettagli sull'organizzazione.
- Alcuni comandi descritti in questa sezione richiedono autorizzazioni elevate; ad esempio, per ottenere dettagli sugli account di servizio di un progetto, devi essere un proprietario del progetto.
-
Per verificare che l'account di servizio esista, esegui il comando
iam service-accounts describe
, come illustrato nell'esempio seguente:gcloud iam service-accounts describe
service-
8675309
@gcp-sa-apigee.iam.gserviceaccount.comgcloud
risponde fornendo informazioni sull'account di servizio, inclusi il nome visualizzato e l'ID progetto a cui appartiene. Se l'account di servizio non esiste,gcloud
risponde con un erroreNOT_FOUND
.
Limitazioni
Le integrazioni di Apigee con i Controlli di servizio VPC presentano le seguenti limitazioni:
- La configurazione dei portali integrati richiede passaggi aggiuntivi.
- Devi eseguire il deployment dei portali Drupal all'interno del perimetro di servizio.