Casi d'uso della sicurezza del servizio

Questo documento descrive i casi d'uso comuni per la sicurezza di Cloud Service Mesh. Utilizza queste informazioni per determinare il modello di sicurezza più adatto alle tue esigenze. Questo documento fornisce anche una panoramica generale di ciò che devi configurare per ogni caso d'uso.

Per una panoramica della sicurezza dei servizi, consulta Sicurezza dei servizi Cloud Service Mesh.

Abilitazione di mutual TLS per i servizi nel mesh

In una rete mesh di servizi, puoi attivare TLS reciproco (mTLS) in modo che sia il client sia il server in una comunicazione debbano dimostrare la propria identità e criptare le comunicazioni.

Autenticazione TLS reciproca (mTLS) in una rete mesh di servizi.
Autenticazione TLS reciproca (mTLS) in una mesh di servizi (fai clic per ingrandire)

La sezione seguente omette la discussione delle risorse Mesh, Gateway e Route. Queste risorse API sono necessarie per creare la mesh e instradare il traffico, ma non devi aggiornarle per attivare mTLS.

Il pattern precedente può essere ottenuto configurando le seguenti risorse dell'API Compute Engine. Questo diagramma utilizza proxy sidecar, ma la configurazione di un'applicazione gRPC senza proxy conmTLSS reciproca utilizza le stesse risorse.

Risorse API Compute Engine per mTLS all'interno di un mesh.
Risorse API Compute Engine per mTLS all'interno di un mesh (fai clic per ingrandire)

Per creare questo modello:

  1. Crea una policy Transport Layer Security (TLS) del client.
  2. Crea una policy TLS del server.
  3. Aggiorna il campo securitySettings nei servizi di backend globali esistenti in modo che faccia riferimento alla nuova policy TLS del client.

  4. Crea una policy endpoint:

    1. Fai riferimento alla policy TLS del server nel campo server_tls_policy.

    2. Definisci un EndpointMatcher per selezionare i client Cloud Service Mesh che devono applicare l'autenticazione al traffico in entrata.

      La selezione dei client Cloud Service Mesh si basa sulle etichette specificate nella configurazione di bootstrap del client Cloud Service Mesh. Queste etichette possono essere fornite manualmente o compilate automaticamente in base alle etichette fornite ai deployment di Google Kubernetes Engine (GKE).

      Nel diagramma precedente, le etichette "mesh-service":"true" sono configurate nella policy dell'endpoint e nei client Cloud Service Mesh. Puoi scegliere le etichette più adatte al tuo deployment.

    3. (Facoltativo) Definisci un TrafficPortSelector che applichi i criteri solo quando vengono effettuate richieste in entrata alla porta specificata nell'entità del data plane.

Il seguente diagramma mostra le risorse Compute Engine che configuri per mTLS, indipendentemente dal fatto che utilizzi Envoy o un'applicazione gRPC proxyless.

Risorse API Compute Engine per mTLS all'interno di un mesh.
Risorse API Compute Engine per mTLS all'interno di un mesh (fai clic per ingrandire)

Il seguente diagramma mostra il flusso di traffico ed elenca le risorse API Compute Engine che configuri per abilitare mTLS. Il proxy sidecar locale che si trova accanto al pod GKE del servizio B è l'endpoint nella comunicazione.

Risorse API Compute Engine e flusso di traffico per mTLS all'interno di un mesh.
Risorse API Compute Engine e flusso di traffico per mTLS all'interno di un mesh (fai clic per ingrandire)

Il criterio dell'endpoint esegue le seguenti operazioni:

  1. Seleziona un insieme di endpoint utilizzando un matcher di endpoint e, facoltativamente, le porte su questi endpoint.

    1. Il matcher degli endpoint ti consente di specificare regole che determinano se un client Cloud Service Mesh riceve la configurazione. Queste regole si basano sui metadati xDS che l'entità del piano dati fornisce al control plane, in questo caso Cloud Service Mesh.

      Puoi aggiungere etichette al client Cloud Service Mesh nel seguente modo:

      • Puoi specificare manualmente questi metadati nel file di bootstrap del client Cloud Service Mesh.

      • In alternativa, i metadati possono essere compilati automaticamente quando utilizzi GKE aggiungendo le coppie chiave-valore alla sezione env dei file demo_server.yaml o demo_client.yaml. Questi valori sono forniti nella guida alla configurazione di Envoy e nella guida alla configurazione di gRPC proxyless.

        Ad esempio, solo con Envoy puoi aggiungere il prefisso ISTIO_META_ alla chiave. I nomi variabile di ambiente proxy che iniziano con ISTIO_META_ sono inclusi nel bootstrap generato e inviati al server xDS.

        - name: ISTIO_META_app
  value: 'review'
- name: ISTIO_META_version
  value: 'canary'

    2. Se specifichi una porta, i criteri a cui viene fatto riferimento nella policy dell'endpoint vengono applicati solo alle richieste in entrata che specificano la stessa porta. Se non specifichi una porta, i criteri vengono applicati alle richieste in entrata che specificano una porta presente anche nel campo TRAFFICDIRECTOR_INBOUND_BACKEND_PORTS, fornito al client Cloud Service Mesh nelle informazioni di bootstrap.

  2. Fa riferimento alle policy TLS del client, TLS del server e di autorizzazione che configurano gli endpoint a cui vengono risolte le richieste.

La configurazione di modalità TLS incompatibili potrebbe causare un'interruzione delle comunicazioni. Ad esempio, se imposti OPEN sul servizio di backend globale o se lasci vuoto il campo della policy TLS del client e imposti MTLS come valore della policy TLS del server nella policy dell'endpoint, i tentativi di comunicazione non vanno a buon fine. Questo perché gli endpoint configurati per accettare solo mTLS rifiutano i tentativi di stabilire canali di comunicazione non autenticati.

Tieni presente la distinzione tra una policy TLS del client e una policy TLS del server collegate rispettivamente a un servizio di backend globale e a una policy endpoint:

  • La policy TLS del client viene applicata al servizio di backend globale. Indica al proxy Envoy o al client senza proxy la modalità TLS, l'identità e l'approccio di convalida peer da utilizzare quando si accede al servizio.
  • Il criterio TLS del server è collegato al criterio dell'endpoint. Indica al server quale modalità TLS, identità e approccio di convalida peer utilizzare per le connessioni in entrata.

Attivazione di TLS per un gateway in entrata

Dopo aver configurato mTLS per le comunicazioni all'interno del mesh, potresti voler proteggere il traffico in entrata nel mesh, noto come traffico in entrata. Cloud Service Mesh può configurare il tuo data plane in modo che richieda che il traffico in entrata utilizzi canali di comunicazione criptati con TLS.

Per raggiungere questo obiettivo, scegli una delle seguenti opzioni di architettura:

  • I servizi nel mesh terminano TLS per il traffico proveniente da un bilanciatore del carico. In questo modello, ogni servizio nel mesh viene configurato come backend nella configurazione del bilanciatore del carico, in particolare nella mappa degli URL del bilanciatore del carico.
  • Un gateway in entrata termina TLS per il traffico proveniente da un bilanciatore del carico prima di inoltrare il traffico ai servizi nel mesh. In questo modello, un servizio dedicato nel mesh, il gateway di ingresso, è configurato come backend nella configurazione del bilanciatore del carico, in particolare nella mappa URL del bilanciatore del carico.

Entrambe le opzioni sono spiegate in questa sezione.

I servizi nel mesh terminano TLS per il traffico proveniente da un bilanciatore del carico

Se vuoi rendere disponibili i tuoi servizi ai client al di fuori di Google Cloud, puoi utilizzare un bilanciatore del carico delle applicazioni esterno. I client inviano il traffico all'indirizzo IP virtuale (VIP) Anycast globale del bilanciatore del carico, che poi inoltra il traffico ai servizi nel mesh. Ciò significa che ci sono due connessioni quando un client esterno deve raggiungere un servizio nel mesh.

TLS a un servizio nel mesh.
TLS a un servizio nella mesh (fai clic per ingrandire)

Lo stesso pattern si applica quando utilizzi un bilanciatore del carico delle applicazioni interno. Il traffico proveniente dai client interni raggiunge prima il bilanciatore del carico, che poi stabilisce una connessione al backend.

Per proteggere entrambe le connessioni:

  1. Proteggi la connessione tra il client e il bilanciatore del carico utilizzando un bilanciatore del carico delle applicazioni esterno.
  2. Configura il bilanciatore del carico in modo che utilizzi i protocolli HTTPS o HTTP/2 quando tenta di stabilire una connessione con i servizi nel mesh.
  3. Configura Cloud Service Mesh in modo che i client Cloud Service Mesh terminino HTTPS e presentino i certificati al client, che in questo caso è il bilanciatore del carico.

Per ulteriori informazioni sui passaggi 1 e 2, consulta Configurazione di un bilanciatore del carico HTTPS esterno multiregionale basato sui contenuti.

Quando configuri la sicurezza di Cloud Service Mesh, configuri varie risorse API Compute Engine. Queste risorse sono separate dalle risorse che configuri per il bilanciatore del carico. Crea un insieme di risorse dell'API Compute Engine (regola di forwarding globale, proxy di destinazione, mappa URL e servizi di backend globali) per il bilanciatore del carico e configura Cloud Service Mesh con le API di routing del servizio. Inoltre, nella risorsa del servizio di backend, il bilanciatore del carico ha lo schema di bilanciamento del carico INTERNAL_MANAGED e Cloud Service Mesh ha lo schema di bilanciamento del carico INTERNAL_SELF_MANAGED.

Nel passaggio 3, configuri Cloud Service Mesh in modo che i client Cloud Service Mesh terminino HTTPS e presentino i certificati ai client.

Risorse API Compute Engine per TLS al servizio nel mesh.
Risorse API Compute Engine per TLS al servizio in mesh (fai clic per ingrandire)

In questo modello, esegui le seguenti operazioni:

  1. Crea un serverTlsPolicy: configura serverCertificate sulla risorsa serverTlsPolicy.
  2. Crea un criterio endpoint:
    1. Fai riferimento alla policy TLS del server nel campo authentication.
    2. Definisci un EndpointMatcher per selezionare le entità del data plane xDS che devono applicare l'autenticazione al traffico in entrata.
    3. (Facoltativo) Definisci un TrafficPortSelector che applichi i criteri solo quando vengono effettuate richieste in entrata alla porta specificata sul client Cloud Service Mesh.

Poiché il bilanciatore del carico delle applicazioni esterno è già configurato per avviare connessioni TLS ai servizi nel mesh, Cloud Service Mesh deve solo configurare i client Cloud Service Mesh per terminare le connessioni TLS.

Il gateway in entrata termina TLS per il traffico proveniente da un bilanciatore del carico prima di inoltrare il traffico ai servizi nel mesh

Se vuoi esporre solo un gateway in entrata al bilanciatore del carico, puoi utilizzare il pattern di deployment del gateway in entrata. In questo pattern, il bilanciatore del carico non indirizza direttamente i servizi nel mesh. Un proxy intermedio si trova al limite del mesh e indirizza il traffico ai servizi all'interno del mesh, in base alla configurazione che riceve da Cloud Service Mesh. Il proxy intermedio può essere un proxy Envoy di cui hai eseguito il deployment su istanze di macchine virtuali (VM) in un gruppo di istanze gestite Compute Engine.

TLS a un gateway in entrata con mTLS all'interno di una rete mesh.
TLS a un gateway in entrata con mTLS all'interno di un mesh (fai clic per ingrandire)

Dal punto di vista della sicurezza, configuri il gateway in entrata per terminare TLS e poi, facoltativamente, configuri le connessioni all'interno del mesh in modo che siano protette da mTLS. Sono incluse le connessioni tra il gateway in entrata e i servizi in-mesh, nonché le connessioni tra i servizi in-mesh.

Dal punto di vista della configurazione, devi:

  1. Configura la tua mesh di servizi e attiva mTLS per le comunicazioni all'interno della mesh (come spiegato in precedenza).
  2. Configura il bilanciatore del carico per instradare il traffico al gateway in entrata e avviare le connessioni utilizzando il protocollo HTTPS (come spiegato in precedenza).
  3. Crea un insieme di risorse API Compute Engine che rappresentano il gateway in entrata e il relativo criterio TLS server.

Per il terzo passaggio, configura Cloud Service Mesh per terminare HTTPS e presentare i certificati nel seguente modo:

  1. Crea una risorsa Mesh per rappresentare la mesh.

  2. Crea una risorsa Route che rimandi ai servizi di backend globali corretti e collega la risorsa Route alla risorsa Mesh.

  3. Crea una policy TLS del server: configura serverCertificate.

  4. Crea una risorsa Gateway per rappresentare il gateway in entrata gestito da Cloud Service Mesh.

  5. Collega la risorsa della policy TLS del server alla risorsa Gateway.

Il pattern del gateway in entrata è particolarmente utile nelle grandi organizzazioni che utilizzano il VPC condiviso. In questa impostazione, un team potrebbe consentire l'accesso ai propri servizi solo tramite un gateway di ingresso. Nel diagramma precedente, quando configuri la regola di forwarding globale per il bilanciatore del carico, fornisci un indirizzo IP diverso (in questo esempio, 10.0.0.2) da quello fornito quando configuri il mesh (in questo esempio, l'indirizzo del mesh è 10.0.0.1). I client che comunicano tramite un'entità del piano dati xDS configurata con Cloud Service Mesh possono utilizzare questo indirizzo per accedere al gateway in entrata.

Ad esempio, supponiamo quanto segue:

  • Due progetti di servizio (1 e 2), entrambi collegati alla stessa rete VPC condiviso.

  • Il progetto di servizio 1 contiene un mesh di servizi configurato da Cloud Service Mesh.

    Il progetto di servizio 1 ha configurato un mesh e un gateway in entrata. Questo gateway in entrata è raggiungibile all'indirizzo/VIP 10.0.0.2.

  • Il progetto di servizio 2 contiene un mesh di servizi configurato da Cloud Service Mesh.

    Il progetto di servizio 2 potrebbe avere o meno il proprio gateway di ingresso.

  • Cloud Service Mesh configura i client Cloud Service Mesh in ogni progetto di servizio. I client sono avviati per utilizzare la stessa rete.

Data questa configurazione, i client nel mesh del progetto di servizio 2 possono comunicare con il gateway in entrata nel progetto di servizio 1 utilizzando il VIP 10.0.0.2. In questo modo, i proprietari del progetto di servizio 1 possono configurare il routing, la sicurezza e altri criteri specifici per il traffico in entrata nel mesh. In effetti, i proprietari del progetto di servizio 1 possono comunicare ad altri che i client nella mesh possono raggiungere i miei servizi su 10.0.0.2.

Limitazioni

La sicurezza del servizio Cloud Service Mesh è supportata solo con GKE. Non puoi eseguire il deployment della sicurezza del servizio con Compute Engine.

Passaggi successivi