Casi d'uso per la sicurezza dei servizi (legacy)

Questo documento descrive i casi d'uso comuni della sicurezza di Cloud Service Mesh. Usa questa informazioni per aiutarti a determinare il modello di sicurezza più adatto alle tue esigenze. Questo documento fornisce anche una panoramica di alto livello di ciò che devi configurare per ogni caso d'uso.

Per una panoramica della sicurezza dei servizi, vedi Sicurezza del servizio Cloud Service Mesh.

Questo documento riguarda le configurazioni che utilizzano le API di bilanciamento del carico. Questo è un documento legacy.

Abilitazione di TLS reciproco per i servizi nel mesh

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

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

La sezione seguente omette la discussione sulla regola di forwarding globale, destinazione Proxy HTTPS e mappa URL. Queste risorse dell'API Compute Engine sono obbligatorie per creare la rete mesh, ma non è necessario aggiornarli per abilitare mTLS.

Il pattern precedente può essere ottenuto configurando quanto segue: alle risorse dell'API Compute Engine. Questo diagramma utilizza i proxy sidecar, la configurazione di un'applicazione gRPC senza proxy con mTLS utilizza le stesse risorse.

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

Per creare questo modello, segui questi passaggi:

  1. Crea un criterio TLS (Client Transport Layer Security).
  2. Crea un criterio TLS del server.
  3. Aggiorna il campo securitySettings nei servizi di backend globali esistenti per fare riferimento al nuovo criterio TLS del client.

  4. Crea un criterio per gli endpoint:

    1. Fai riferimento al criterio TLS del server nel campo server_tls_policy.

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

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

      Nel diagramma precedente, le etichette "mesh-service":"true" sono configurato sul criterio dell'endpoint e sui client Cloud Service Mesh. Puoi scegliere le etichette adatte al tuo deployment.

    3. Se vuoi, definisci un valore TrafficPortSelector che applichi solo i criteri Quando le richieste in entrata vengono effettuate alla porta specificata sul piano dati. dell'oggetto.

Il seguente diagramma mostra le risorse Compute Engine utilizzate configurare mTLS, a prescindere dal fatto che utilizzi Envoy o una rete gRPC senza proxy un'applicazione.

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

Il seguente diagramma mostra il flusso di traffico ed elenca l'API Compute Engine e le risorse configurate per abilitare mTLS. Il proxy sidecar locale che si trova insieme al pod GKE del Servizio B è presente l'endpoint la comunicazione.

Risorse dell'API Compute Engine e flusso di traffico per mTLS all'interno di una mesh.
Risorse dell'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 uno strumento di abbinamento degli endpoint e, facoltativamente, su questi endpoint.

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

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

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

      • In alternativa, i metadati possono essere compilati automaticamente utilizzi GKE aggiungendo le coppie chiave-valore Sezione env di demo_server.yaml o demo_client.yaml . Questi valori sono forniti nel Guida alla configurazione di Envoy e guida alla configurazione di gRPC senza proxy.

        Ad esempio, solo per Envoy, puoi aggiungere il prefisso alla chiave Prefisso ISTIO_META_. 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 si fa riferimento nel criterio dell'endpoint vengono applicate 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 che si trova anche Campo TRAFFICDIRECTOR_INBOUND_BACKEND_PORTS, fornito al client Cloud Service Mesh nelle informazioni di bootstrap.

  2. Fa riferimento ai criteri TLS del client, TLS del server e ai criteri di autorizzazione che configurano gli endpoint in cui vengono risolte le richieste.

La configurazione di modalità TLS non compatibili può causare l'interruzione delle le comunicazioni. Ad esempio, l'impostazione di OPEN sul servizio di backend globale lasciando vuoto il campo del criterio TLS del client e impostando MTLS come valore il criterio TLS del server nel criterio dell'endpoint, causando un errore di comunicazione tentativi. Questo perché gli endpoint configurati per accettare solo mTLS rifiutare i tentativi di stabilire canali di comunicazione non autenticati.

Nota la distinzione tra un criterio TLS del client e un criterio TLS del server collegati rispettivamente a un servizio di backend globale e a un criterio endpoint:

  • Il criterio TLS del client viene applicato al servizio di backend globale. Dice il proxy Envoy o il client senza proxy quale modalità TLS, identità e peer di convalida da usare per gestire il servizio.
  • Il criterio TLS del server è collegato al criterio dell'endpoint. Indica server per l'utilizzo di modalità TLS, identità e convalida peer connessioni in entrata.

Abilitazione di TLS per un gateway in entrata

Dopo aver configurato mTLS per le comunicazioni in-mesh, potresti voler il traffico sicuro che entra nel mesh, noto come traffico in entrata. Cloud Service Mesh può configurare il piano dati in modo da richiedere il traffico in entrata verso utilizzano canali di comunicazione con crittografia TLS.

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

  • I servizi nel mesh terminano il protocollo TLS per il traffico proveniente da un bilanciatore del carico. Nella questo modello, ogni servizio nel mesh è configurato come backend configurazione del bilanciatore del carico, nello specifico nella mappa 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, servizio dedicato nella rete mesh, il gateway in entrata, è configurato come il backend nella configurazione del bilanciatore del carico, nello specifico mappa URL del bilanciatore.

Entrambe le opzioni sono spiegate in questa sezione.

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

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

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

Lo stesso pattern si applica quando utilizzi un Application Load Balancer 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 prova a Stabilire una connessione con i servizi nella rete mesh.
  3. Configura Cloud Service Mesh in modo che i client Cloud Service Mesh vengano terminati HTTPS e presentare certificati al client, che in questo caso è la con il bilanciatore del carico di rete passthrough esterno regionale.

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

Quando configuri la sicurezza di Cloud Service Mesh, configuri diverse alle risorse dell'API Compute Engine. Queste risorse sono separate e quelle configurate per il bilanciatore del carico. In altre parole, crei due insiemi di risorse dell'API Compute Engine (regola di forwarding globale, target proxy, mappa URL e servizi di backend globali) con bilanciamento del carico diverso schemi:

  • Un insieme di risorse configura il bilanciatore del carico, che include schema di bilanciamento del carico INTERNAL_MANAGED.
  • L'altro insieme di risorse configura Cloud Service Mesh, che include schema di bilanciamento del carico INTERNAL_SELF_MANAGED.

Nel passaggio 3, configurerai Cloud Service Mesh in modo che Cloud Service Mesh termina il protocollo HTTPS e presenta certificati ai client.

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

In questo modello, esegui queste operazioni:

  1. Crea un criterio TLS del server: configura terminationTls su transportAuthentication.
  2. Crea un criterio per gli endpoint:
    1. Fai riferimento al criterio TLS del server nel campo authentication.
    2. Definisci un EndpointMatcher per selezionare il piano dati xDS entità che devono applicare l'autenticazione al traffico in entrata.
    3. Se vuoi, definisci un valore TrafficPortSelector che applichi il valore solo quando le richieste in entrata vengono inviate alla porta specificata con il client Cloud Service Mesh.

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

Il gateway in entrata termina il 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 tuo mesh. Un proxy centrale si trova invece sul perimetro della rete mesh e instrada il traffico ai servizi all'interno del mesh, in base sulla configurazione che riceve da Cloud Service Mesh. Il proxy centrale può essere un proxy Envoy di cui hai eseguito il deployment su istanze di macchine virtuali (VM) in un gruppo di istanze gestite di Compute Engine.

TLS a un gateway in entrata con mTLS all'interno di un 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, se vuoi, di configurare le connessioni all'interno della rete mesh in modo con mTLS. Queste includono connessioni tra il gateway in entrata e dei servizi in-mesh e delle connessioni tra i servizi in-mesh.

Dal punto di vista della configurazione, segui questi passaggi:

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

Per il terzo passaggio, configura Cloud Service Mesh per la terminazione di HTTPS presentare certificati come segue:

  1. Crea una regola di forwarding globale e un proxy HTTPS di destinazione per che rappresentano il percorso del traffico in entrata nella tua rete mesh.

  2. Collega la mappa URL esistente per la tua rete mesh a questa destinazione Proxy HTTPS. La mappa URL contiene già riferimenti ai tuoi i vari servizi di backend globali del mesh, in base fornita durante la configurazione di mesh e mTLS.

  3. Crea un criterio TLS del server: configura serverCertificate.

  4. Collega la risorsa del criterio TLS del server al proxy HTTPS di destinazione.

Il pattern del gateway in entrata è particolarmente utile nelle grandi organizzazioni che utilizzano VPC condiviso. In una situazione di questo tipo, un team può e consentire l'accesso ai suoi servizi tramite un gateway in entrata. Nella versione precedente nel diagramma, quando configuri la regola di forwarding globale, fornisci un un indirizzo IP diverso (in questo esempio, 10.0.0.2) rispetto a quello fornito quando configuri la rete mesh (in questo esempio, l'indirizzo mesh è 10.0.0.1). Client che comunicano tramite un piano dati xDS configurato da Cloud Service Mesh può utilizzare questo indirizzo per accedere al gateway in entrata.

Ad esempio, supponiamo che:

  • Due progetti di servizio (1 e 2), entrambi collegati allo stesso VPC condiviso in ogni rete.

  • 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 dall'indirizzo 10.0.0.2 (VIP).

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

    Il progetto di servizio 2 potrebbe avere o meno un proprio gateway in entrata.

  • Cloud Service Mesh configura i client Cloud Service Mesh in ciascun servizio progetto. Viene eseguito il bootstrap dei client 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. Questo consente ai proprietari del progetto di servizio 1 di configurare routing, sicurezza specifici per il traffico che entra nel mesh. In effetti, i proprietari del progetto di servizio 1 può dire ad altri che i client nel tuo mesh possono raggiungere su 10.0.0.2.

Limitazioni

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

Passaggi successivi