Utilizzo di Controlli di servizio VPC con Apigee e Apigee hybrid

Stai visualizzando la documentazione di Apigee X.
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 evitano fughe/esfiltrazioni di dati.

Questa sezione descrive come utilizzare i 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 i servizi Google Cloud nei tuoi progetti e ridurre il rischio di esfiltrazione dei dati.

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

Per una panoramica dettagliata dei vantaggi dei perimetri di servizio, consulta la Panoramica dei Controlli di servizio VPC.

Quando utilizzi i Controlli di servizio VPC, tieni presente che:

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

Apigee e Apigee hybrid si integrano entrambi con Controlli di servizio VPC. Per un elenco completo dei prodotti che si integrano con i Controlli di servizio VPC, vedi 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 nessuna destinazione Internet pubblica. Devi instradare il traffico al tuo VPC stabilendo route personalizzate. Consulta Importazione ed esportazione di route personalizzate.

Configurazione di Controlli di servizio VPC con Apigee

Il processo generale per la configurazione di Controlli di servizio VPC con Apigee è il seguente:

  1. Abilita Controlli di servizio VPC.
  2. Crea un nuovo perimetro di servizio.
  3. Configura il perimetro di servizio.

Questi passaggi sono descritti più dettagliatamente di seguito.

Per configurare Controlli di servizio VPC con Apigee:

  1. Abilita Controlli di servizio VPC per la connessione in peering dalla rete ad Apigee eseguendo il comando seguente:

    gcloud services vpc-peerings enable-vpc-service-controls \
      --network=NETWORK_NAME --project=PROJECT_ID

    Dove:

    • NETWORK_NAME è il nome della rete di peering VPC.

      Se hai utilizzato i valori predefiniti durante la configurazione di Apigee, il nome della rete è "DEFAULT". Negli ambienti di produzione, tuttavia, è il nome della rete di peering personalizzata.

    • PROJECT_ID è il nome del progetto che hai creato durante la procedura di configurazione di 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.

  2. Crea un nuovo perimetro come descritto nella guida rapida di 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 ti consiglia di proteggere tutti i servizi quando crei un perimetro, inclusa l'API Apigee.

    Per ulteriori informazioni, consulta la sezione Creare un perimetro di servizio.

  3. Configura il perimetro di servizio, come descritto nella sezione Dettagli e configurazione del perimetro di servizio.

Per aggiungere un portale integrato all'interno del tuo perimetro, consulta l'articolo Aggiungere un portale integrato al perimetro.

Configurazione di Controlli di servizio VPC con Apigee hybrid

Apigee hybrid supporta i Controlli di servizio VPC, ma devi eseguire ulteriori passaggi. Il processo generale per l'integrazione di Apigee hybrid con i Controlli di servizio VPC è il seguente:

  1. Configura la connettività privata.
  2. Servizi aggiuntivi sicuri all'interno del perimetro.
  3. Configura un repository privato. (un repository privato si trova all'interno del perimetro; non deve necessariamente essere un repository locale finché si trova all'interno del perimetro.)
  4. Esegui il push delle immagini Apigee nel repository privato.
  5. Aggiorna le sostituzioni per utilizzare il repository privato durante il processo di installazione e configurazione ibrida.

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

Per configurare Controlli di servizio VPC con Apigee hybrid:

  1. Configura indirizzi IP privati per i tuoi host di rete ibridi, come descritto in Configurare la connettività privata alle API e ai servizi Google. Questo implica la configurazione di route, regole firewall e voci DNS per consentire alle API di Google di accedere a tali IP privati.
  2. Segui i passaggi descritti in Configurazione di 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 utilizzi GKE)
    • Google Container Registry (se lo utilizzi come repository locale)

    Per aggiungere questi servizi al perimetro, segui le istruzioni nella sezione Dettagli e configurazione del perimetro di servizio.

  3. Copia le immagini Apigee nel repository privato:
    1. 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
    2. Tagga le immagini.

      L'esempio seguente 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 di identificazione nel percorso del repository per ogni immagine.

    3. Esegui il push delle immagini nel 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

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

  4. Aggiorna il file di override in modo che rimandi gli URL dell'immagine al tuo repository privato, come descritto in Specificare le sostituzioni 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-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

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

Concessione dell'accesso ai portali integrati al perimetro

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 che supportano VPC-SC.

Concedere un livello di accesso ai portali:

  • Non inserisce portali integrati all'interno del perimetro.
  • Consente l'accesso ai portali integrati dall'esterno del perimetro.
  • Consente l'esposizione ai dati Apigee protetti di VPC-SC (come i dati dell'applicazione) a utenti del portale esterni al perimetro VPC-SC.

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

Prerequisiti

Prima di concedere l'accesso al perimetro di un portale integrato, devi abilitare Access Context Manager API per il tuo progetto, se non è già abilitato. Puoi farlo in Google Cloud Console o utilizzando il comando services enable.

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

Inoltre, devi avere l'indirizzo email dell'account di servizio per il progetto in cui viene utilizzato il portale. Per ottenere questo dato, sono necessari l'ID progetto GCP e il numero di progetto. I seguenti passaggi spiegano come ottenere questi valori:

  1. Ottieni i dettagli del progetto GCP utilizzando il comando projects list, come mostra il seguente esempio:
    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 nella tua organizzazione GCP.

  2. Identifica l'indirizzo email dell'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.

    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 vuoi è 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

  3. Ottieni l'ID criterio (o perimetro) utilizzando il comando access-context-manager policies list. Passa l'ID organizzazione a questo comando, come mostra l'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

    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 al perimetro ai portali integrati

Per concedere l'accesso al perimetro di un portale integrato:

  1. Raccogli l'indirizzo email dell'account di servizio e l'ID criterio di VPC-SC, come descritto nella sezione Prerequisiti.
  2. Crea un file delle condizioni sulla tua 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, ma deve avere un'estensione *.yaml. Ad esempio, my-portal-access-rules.yaml.

  3. Nel file delle condizioni, aggiungi una sezione members che specifichi l'account di servizio Apigee, come illustrato 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 del livello di accesso. Per ulteriori informazioni sulla creazione di un file delle condizioni, consulta Limitare l'accesso per account utente o di servizio.

  4. 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. Il titolo può essere qualsiasi cosa tu voglia, ma Google consiglia di assegnargli un valore significativo in modo che tu e gli altri amministratori sapete a cosa serve. Ad esempio, Livello di accesso del mio portale.
    • 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
  5. 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

Risolvere i problemi

Verifica quanto segue:

  • Se l'API Access Context Manager non è abilitata per il tuo progetto GCP, gcloud ti chiede di abilitarla quando tenti di elencare o impostare i criteri.
  • Assicurati di utilizzare l'ID organizzazione GCP e non l'ID organizzazione Apigee quando ricevi i dettagli relativi all'organizzazione.
  • Alcuni comandi descritti in questa sezione richiedono autorizzazioni elevate; ad esempio, per ottenere dettagli sugli account di servizio per un progetto, devi essere un proprietario del progetto.
  • Per verificare l'esistenza dell'account di servizio, esegui il comando iam service-accounts describe, come mostrato nell'esempio seguente:

    gcloud iam service-accounts describe service-8675309@gcp-sa-apigee.iam.gserviceaccount.com

    gcloud risponde con 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 errore NOT_FOUND.

Limitazioni

Le integrazioni Apigee con controlli di servizio VPC presentano le seguenti limitazioni:

  • I portali integrati richiedono passaggi aggiuntivi per la configurazione.
  • Devi eseguire il deployment dei portali Drupal all'interno del perimetro di servizio.