Anthos Service Mesh tramite esempi: mTLS


In Anthos Service Mesh 1.5 e versioni successive, il protocollo TLS reciprocamente attivo (mTLS automatico) è abilitato per impostazione predefinita. Con mTLS automatico, un proxy sidecar client rileva automaticamente se il server ha un file collaterale. Il file collaterale client invia mTLS ai carichi di lavoro con file collaterali e invia testo non crittografato ai carichi di lavoro senza file collaterali. Tuttavia, tieni presente che i servizi accettano sia il traffico in testo non crittografato che il traffico mTLS. Quando inietta i proxy collaterali ai tuoi pod, ti consigliamo anche di configurare i tuoi servizi in modo che accettino solo il traffico mTLS.

Con Anthos Service Mesh, puoi applicare mTLS, all'esterno del codice dell'applicazione, applicando un singolo file YAML. Anthos Service Mesh ti offre la flessibilità di applicare un criterio di autenticazione all'intero mesh di servizi, a uno spazio dei nomi o a un singolo carico di lavoro.

mTLS reciproca

Costi

In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud possono essere idonei a una prova senza costi aggiuntivi.

Al termine di questo tutorial, puoi evitare i costi continui eliminando le risorse che hai creato. Per ulteriori informazioni, consulta Pulizia.

Prima di iniziare

  • Verifica che la fatturazione sia attivata per il tuo progetto Cloud. Scopri come verificare che la fatturazione sia abilitata per il tuo progetto.

  • Installa Anthos Service Mesh su un cluster GKE ed esegui il deployment di un gateway in entrata. Se hai bisogno di configurare un cluster per questo tutorial, consulta la guida rapida di Anthos Service Mesh, che illustra la procedura:

    • Creazione di un cluster GKE.
    • Esegue il provisioning di Anthos Service Mesh gestito.
    • Deployment di un gateway in entrata.
    • È in corso il deployment dell'applicazione di esempio Online Boutique dal repository anthos-service-mesh-packages, che viene modificato dal set originale di manifest nel repository microservices-demo. Seguendo le best practice, il deployment di ogni servizio viene eseguito in uno spazio dei nomi separato con un account di servizio univoco.

Accedi a Boutique online

  1. Imposta il contesto attuale per kubectl nel cluster in cui hai eseguito il deployment di Boutique online:

    gcloud container clusters get-credentials CLUSTER_NAME  \
        --project=PROJECT_ID \
        --zone=CLUSTER_LOCATION
    
  2. Elenca i servizi nello spazio dei nomi frontend:

    kubectl get services -n frontend
    

    Nota che frontend-external è un LoadBalancer e ha un indirizzo IP esterno. L'applicazione di esempio include un servizio che è un bilanciatore del carico, in modo da poterne eseguire il deployment su GKE senza Anthos Service Mesh.

  3. Visita l'applicazione nel tuo browser utilizzando l'indirizzo IP esterno del servizio frontend-external:

    http://FRONTEND_EXTERNAL_IP/
    
  4. Anthos Service Mesh ti offre la possibilità di eseguire il deployment di un gateway in entrata. Puoi anche accedere a Online Boutique utilizzando l'indirizzo IP esterno del gateway in entrata. Recupera l'IP esterno del gateway. Sostituisci i segnaposto con le seguenti informazioni:

    • GATEWAY_SERVICE_NAME : il nome del servizio gateway in entrata. Se hai eseguito il deployment del gateway di esempio senza modifiche o se hai eseguito il deployment del gateway in entrata predefinito, il nome è istio-ingressgateway.
    • GATEWAY_NAMESPACE: lo spazio dei nomi in cui hai eseguito il deployment del gateway in entrata. Se hai eseguito il deployment del gateway in entrata predefinito, lo spazio dei nomi è istio-system.
    kubectl get service GATEWAY_NAME -n GATEWAY_NAMESPACE
    
  5. Apri un'altra scheda nel browser e visita l'applicazione utilizzando l'indirizzo IP esterno del gateway in entrata:

    http://INGRESS_GATEWAY_EXTERNAL_IP/
    
  6. Esegui questo comando per curl il servizio frontend con HTTP normale da un altro pod. Poiché i servizi si trovano in spazi dei nomi diversi, devi curl il nome DNS del servizio frontend.

    kubectl exec \
      $(kubectl get pod -l app=productcatalogservice -n product-catalog -o jsonpath={.items..metadata.name}) \
      -c istio-proxy -n product-catalog -- \
      curl http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
    

    La tua richiesta ha esito positivo con lo stato 200 perché per impostazione predefinita è accettato sia il traffico TLS sia il traffico di testo non crittografato.

Abilita TLS reciproco per spazio dei nomi

Puoi forzare l'applicazione di mTLS applicando un criterio PeerAuthentication con kubectl.

  1. Salva il criterio di autenticazione seguente come mtls-namespace.yaml.

    cat <<EOF > mtls-namespace.yaml
    apiVersion: "security.istio.io/v1beta1"
    kind: "PeerAuthentication"
    metadata:
      name: "namespace-policy"
    spec:
      mtls:
        mode: STRICT
    EOF
    

    La riga mode: STRICT nel file YAML configura i servizi in modo che accettino solo mTLS. Per impostazione predefinita, mode è PERMISSIVE, che configura i servizi per accettare sia il testo non crittografato che mTLS.

  2. Applica il criterio di autenticazione per configurare tutti i servizi di Boutique online in modo che accettino solo mTLS:

    for ns in ad cart checkout currency email frontend loadgenerator \
         payment product-catalog recommendation shipping; do
    kubectl apply -n $ns -f mtls-namespace.yaml
    done
    

    Output previsto:

    peerauthentication.security.istio.io/namespace-policy created
    peerauthentication.security.istio.io/namespace-policy created
    peerauthentication.security.istio.io/namespace-policy created
    peerauthentication.security.istio.io/namespace-policy created
    peerauthentication.security.istio.io/namespace-policy created
    peerauthentication.security.istio.io/namespace-policy created
    peerauthentication.security.istio.io/namespace-policy created
    peerauthentication.security.istio.io/namespace-policy created
    peerauthentication.security.istio.io/namespace-policy created
    peerauthentication.security.istio.io/namespace-policy created
    peerauthentication.security.istio.io/namespace-policy created

  3. Vai alla scheda del browser che accede a Online Boutique utilizzando l'indirizzo IP esterno del servizio frontend-external:

    http://FRONTEND_EXTERNAL_IP/
    
  4. Aggiorna la pagina. Il browser visualizza il seguente errore:

    sito non raggiungibile

    Se aggiorni la pagina, viene inviato il testo non crittografato al servizio frontend. A causa del STRICTcriterio di autenticazione, il proxy sidecar blocca la richiesta al servizio.

  5. Vai alla scheda del browser che accede alla Boutique online utilizzando l'indirizzo IP esterno di istio-ingressgateway e aggiorna la pagina, che viene visualizzata correttamente. Quando accedi a Online Boutique utilizzando il gateway in entrata, la richiesta segue il seguente percorso:

    mTLS reciproca

    Flusso di autenticazione mTLS:

    1. Il browser invia una richiesta HTTP in testo non crittografato al server.
    2. Il container proxy del gateway in entrata intercetta la richiesta.
    3. Il proxy del gateway in entrata esegue un handshake TLS con il proxy lato server (il servizio di frontend in questo esempio). Questo handshake include uno scambio di certificati. Questi certificati sono precaricati nei container proxy da Anthos Service Mesh.
    4. Il proxy del gateway in entrata esegue un controllo di denominazione sicura sul certificato del server, verificando che il server sia in esecuzione da un'identità autorizzata.
    5. Il gateway in entrata e i proxy server stabiliscono una connessione TLS reciproca e il proxy del server inoltra la richiesta al contenitore dell'applicazione server (il servizio frontend).
  6. Esegui questo comando per curl il servizio frontend con HTTP normale da un altro pod.

    kubectl exec \
      $(kubectl get pod -l app=productcatalogservice -n product-catalog -o jsonpath={.items..metadata.name}) \
      -c istio-proxy -n product-catalog -- \
      curl http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
    

    La tua richiesta non va a buon fine perché tutti i servizi di Boutique Online sono impostati su STRICT mTLS e il proxy sidecar blocca la richiesta al servizio.

    Output previsto:

    000
    command terminated with exit code 56

Visualizza lo stato di mTLS

Puoi visualizzare lo stato delle funzionalità di sicurezza di GKE Enterprise, inclusi i criteri di autenticazione, nella console Google Cloud.

  1. Nella console Google Cloud, vai alla pagina Panoramica di GKE Enterprise.

    Vai a Panoramica

  2. Seleziona il progetto Google Cloud dall'elenco dei progetti nella barra dei menu.

  3. Nella scheda Stato dei criteri, a seconda della configurazione, fai clic su Visualizza criterio o Attiva criterio. Si apre la dashboard di Policy Controller.

  4. Fai clic sulla scheda Violazioni.

  5. In Tipo di risorsa, seleziona la casella di controllo Pod. Viene mostrato un elenco di pod che violano una norma.

Trovare ed eliminare i criteri di autenticazione

  1. Per un elenco di tutti i criteri PeerAuthentication nel mesh di servizi:

    kubectl get peerauthentication --all-namespaces
    

    L'output è simile al seguente:

    NAMESPACE         NAME               MODE     AGE
    ad                namespace-policy   STRICT   17m
    cart              namespace-policy   STRICT   17m
    checkout          namespace-policy   STRICT   17m
    currency          namespace-policy   STRICT   17m
    email             namespace-policy   STRICT   17m
    frontend          namespace-policy   STRICT   17m
    loadgenerator     namespace-policy   STRICT   17m
    payment           namespace-policy   STRICT   17m
    product-catalog   namespace-policy   STRICT   17m
    recommendation    namespace-policy   STRICT   17m
    shipping          namespace-policy   STRICT   17m
    
  2. Elimina il criterio di autenticazione da tutti gli spazi dei nomi di Boutique Online:

    for ns in ad cart checkout currency email frontend loadgenerator payment \
      product-catalog recommendation shipping; do
        kubectl delete peerauthentication -n $ns namespace-policy
    done;
    

    Output previsto:

    peerauthentication.security.istio.io "namespace-policy" deleted
    peerauthentication.security.istio.io "namespace-policy" deleted
    peerauthentication.security.istio.io "namespace-policy" deleted
    peerauthentication.security.istio.io "namespace-policy" deleted
    peerauthentication.security.istio.io "namespace-policy" deleted
    peerauthentication.security.istio.io "namespace-policy" deleted
    peerauthentication.security.istio.io "namespace-policy" deleted
    peerauthentication.security.istio.io "namespace-policy" deleted
    peerauthentication.security.istio.io "namespace-policy" deleted
    peerauthentication.security.istio.io "namespace-policy" deleted
    peerauthentication.security.istio.io "namespace-policy" deleted
    
  3. Accedi a Boutique online utilizzando l'indirizzo IP esterno del servizio frontend-external e aggiorna la pagina. La pagina viene visualizzata come previsto.

  4. Esegui questo comando per curl il servizio frontend con HTTP normale da un altro pod.

    kubectl exec \
      $(kubectl get pod -l app=productcatalogservice -n product-catalog -o jsonpath={.items..metadata.name}) \
      -c istio-proxy -n product-catalog -- \
      curl http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
    

    La tua richiesta ha esito positivo con lo stato 200 perché per impostazione predefinita è accettato sia il traffico TLS sia il traffico di testo non crittografato.

Se nella console Google Cloud aggiorni la pagina che mostra l'elenco Carichi di lavoro, ora lo stato di mTLS è Permissive.

Abilita TLS reciproco per carico di lavoro

Per impostare un criterio PeerAuthentication per un carico di lavoro specifico, devi configurare la sezione selector e specificare le etichette corrispondenti al carico di lavoro desiderato. Tuttavia, Anthos Service Mesh non può aggregare i criteri a livello di carico di lavoro per il traffico mTLS in uscita verso un servizio. Per gestire tale comportamento, devi configurare una regola di destinazione.

  1. Applica un criterio di autenticazione a un carico di lavoro specifico. Osserva come il criterio seguente utilizza etichette e selettori per scegliere come target il deployment di frontend specifico.

    cat <<EOF | kubectl apply -n frontend -f -
    apiVersion: "security.istio.io/v1beta1"
    kind: "PeerAuthentication"
    metadata:
      name: "frontend"
      namespace: "frontend"
    spec:
      selector:
        matchLabels:
          app: frontend
      mtls:
        mode: STRICT
    EOF
    

    Output previsto:

    peerauthentication.security.istio.io/frontend created
  2. Configura una regola di destinazione corrispondente.

    cat <<EOF | kubectl apply -n frontend -f -
    apiVersion: "networking.istio.io/v1alpha3"
    kind: "DestinationRule"
    metadata:
      name: "frontend"
    spec:
      host: "frontend.demo.svc.cluster.local"
      trafficPolicy:
        tls:
          mode: ISTIO_MUTUAL
    EOF
    

    Output previsto:

    destinationrule.networking.istio.io/frontend created
  3. Accedi a Boutique online utilizzando l'indirizzo IP esterno del servizio frontend-external e aggiorna la pagina. La pagina non viene visualizzata perché frontend service è impostato su STRICT mTLS e il proxy sidecar blocca la richiesta.

  4. Esegui questo comando per curl il servizio frontend con HTTP normale da un altro pod.

    kubectl exec \
      $(kubectl get pod -l app=productcatalogservice -n product-catalog -o jsonpath={.items..metadata.name}) \
      -c istio-proxy -n product-catalog -- \
      curl http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
    

    La tua richiesta ha esito negativo con il codice di stato 56.

    Se nella console Google Cloud aggiorni la pagina che mostra l'elenco Carichi di lavoro, ora lo stato mTLS per il servizio frontend è Strict e tutti gli altri servizi sono impostati su Permissive.

    l'unico servizio frontend è un mtls fisso

  5. Elimina il criterio di autenticazione:

    kubectl delete peerauthentication -n frontend frontend
    

    Output previsto:

    peerauthentication.security.istio.io "frontend" deleted
    
  6. Elimina la regola di destinazione:

    kubectl delete destinationrule -n frontend frontend
    

    Output previsto:

    destinationrule.networking.istio.io "frontend" deleted
    

Applicazione di mTLS a livello di mesh

Per impedire a tutti i tuoi servizi nel mesh di accettare il traffico di testo non crittografato, imposta un criterio PeerAuthentication a livello di mesh con la modalità mTLS impostata su STRICT. Il criterio PeerAuthentication a livello di mesh non deve avere un selettore e deve essere applicato nello spazio dei nomi principale, istio-system. Quando esegui il deployment del criterio, il piano di controllo esegue automaticamente il provisioning dei certificati TLS in modo che i carichi di lavoro possano autenticarsi l'uno con l'altro.

  1. Applica il protocollo mTLS a livello di mesh:

    kubectl apply -f - <<EOF
    apiVersion: "security.istio.io/v1beta1"
    kind: "PeerAuthentication"
    metadata:
      name: "mesh-wide"
      namespace: "istio-system"
    spec:
      mtls:
        mode: STRICT
    EOF
    

    Output previsto:

    peerauthentication.security.istio.io/mesh-wide created

  2. Accedi a Boutique online utilizzando l'indirizzo IP esterno del servizio frontend-external e aggiorna la pagina. La pagina non viene visualizzata.

  3. Esegui questo comando per curl il servizio frontend con HTTP normale da un altro pod.

    kubectl exec \
      $(kubectl get pod -l app=productcatalogservice -n product-catalog -o jsonpath={.items..metadata.name}) \
      -c istio-proxy -n product-catalog -- \
      curl http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
    

    La tua richiesta ha esito negativo con il codice di stato 56.

  4. Elimina il criterio mesh-wide:

    kubectl delete peerauthentication -n istio-system mesh-wide
    

    Output previsto:

    peerauthentication.security.istio.io "mesh-wide" deleted
    

    Se aggiorni la pagina nella console Google Cloud, vedrai che i dettagli mTLS per tutti i servizi ora mostrano Permissive.

Esegui la pulizia

Per evitare che al tuo Account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.

  • Se vuoi evitare costi aggiuntivi, elimina il cluster:

    gcloud container clusters delete  CLUSTER_NAME  \
        --project=PROJECT_ID \
        --zone=CLUSTER_LOCATION
    
  • Se vuoi mantenere il cluster e rimuovere l'esempio di Boutique online:

    1. Elimina gli spazi dei nomi dell'applicazione:
    kubectl delete -f online-boutique/kubernetes-manifests/namespaces
    

    Output previsto:

    namespace "ad" deleted
    namespace "cart" deleted
    namespace "checkout" deleted
    namespace "currency" deleted
    namespace "email" deleted
    namespace "frontend" deleted
    namespace "loadgenerator" deleted
    namespace "payment" deleted
    namespace "product-catalog" deleted
    namespace "recommendation" deleted
    namespace "shipping" deleted
    
    1. Elimina le voci del servizio:
    kubectl delete -f online-boutique/istio-manifests/allow-egress-googleapis.yaml
    

    Output previsto:

    serviceentry.networking.istio.io "allow-egress-googleapis" deleted
    serviceentry.networking.istio.io "allow-egress-google-metadata" deleted
    

Passaggi successivi