Configura la sicurezza del servizio con Envoy

Utilizza le istruzioni riportate in questa guida per configurare l'autenticazione e l'autorizzazione per i servizi di cui è stato eseguito il deployment con proxy Traffic Director e Envoy. Per informazioni complete sulla sicurezza del servizio Traffic Director, consulta Sicurezza del servizio Traffic Director.

Requisiti

Prima di configurare la sicurezza del servizio per Traffic Director con Envoy, assicurati che la configurazione soddisfi i seguenti prerequisiti:

Utilizza Envoy 1.16.4 o versioni successive per l'API xDS v3.
Puoi soddisfare tutti i requisiti per l'implementazione di Traffic Director. Per informazioni complete su questi requisiti, vedi Prepararsi a configurare Traffic Director con Envoy.
Disponi di autorizzazioni sufficienti per creare o aggiornare le risorse mesh di Service Traffic e Google Cloud per utilizzare la sicurezza dei servizi, come descritto nella sezione Preparare la configurazione di Traffic Director con Envoy.

Preparati per la configurazione

Le sezioni seguenti descrivono le attività da completare prima di configurare il servizio di sicurezza Traffic Director. Le attività sono:

Aggiornamento di Google Cloud CLI
Impostare le variabili
Abilitare le API necessarie affinché Traffic Director possa funzionare con Certificate Authority Service

Aggiorna lo strumento a riga di comando `gcloud`

Per aggiornare Google Cloud CLI, esegui quanto segue sulla macchina locale:

gcloud components update

Imposta le variabili

Imposta le variabili seguenti in modo da poter copiare e incollare il codice con valori coerenti, come indicato nell'esempio di questo documento. Utilizza i valori che seguono.

PROJECT_ID: sostituisci l'ID del tuo progetto.
CLUSTER_NAME: sostituisci il nome del cluster che vuoi utilizzare, ad esempio secure-td-cluster.
ZONE: sostituisci la zona in cui si trova il tuo cluster.
GKE_CLUSTER_URL: sostituzione https://container.googleapis.com/v1/projects/PROJECT_ID/locations/ZONE/clusters/CLUSTER_NAME
WORKLOAD_POOL: sostituzione PROJECT_ID.svc.id.goog
K8S_NAMESPACE: sostituisci default.
DEMO_CLIENT_KSA: sostituisci il nome del tuo account di servizio Kubernetes client.
DEMO_SERVER_KSA: sostituisci il nome del tuo account di servizio Kubernetes del server.
PROJNUM: sostituisci il numero del tuo progetto, che puoi determinare dalla console Google Cloud o con questo comando:
```
gcloud projects describe PROJECT_ID --format="value(projectNumber)"
```
SA_GKE: sostituzione service-PROJNUM@container-engine-robot.iam.gserviceaccount.com
CLUSTER_VERSION: sostituisci la versione più recente disponibile. Puoi trovare questa informazione nelle note di rilascio rapide del canale. La versione minima richiesta è 1.21.4-gke.1801. Questa è la versione del cluster GKE da utilizzare in questo esempio.

Imposta i valori qui:

# Substitute your project ID
PROJECT_ID=PROJECT_ID

# GKE cluster name and zone for this example.
CLUSTER_NAME=CLUSTER_NAME
ZONE=ZONE

# GKE cluster URL derived from the above
GKE_CLUSTER_URL="https://container.googleapis.com/v1/projects/PROJECT_ID/locations/ZONE/clusters/CLUSTER_NAME"

# Workload pool to be used with the GKE cluster
WORKLOAD_POOL="PROJECT_ID.svc.id.goog"

# Kubernetes namespace to run client and server demo.
K8S_NAMESPACE=K8S_NAMESPACE
DEMO_CLIENT_KSA=DEMO_CLIENT_KSA
DEMO_SERVER_KSA=DEMO_SERVER_KSA

# Compute other values
# Project number for your project
PROJNUM=PROJNUM

CLUSTER_VERSION=CLUSTER_VERSION
SA_GKE=service-PROJNUM@container-engine-robot.iam.gserviceaccount.com

Abilita le API

Utilizza il comando gcloud services enable per abilitare tutte le API necessarie per configurare la sicurezza di Traffic Director con Certificate Authority Service.

gcloud services enable \
   container.googleapis.com \
   cloudresourcemanager.googleapis.com \
   compute.googleapis.com \
   trafficdirector.googleapis.com \
   networkservices.googleapis.com \
   networksecurity.googleapis.com \
   privateca.googleapis.com \
   gkehub.googleapis.com

Crea o aggiorna un cluster GKE

La sicurezza dei servizi di Traffic Director dipende dall'integrazione del servizio CA con GKE. Il cluster GKE deve soddisfare i seguenti requisiti in aggiunta ai requisiti per la configurazione:

Usa una versione minima del cluster pari a 1.21.4-gke.1801. Se hai bisogno di funzionalità che sono in una versione successiva, puoi ottenerla dal canale di rilascio rapido.
Il cluster GKE deve essere abilitato e configurato con certificati mesh, come descritto nella sezione Creare autorità di certificazione per emettere i certificati.

Creare un nuovo cluster che utilizza Workload Identity. Se stai aggiornando un cluster esistente, vai al passaggio successivo. Il valore fornito per --tags deve corrispondere al nome passato al flag --target-tags per il comando firewall-rules create nella sezione Configurazione di Traffic Director con i componenti di Cloud Load Balancing.

# Create a GKE cluster with GKE managed mesh certificates.
gcloud container clusters create CLUSTER_NAME \
  --release-channel=rapid \
  --scopes=cloud-platform \
  --image-type=cos_containerd \
  --machine-type=e2-standard-2 \
  --zone=ZONE \
  --workload-pool=PROJECT_ID.svc.id.goog \
  --enable-mesh-certificates \
  --cluster-version=CLUSTER_VERSION \
  --enable-ip-alias \
  --tags=allow-health-checks \
  --workload-metadata=GKE_METADATA

Il completamento della creazione del cluster potrebbe richiedere diversi minuti.

Se utilizzi un cluster esistente, attiva Workload Identity e i certificati mesh GKE. Assicurati che il cluster sia stato creato con il flag --enable-ip-alias, che non può essere utilizzato con il comando update.
```
gcloud container clusters update CLUSTER_NAME \
  --enable-mesh-certificates
```
Esegui questo comando per passare al nuovo cluster come cluster predefinito per i tuoi comandi kubectl:
```
gcloud container clusters get-credentials CLUSTER_NAME \
  --zone ZONE
```

Deployment in un ambiente multi-cluster

Se stai eseguendo il deployment in un ambiente multi-cluster, segui la procedura generale descritta in questa sezione. Queste istruzioni presuppongono che i pod client siano in esecuzione in un cluster e che i pod server siano in esecuzione nell'altro cluster.

Crea o aggiorna i cluster seguendo le istruzioni nella sezione precedente.

Acquisisci gli intervalli di indirizzi IP del pod per ciascun cluster utilizzando il comando seguente:

gcloud compute firewall-rules list \
  --filter="name~gke-{CLUSTER_NAME}-[0-9a-z]*-all" \
  --format="value(sourceRanges)"

Ad esempio, per i cluster denominati cluster-a e cluster-b, i comandi restituiscono risultati come i seguenti:

cluster-a, pod CIDR: 10.4.0.0/14, node network tag: gke-cluster-a-9cd18751-node
cluster-b, pod CIDR: 10.8.0.0/14, node network tag: gke-cluster-b-acd14479-node

Creare regole firewall VPC che consentono ai cluster di comunicare tra loro. Ad esempio, il seguente comando crea una regola firewall che consente agli indirizzi IP dei pod cluster-a di comunicare con i nodi cluster-b:
```
gcloud compute firewall-rules create per-cluster-a-pods \
  --allow="tcp,udp,icmp,esp,ah,sctp" \
  --target-tags="gke-cluster-b-acd14479-node"
```
Il comando seguente crea una regola firewall che consente agli indirizzi IP dei pod cluster-b di comunicare con i nodi cluster-a:
```
gcloud compute firewall-rules create per-cluster-b-pods \
  --allow="tcp,udp,icmp,esp,ah,sctp" \
  --target-tags="gke-cluster-a-9cd18751-node"
```

Registra i cluster con un parco risorse

Registra il cluster che hai creato o aggiornato in Creazione di un cluster GKE con un parco risorse. La registrazione del cluster semplifica la configurazione dei cluster su più progetti.

Tieni presente che il completamento di questi passaggi può richiedere fino a dieci minuti.

Registra il cluster con il parco risorse:
```
gcloud container fleet memberships register CLUSTER_NAME \
  --gke-cluster=ZONE/CLUSTER_NAME \
  --enable-workload-identity \
  --manifest-output-file=MANIFEST-FILE_NAME
```
Sostituisci le variabili come indicato di seguito:
- CLUSTER_NAME: il nome del tuo cluster.
- ZONE: la zona del tuo cluster.
- MANIFEST-FILE_NAME: il percorso del file in cui questi comandi generano il manifest per la registrazione.
Una volta completata la registrazione, visualizzerai un messaggio simile al seguente:
```
Finished registering the cluster CLUSTER_NAME with the fleet.
```

Applica il file manifest generato al cluster:

kubectl apply -f MANIFEST-FILE_NAME

Una volta completata la procedura, verranno visualizzati messaggi come i seguenti:

namespace/gke-connect created
serviceaccount/connect-agent-sa created
podsecuritypolicy.policy/gkeconnect-psp created
role.rbac.authorization.k8s.io/gkeconnect-psp:role created
rolebinding.rbac.authorization.k8s.io/gkeconnect-psp:rolebinding created
role.rbac.authorization.k8s.io/agent-updater created
rolebinding.rbac.authorization.k8s.io/agent-updater created
role.rbac.authorization.k8s.io/gke-connect-agent-20210416-01-00 created
clusterrole.rbac.authorization.k8s.io/gke-connect-impersonation-20210416-01-00 created
clusterrolebinding.rbac.authorization.k8s.io/gke-connect-impersonation-20210416-01-00 created
clusterrolebinding.rbac.authorization.k8s.io/gke-connect-feature-authorizer-20210416-01-00 created
rolebinding.rbac.authorization.k8s.io/gke-connect-agent-20210416-01-00 created
role.rbac.authorization.k8s.io/gke-connect-namespace-getter created
rolebinding.rbac.authorization.k8s.io/gke-connect-namespace-getter created
secret/http-proxy created
deployment.apps/gke-connect-agent-20210416-01-00 created
service/gke-connect-monitoring created
secret/creds-gcp create

Recupera la risorsa di appartenenza dal cluster:
```
kubectl get memberships membership -o yaml
```
L'output deve includere il pool di Workoad Identity assegnato dal parco risorse, dove PROJECT_ID è il tuo ID progetto:
```
workload_identity_pool: PROJECT_ID.svc.id.goog
```
Ciò significa che il cluster è stato registrato.

Crea autorità di certificazione per emettere i certificati

Per emettere certificati nei pod, crea un pool di servizi CA e le seguenti autorità di certificazione (CA):

CA radice. Questa è la radice di attendibilità per tutti i certificati mesh emessi. Puoi utilizzare una CA radice esistente, se disponibile. Crea la CA radice nel livello enterprise, che è destinata all'emissione di certificati di lunga durata e a basso volume.
CA subordinata. Questa CA emette certificati per i carichi di lavoro. Crea la CA subordinata nell'area geografica in cui viene eseguito il deployment del cluster. Crea la CA subordinata nel livello devops, che è destinata all'emissione di certificati di breve durata e con volumi elevati.

La creazione di una CA subordinata è facoltativa, ma consigliamo vivamente di crearne una anziché utilizzare la CA radice per emettere i certificati mesh GKE. Se decidi di utilizzare la CA radice per emettere i certificati mesh, assicurati che la modalità di emissione basata sulla configurazione predefinita rimanga consentita.

La CA subordinata può trovarsi in una regione diversa dal tuo cluster, ma consigliamo vivamente di crearla nella stessa regione del cluster per ottimizzare le prestazioni. Tuttavia, puoi creare CA radice e subordinate in aree geografiche diverse senza influire sulle prestazioni o sulla disponibilità.

Queste regioni sono supportate per il servizio CA:

Nome regione	Descrizione regione
`asia-east1`	Taiwan
`asia-east2`	Hong Kong
`asia-northeast1`	Tokyo
`asia-northeast2`	Osaka
`asia-northeast3`	Seul
`asia-south1`	Mumbai
`asia-south2`	Delhi
`asia-southeast1`	Singapore
`asia-southeast2`	Giacarta
`australia-southeast1`	Sydney
`australia-southeast2`	Melbourne
`europe-central2`	Varsavia
`europe-north1`	Finlandia
`europe-southwest1`	Madrid
`europe-west1`	Belgio
`europe-west2`	Londra
`europe-west3`	Francoforte
`europe-west4`	Paesi Bassi
`europe-west6`	Zurigo
`europe-west8`	Milano
`europe-west9`	Parigi
`me-west1`	Tel Aviv
`northamerica-northeast1`	Montréal
`northamerica-northeast2`	Toronto
`southamerica-east1`	San Paolo
`southamerica-west1`	Santiago
`us-central1`	Iowa
`us-east1`	Carolina del Sud
`us-east4`	Virginia del Nord
`us-east5`	Columbus
`us-south1`	Dallas
`us-west1`	Oregon
`us-west2`	Los Angeles
`us-west3`	Salt Lake City
`us-west4`	Las Vegas

L'elenco delle località supportate può essere verificato anche eseguendo questo comando:

gcloud privateca locations list

Concedi l'ID IAM roles/privateca.caManager alle persone che creano un pool di CA e una CA. Tieni presente che per MEMBER il formato corretto è user:userid@example.com. Se quella persona è l'utente corrente, puoi ottenere l'ID utente corrente con il comando shell $(gcloud auth list --filter=status:ACTIVE --format="value(account)").
```
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=MEMBER \
  --role=roles/privateca.caManager
```
Concedi il ruolo role/privateca.admin per il servizio CA alle persone che devono modificare i criteri IAM, dove MEMBER è una persona che ha bisogno di questo accesso, in particolare, chiunque esegua i passaggi seguenti che concedono i ruoli privateca.auditor e privateca.certificateManager:
```
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=MEMBER \
  --role=roles/privateca.admin
```

Crea il pool di servizi CA radice.

gcloud privateca pools create ROOT_CA_POOL_NAME \
  --location ROOT_CA_POOL_LOCATION \
  --tier enterprise

Crea una CA radice.

gcloud privateca roots create ROOT_CA_NAME --pool ROOT_CA_POOL_NAME \
  --subject "CN=ROOT_CA_NAME, O=ROOT_CA_ORGANIZATION" \
  --key-algorithm="ec-p256-sha256" \
  --max-chain-length=1 \
  --location ROOT_CA_POOL_LOCATION

Per questa configurazione dimostrativa, utilizza i seguenti valori per le variabili:

ROOT_CA_POOL_NAME=td_sec_pool
ROOT_CA_NAME=pkcs2-ca
ROOT_CA_POOL_LOCATION=us-east1
ROOT_CA_ORGANIZATION="TestCorpLLC"

Crea il pool subordinato e la CA subordinata. Assicurati che la modalità di emissione basata sulla configurazione predefinita rimanga consentita.

gcloud privateca pools create SUBORDINATE_CA_POOL_NAME \
  --location SUBORDINATE_CA_POOL_LOCATION \
  --tier devops

gcloud privateca subordinates create SUBORDINATE_CA_NAME \
  --pool SUBORDINATE_CA_POOL_NAME \
  --location SUBORDINATE_CA_POOL_LOCATION \
  --issuer-pool ROOT_CA_POOL_NAME \
  --issuer-location ROOT_CA_POOL_LOCATION \
  --subject "CN=SUBORDINATE_CA_NAME, O=SUBORDINATE_CA_ORGANIZATION" \
  --key-algorithm "ec-p256-sha256" \
  --use-preset-profile subordinate_mtls_pathlen_0

Per questa configurazione dimostrativa, utilizza i seguenti valori per le variabili:

SUBORDINATE_CA_POOL_NAME="td-ca-pool"
SUBORDINATE_CA_POOL_LOCATION=it-east1
SUBORDINATE_CA_NAME="td-ca"
SUBORDINATE_CA_ORGANIZATION="TestCorpLLC"
ROOT_CA_POOL_NAME=td_sec_pool
ROOT_CA_POOL_LOCATION=us-east1

Concedi il ruolo IAM privateca.auditor per il pool di CA radice per consentire l'accesso dall'account di servizio GKE:

gcloud privateca pools add-iam-policy-binding ROOT_CA_POOL_NAME \
 --location ROOT_CA_POOL_LOCATION \
 --role roles/privateca.auditor \
 --member="serviceAccount:service-PROJNUM@container-engine-robot.iam.gserviceaccount.com"

Concedi il ruolo IAM privateca.certificateManager per il pool di CA subordinato per consentire l'accesso dall'account di servizio GKE:

gcloud privateca pools add-iam-policy-binding SUBORDINATE_CA_POOL_NAME \
  --location SUBORDINATE_CA_POOL_LOCATION \
  --role roles/privateca.certificateManager \
  --member="serviceAccount:service-PROJNUM@container-engine-robot.iam.gserviceaccount.com"

Salva la seguente configurazione YAML WorkloadCertificateConfig per indicare al tuo cluster come emettere certificati mesh:

apiVersion: security.cloud.google.com/v1
kind: WorkloadCertificateConfig
metadata:
  name: default
spec:
  # Required. The CA service that issues your certificates.
  certificateAuthorityConfig:
    certificateAuthorityServiceConfig:
      endpointURI: ISSUING_CA_POOL_URI

  # Required. The key algorithm to use. Choice of RSA or ECDSA.
  #
  # To maximize compatibility with various TLS stacks, your workloads
  # should use keys of the same family as your root and subordinate CAs.
  #
  # To use RSA, specify configuration such as:
  #   keyAlgorithm:
  #     rsa:
  #       modulusSize: 4096
  #
  # Currently, the only supported ECDSA curves are "P256" and "P384", and the only
  # supported RSA modulus sizes are 2048, 3072 and 4096.
  keyAlgorithm:
    rsa:
      modulusSize: 4096

  # Optional. Validity duration of issued certificates, in seconds.
  #
  # Defaults to 86400 (1 day) if not specified.
  validityDurationSeconds: 86400

  # Optional. Try to start rotating the certificate once this
  # percentage of validityDurationSeconds is remaining.
  #
  # Defaults to 50 if not specified.
  rotationWindowPercentage: 50

Sostituisci quanto segue:

L'ID del progetto in cui viene eseguito il cluster:
```
PROJECT_ID
```
L'URI completo della CA che emette i certificati mesh (ISSUING_CA_POOL_URI). Può essere la tua CA subordinata (consigliata) o la tua CA radice. Il formato è:
```
//privateca.googleapis.com/projects/PROJECT_ID/locations/SUBORDINATE_CA_POOL_LOCATION/caPools/SUBORDINATE_CA_POOL_NAME
```

Salva la seguente configurazione YAML TrustConfig per comunicare al tuo cluster come considerare attendibili i certificati emessi:

apiVersion: security.cloud.google.com/v1
kind: TrustConfig
metadata:
  name: default
spec:
  # You must include a trustStores entry for the trust domain that
  # your cluster is enrolled in.
  trustStores:
  - trustDomain: PROJECT_ID.svc.id.goog
    # Trust identities in this trustDomain if they appear in a certificate
    # that chains up to this root CA.
    trustAnchors:
    - certificateAuthorityServiceURI: ROOT_CA_POOL_URI

Sostituisci quanto segue:

L'ID del progetto in cui viene eseguito il cluster:
```
PROJECT_ID
```

L'URI completo del pool di CA radice (ROOT_CA_POOL_URI). Il formato è:

//privateca.googleapis.com/projects/PROJECT_ID/locations/ROOT_CA_POOL_LOCATION/caPools/ROOT_CA_POOL_NAME

Applica le configurazioni al tuo cluster:

kubectl apply -f WorkloadCertificateConfig.yaml
kubectl apply -f TrustConfig.yaml

Configura Identity and Access Management

Per creare le risorse necessarie per la configurazione, devi avere il ruolo compute.NetworkAdmin. Questo ruolo contiene tutte le autorizzazioni necessarie per creare, aggiornare, eliminare, elencare e utilizzare le risorse richieste. Se sei l'editor proprietario del tuo progetto, questo ruolo viene assegnato automaticamente a te.

Tieni presente che networksecurity.googleapis.com.clientTlsPolicies.use e networksecurity.googleapis.com.serverTlsPolicies.use non vengono applicati quando fai riferimento a queste risorse nel servizio di backend e scegli come target le risorse proxy HTTPS.

Se queste autorizzazioni verranno applicate in futuro e utilizzerai il ruolo compute.NetworkAdmin, non noterai alcun problema durante l'applicazione di questo controllo.

Se utilizzi ruoli personalizzati e questo controllo verrà applicato in futuro, assicurati di includere la rispettiva autorizzazione .use. In caso contrario, in futuro, il tuo ruolo personalizzato potrebbe non disporre delle autorizzazioni necessarie per fare riferimento, rispettivamente, a clientTlsPolicy o serverTlsPolicy del servizio di backend o del proxy HTTPS di destinazione.

Le seguenti istruzioni consentono all'account di servizio predefinito di accedere all'API Traffic Director Security e creare gli account di servizio Kubernetes.

Configurare IAM per consentire all'account di servizio predefinito di accedere all'API Traffic Director Security.

GSA_EMAIL=$(gcloud iam service-accounts list --format='value(email)' \
   --filter='displayName:Compute Engine default service account')

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member serviceAccount:${GSA_EMAIL} \
  --role roles/trafficdirector.client

Configurare gli account di servizio Kubernetes. I deployment client e server nelle seguenti sezioni utilizzano i Kname degli account server e di servizio client Kubernetes.
```
kubectl create serviceaccount --namespace K8S_NAMESPACE DEMO_SERVER_KSA
kubectl create serviceaccount --namespace K8S_NAMESPACE DEMO_CLIENT_KSA
```

Consenti agli account di servizio Kubernetes di impersonare l'account di servizio Compute Engine predefinito creando un'associazione dei criteri IAM tra i due. Questo collegamento consente all'account di servizio Kubernetes di fungere da account di servizio Compute Engine predefinito.

gcloud iam service-accounts add-iam-policy-binding  \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[K8S_NAMESPACE/DEMO_SERVER_KSA]" ${GSA_EMAIL}

gcloud iam service-accounts add-iam-policy-binding  \
  --role roles/iam.workloadIdentityUser  \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[K8S_NAMESPACE/DEMO_CLIENT_KSA]" ${GSA_EMAIL}

Annota gli account di servizio Kubernetes per associarli all'account di servizio Compute Engine predefinito.

kubectl annotate --namespace K8S_NAMESPACE \
  serviceaccount DEMO_SERVER_KSA \
  iam.gke.io/gcp-service-account=${GSA_EMAIL}

kubectl annotate --namespace K8S_NAMESPACE \
  serviceaccount DEMO_CLIENT_KSA \
  iam.gke.io/gcp-service-account=${GSA_EMAIL}

Configura Traffic Director

Segui le istruzioni riportate di seguito per installare l'iniettore sidecar, configurare un servizio di test e completare altre attività di deployment.

Installa l'iniettore sidecar Envoy nel cluster

Usa le istruzioni in entrambe le seguenti sezioni della configurazione di Traffic Director per pod GKE con iniezione automatica di Envoy per eseguire il deployment e l'abilitazione dell'inserimento di sidecar Envoy nel cluster:

Assicurati di completare entrambe le serie di istruzioni prima di configurare un servizio di test.

Configura un servizio di test

Dopo aver installato l'iniettore sidecar Envoy, segui queste istruzioni per configurare un servizio di test per il tuo deployment.

wget -q -O -  https://storage.googleapis.com/traffic-director/security/ga/service_sample.yaml | sed -e s/DEMO_SERVER_KSA_PLACEHOLDER/DEMO_SERVER_KSA/g > service_sample.yaml

kubectl apply -f service_sample.yaml

Il file service_sample.yaml contiene la specifica podspec per l'applicazione del server demo. Esistono alcune annotazioni specifiche per la sicurezza di Traffic Director.

Metadati proxy di Traffic Director

Il podspec specifica l'annotazione proxyMetadata:

spec:
...
      annotations:
        cloud.google.com/proxyMetadata: '{"app": "payments"}'
...

Quando il pod viene inizializzato, il proxy sidecar acquisisce questa annotazione e la trasmette a Traffic Director. Traffic Director può quindi utilizzare queste informazioni per restituire la configurazione filtrata:

Più avanti in questa guida, tieni presente che il criterio dell'endpoint specifica uno strumento di corrispondenza degli endpoint.
Il matcher endpoint specifica che solo i client che presentano un'etichetta con il nome app e il valore payments ricevono la configurazione filtrata.

Usa certificati e chiavi mesh firmati da CA Service

Il podspec specifica l'annotazione enableManagedCerts:

spec:
...
      annotations:
        ...
        cloud.google.com/enableManagedCerts: "true"
...

Quando il pod viene inizializzato, le chiavi e i certificati firmati dal servizio CA vengono montati automaticamente sul file system proxy sidecar.

Configurazione della porta di intercettazione del traffico in entrata

Il podspec specifica l'annotazione includeInboundPorts:

spec:
...
      annotations:
        ...
        cloud.google.com/includeInboundPorts: "8000"
...

Questa è la porta sulla quale la tua applicazione server rimane in ascolto delle connessioni. Quando il pod viene inizializzato, il proxy sidecar raccoglie questa annotazione e la trasmette a Traffic Director. Traffic Director può quindi utilizzare queste informazioni per restituire la configurazione filtrata che intercetta tutto il traffico in entrata verso questa porta e può applicare i criteri di sicurezza.

La porta del controllo di integrità deve essere diversa da quella dell'applicazione. In caso contrario, le stesse norme di sicurezza verranno applicate alle connessioni in entrata verso la porta del controllo di integrità, il che potrebbe causare il rifiuto delle connessioni, con il risultato che il server è erroneamente contrassegnato come in stato non integro.

Configura i servizi GKE con NEG

I servizi GKE devono essere esposti tramite i gruppi di endpoint di rete (NEG) in modo da poterli configurare come backend di un servizio di backend Traffic Director. Il pacchetto service_sample.yaml fornito con questa guida alla configurazione usa il nome NEG service-test-neg nella seguente annotazione:

...
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "service-test-neg"}}}'
spec:
  ports:
  - port: 80
    name: service-test
    protocol: TCP
    targetPort: 8000

Non è necessario modificare il file service_sample.yaml.

Salvataggio del nome NEG

Salva il nome del NEG nella variabile NEG_NAME:

NEG_NAME="service-test-neg"

Esegui il deployment di un'applicazione client in GKE

Esegui questo comando per avviare un client dimostrativo con un proxy Envoy come sidecar, di cui devi dimostrare le funzionalità di sicurezza.

wget -q -O -  https://storage.googleapis.com/traffic-director/security/ga/client_sample.yaml | sed -e s/DEMO_CLIENT_KSA_PLACEHOLDER/DEMO_CLIENT_KSA/g > client_sample.yaml

kubectl apply -f client_sample.yaml

Il podspec client include solo l'annotazione enableManagedCerts. Questo è necessario per montare i volumi necessari per le chiavi e i certificati mesh gestiti da GKE firmati dall'istanza di servizio CA.

Configurare le risorse Google Cloud Traffic Director

Segui i passaggi in Configurare Traffic Director con i componenti di Cloud Load Balancing. Assicurati di verificare che il traffico dal client di esempio sia indirizzato al servizio di esempio.

La configurazione di Traffic Director è completa e ora puoi configurare i criteri di autenticazione e autorizzazione.

Configura la sicurezza da servizio a servizio

Segui le istruzioni riportate nelle sezioni seguenti per configurare la sicurezza da servizio a servizio.

Attiva mTLS nel mesh

Per configurare mTLS nel mesh, devi proteggere il traffico in uscita verso il servizio di backend e il traffico in entrata sicuro verso l'endpoint.

Formato per i riferimenti ai criteri

Prendi nota del seguente formato obbligatorio per fare riferimento ai criteri TLS, server client e autorizzazione del server:

projects/PROJECT_ID/locations/global/[serverTlsPolicies|clientTlsPolicies|authorizationPolicies]/[server-tls-policy|client-mtls-policy|authz-policy]

Ad esempio:

projects/PROJECT_ID/locations/global/serverTlsPolicies/server-tls-policy

projects/PROJECT_ID/locations/global/clientTlsPolicies/client-mtls-policy

projects/PROJECT_ID/locations/global/authorizationPolicies/authz-policy

Proteggi il traffico in uscita verso il servizio di backend

Per proteggere il traffico in uscita, crea innanzitutto un criterio TLS client che:

Utilizza google_cloud_private_spiffe come plug-in per clientCertificate, che programma l'utilizzo di certificati mesh gestiti da GKE come identità client.
Utilizza google_cloud_private_spiffe come plug-in per serverValidationCa che programma Envoy per utilizzare i certificati mesh gestiti da GKE per la convalida dei server.

Successivamente, collegherai il criterio TLS del client al servizio di backend. In questo modo:

Applica il criterio di autenticazione dal criterio TLS del client alle connessioni in uscita agli endpoint del servizio di backend.
SAN (Subject Alternative Names) indica al client di dichiarare l'esatta identità del server a cui si connette.

Crea il criterio TLS del client in un file client-mtls-policy.yaml:

name: "client-mtls-policy"
clientCertificate:
  certificateProviderInstance:
    pluginInstance: google_cloud_private_spiffe
serverValidationCa:
- certificateProviderInstance:
    pluginInstance: google_cloud_private_spiffe

Importa il criterio TLS del client:

gcloud network-security client-tls-policies import client-mtls-policy \
    --source=client-mtls-policy.yaml --location=global

Collega il criterio TLS del client al servizio di backend. Viene applicata l'autenticazione mTLS su tutte le richieste in uscita dal client a questo servizio di backend.

gcloud compute backend-services export td-gke-service \
    --global --destination=demo-backend-service.yaml

Aggiungi le seguenti righe a demo-backend-service.yaml:

securitySettings:
  clientTlsPolicy: projects/PROJECT_ID/locations/global/clientTlsPolicies/client-mtls-policy
  subjectAltNames:
    - "spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_SERVER_KSA"

Importa i valori:

gcloud compute backend-services import td-gke-service \
    --global --source=demo-backend-service.yaml

Se vuoi, esegui questo comando per verificare se la richiesta ha esito negativo. Si tratta di un errore previsto, perché il client prevede i certificati dall'endpoint, ma l'endpoint non è programmato con un criterio di sicurezza.

# Get the name of the Podrunning Busybox.
BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}')

# Command to execute that tests connectivity to the service service-test.
TEST_CMD="wget -q -O - service-test; echo"

# Execute the test command on the pod.
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

L'output sarà simile al seguente:

wget: server returned error: HTTP/1.1 503 Service Unavailable

Proteggi il traffico in entrata verso l'endpoint

Per proteggere il traffico in entrata, devi prima creare un criterio TLS del server che:

Utilizza google_cloud_private_spiffe come plug-in per serverCertificate, che programma l'utilizzo di certificati mesh gestiti da GKE come identità del server.
Utilizza google_cloud_private_spiffe come plug-in per clientValidationCa, che programma Envoy in modo che utilizzi i certificati mesh gestiti da GKE per la convalida dei client.

Salva i valori del criterio TLS del server in un file denominato server-mtls-policy.yaml.

name: "server-mtls-policy"
serverCertificate:
  certificateProviderInstance:
    pluginInstance: google_cloud_private_spiffe
mtlsPolicy:
  clientValidationCa:
  - certificateProviderInstance:
      pluginInstance: google_cloud_private_spiffe

Crea il criterio TLS del server:

gcloud network-security server-tls-policies import server-mtls-policy \
    --source=server-mtls-policy.yaml --location=global

Creare un file denominato ep_mtls.yaml contenente il matcher endpoint e collegare il criterio TLS del server.

endpointMatcher:
  metadataLabelMatcher:
    metadataLabelMatchCriteria: MATCH_ALL
    metadataLabels:
    - labelName: app
      labelValue: payments
name: "ep"
serverTlsPolicy: projects/PROJECT_ID/locations/global/serverTlsPolicies/server-mtls-policy
type: SIDECAR_PROXY

Importa il matcher endpoint.

gcloud network-services endpoint-policies import ep \
    --source=ep_mtls.yaml --location=global

Convalidare la configurazione

Esegui questo comando curl. Se la richiesta viene completata correttamente, vedrai x-forwarded-client-cert nell'output. L'intestazione viene stampata solo quando la connessione è una connessione mTLS.

# Get the name of the Podrunning Busybox.
BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}')

# Command to execute that tests connectivity to the service service-test.
TEST_CMD="wget -q -O - service-test; echo"

# Execute the test command on the pod.
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

Vedrai un output simile al seguente:

GET /get HTTP/1.1
Host: service-test
content-length: 0
x-envoy-internal: true
accept: */*
x-forwarded-for: 10.48.0.6
x-envoy-expected-rq-timeout-ms: 15000
user-agent: curl/7.35.0
x-forwarded-proto: http
x-request-id: redacted
x-forwarded-client-cert: By=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_SERVER_KSA;Hash=Redacted;Subject="Redacted;URI=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_CLIENT_KSA

Tieni presente che l'intestazione x-forwarded-client-cert viene inserita dal server lato server e contiene la propria identità (server) e l'identità del client di origine. Siccome vediamo sia l'identità client che quella del server, questo è un segnale di una connessione mTLS.

Configurare l'accesso al livello di servizio con un criterio di autorizzazione

Queste istruzioni creano un criterio di autorizzazione che consente le richieste inviate dall'account DEMO_CLIENT_KSA in cui il nome host è service-test, la porta è 8000 e il metodo HTTP è GET. Prima di creare i criteri di autorizzazione, leggi la sezione riportata di seguito all'articolo Limitare l'accesso utilizzando l'autorizzazione.

Crea un criterio di autorizzazione creando un file denominato authz-policy.yaml.

action: ALLOW
name: authz-policy
rules:
- sources:
  - principals:
    - spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_CLIENT_KSA
  destinations:
  - hosts:
    - service-test
    ports:
    - 8000
    methods:
    - GET

Importa il criterio:

gcloud network-security authorization-policies import authz-policy \
  --source=authz-policy.yaml \
  --location=global

Aggiorna il criterio dell'endpoint in modo che faccia riferimento al nuovo criterio di autorizzazione aggiungendo al file ep_mtls.yaml quanto segue:
```
authorizationPolicy: projects/PROJECT_ID/locations/global/authorizationPolicies/authz-policy
```
Il criterio endpoint ora specifica che sia mTLS sia il criterio di autorizzazione devono essere applicati alle richieste in entrata nei pod i cui proxy sidecar Envoy presentano l'etichetta app:payments.

Importa il criterio:

gcloud network-services endpoint-policies import ep \
    --source=ep_mtls.yaml --location=global

Convalidare la configurazione

Esegui questi comandi per convalidare la configurazione.

# Get the name of the Podrunning Busybox.
BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}')

# Command to execute that tests connectivity to the service service-test.
# This is a valid request and will be allowed.
TEST_CMD="wget -q -O - service-test; echo"

# Execute the test command on the pod.
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

L'output previsto è simile a questo:

GET /get HTTP/1.1
Host: service-test
content-length: 0
x-envoy-internal: true
accept: */*
x-forwarded-for: redacted
x-envoy-expected-rq-timeout-ms: 15000
user-agent: curl/7.35.0
x-forwarded-proto: http
x-request-id: redacted
x-forwarded-client-cert: By=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_SERVER_KSA;Hash=Redacted;Subject="Redacted;URI=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_CLIENT_KSA

Esegui questi comandi per verificare se il criterio di autorizzazione rifiuta correttamente le richieste non valide:

# Failure case
# Command to execute that tests connectivity to the service service-test.
# This is an invalid request and server will reject because the server
# authorization policy only allows GET requests.
TEST_CMD="wget -q -O - service-test --post-data='' ; echo"

# Execute the test command on the pod.
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

L'output previsto è simile a questo:

<RBAC: access denied HTTP/1.1 403 Forbidden>

Configura la sicurezza del gateway in entrata

Questa sezione presuppone che tu abbia completato la sezione relativa alla sicurezza tra i servizi, inclusa la configurazione del cluster GKE con l'iniettore automatico sidecar, la creazione di un'autorità di certificazione e la creazione di un criterio endpoint.

In questa sezione, eseguirai il deployment di un proxy Envoy come gateway in entrata che termina le connessioni TLS e autorizza le richieste dai client interni di un cluster.

Terminazione di TLS su un gateway in entrata (fai clic per ingrandire)

Per configurare un gateway in entrata in modo che termini TLS, procedi nel seguente modo:

Esegui il deployment di un servizio Kubernetes raggiungibile utilizzando un indirizzo IP interno del cluster.
1. Il deployment consiste in un proxy Envoy autonomo che viene esposto come servizio Kubernetes e si connette a Traffic Director.
Crea un criterio TLS del server per terminarlo.
Crea un criterio di autorizzazione per autorizzare le richieste in arrivo.

Esegui il deployment di un servizio gateway in entrata su GKE

Esegui questo comando per eseguire il deployment del servizio gateway in entrata su GKE:

wget -q -O -  https://storage.googleapis.com/traffic-director/security/ga/gateway_sample_xdsv3.yaml | sed -e s/PROJECT_NUMBER_PLACEHOLDER/PROJNUM/g | sed -e s/NETWORK_PLACEHOLDER/default/g | sed -e s/DEMO_CLIENT_KSA_PLACEHOLDER/DEMO_CLIENT_KSA/g > gateway_sample.yaml

kubectl apply -f gateway_sample.yaml

Il file gateway_sample.yaml è la specifica del gateway in entrata. Le seguenti sezioni descrivono alcune aggiunte alla specifica.

Disabilitazione dell'iniezione di sidecar Traffic Director

La specifica gateway_sample.yaml esegue il deployment di un proxy Envoy come unico container. Nei passaggi precedenti, Envoy è stato inserito come sidecar in un container dell'applicazione. Per evitare che più richieste Envoy gestiscano le richieste, puoi disabilitare l'inserimento di sidecar per questo servizio Kubernetes utilizzando la seguente istruzione:

sidecar.istio.io/inject: "false"

Monta il volume corretto

La specifica gateway_sample.yaml monta il volume gke-workload-certificates. Questo volume viene utilizzato anche nel deployment delle sidecar, ma viene aggiunto automaticamente dall'iniettore del sidecar quando vede l'annotazione cloud.google.com/enableManagedCerts: "true". Il volume gke-workload-certificates contiene le chiavi e le chiavi SPIFFE gestite da GKE che sono firmate dall'istanza di servizio CA che hai configurato.

Imposta l'indirizzo IP interno del cluster

Configura il gateway in entrata con un servizio di tipo ClusterInternal. Viene creato un nome host DNS risolvibile internamente per mesh-gateway. Quando un client invia una richiesta a mesh-gateway:443, Kubernetes inoltra immediatamente la richiesta alla porta del deployment Envoy del gateway in entrata 8080.

Abilita TLS su un gateway in entrata

Segui queste istruzioni per abilitare TLS su un gateway in entrata.

Crea una risorsa del criterio TLS del server per terminare le connessioni TLS, con i valori in un file denominato server-tls-policy.yaml:

description: tls server policy
name: server-tls-policy
serverCertificate:
  certificateProviderInstance:
    pluginInstance: google_cloud_private_spiffe

Importa il criterio TLS del server:

gcloud network-security server-tls-policies import server-tls-policy \
    --source=server-tls-policy.yaml --location=global

Crea una nuova mappa URL che instrada tutte le richieste al servizio di backend td-gke-service. Il gateway in entrata gestisce le richieste in entrata e le invia ai pod che appartengono al servizio di backend td-gke-service.
```
gcloud compute url-maps create td-gke-ig-url-map \
   --default-service=td-gke-service
```

Creare un nuovo proxy HTTPS di destinazione nel file td-gke-https-proxy.yaml e collegare la mappa URL creata in precedenza e il criterio TLS del server. Questo permette di configurare il gateway in entrata del proxy Envoy per terminare il traffico TLS in entrata.

kind: compute#targetHttpsProxy
name: td-gke-https-proxy
proxyBind: true
urlMap: https://www.googleapis.com/compute/beta/projects/PROJECT_ID/global/urlMaps/td-gke-ig-url-map
serverTlsPolicy: projects/PROJECT_ID/locations/global/serverTlsPolicies/server-tls-policy

Importa il criterio:

gcloud compute target-https-proxies import td-gke-https-proxy \
   --global --source=td-gke-https-proxy.yaml

Crea una nuova regola di forwarding e collega il proxy HTTPS di destinazione. Questo permette di configurare il proxy Envoy per l'ascolto sulla porta 8080 e di applicare i criteri di routing e sicurezza definiti in td-gke-https-proxy.
```
gcloud compute forwarding-rules create td-gke-gateway-forwarding-rule --global \
  --load-balancing-scheme=INTERNAL_SELF_MANAGED --address=0.0.0.0 \
  --target-https-proxy=td-gke-https-proxy --ports 8080 \
  --network default
```
Facoltativamente, aggiorna il criterio di autorizzazione sui backend per consentire le richieste quando vengono soddisfatte tutte le seguenti condizioni:
- Richieste inviate da DEMO_CLIENT_KSA. (il deployment del gateway in entrata utilizza l'account di servizio DEMO_CLIENT_KSA).
- Richieste con l'host mesh-gateway o service-test
- Porta: 8000
Non è necessario eseguire questi comandi se non hai configurato un criterio di autorizzazione per i tuoi backend. Se nel criterio di autorizzazione non è presente alcun criterio di autorizzazione o se non contiene una corrispondenza di host o origine nel criterio di autorizzazione, la richiesta è consentita senza questo passaggio. Aggiungi questi valori a authz-policy.yaml.
```
action: ALLOW
name: authz-policy
rules:
- sources:
  - principals:
    - spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_CLIENT_KSA
  destinations:
  - hosts:
    - service-test
    - mesh-gateway
    ports:
    - 8000
    methods:
    - GET
```

Importa il criterio:

gcloud network-security authorization-policies import authz-policy \
  --source=authz-policy.yaml \
  --location=global

Convalidare il deployment del gateway in entrata

Utilizzerai un nuovo container denominato debug per inviare richieste al gateway in entrata per convalidare il deployment.

Nella seguente specifica, l'annotazione "sidecar.istio.io/inject":"false" impedisce all'iniettore del sidecar Traffic Director di inserire automaticamente un proxy sidecar. Non esiste un file collaterale per aiutare il container debug nel routing delle richieste. Il container deve connettersi al gateway in entrata per il routing.

La specifica include il flag --no-check-certificate, che ignora la convalida dei certificati server. Il container debug non dispone dei certificati di convalida dell'autorità di certificazione necessari per i certificati validi firmati dal servizio CA utilizzati dal gateway in entrata per terminare TLS.

In un ambiente di produzione, consigliamo di scaricare il certificato di convalida del servizio CA e montarlo o installarlo sul tuo client. Dopo aver installato il certificato di convalida, rimuovi l'opzione --no-check-certificate del comando wget.

Esegui questo comando:

kubectl run -i --tty --rm debug --image=busybox --restart=Never  --overrides='{ "metadata": {"annotations": { "sidecar.istio.io/inject":"false" } } }'  -- /bin/sh -c "wget --no-check-certificate -qS -O - https://mesh-gateway; echo"

L'output visualizzato è simile al seguente:

GET / HTTP/1.1
Host: 10.68.7.132
x-forwarded-client-cert: By=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_SERVER_KSA;Hash=Redacted;Subject="Redacted;URI=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_CLIENT_KSA
x-envoy-expected-rq-timeout-ms: 15000
x-envoy-internal: true
x-request-id: 5ae429e7-0e18-4bd9-bb79-4e4149cf8fef
x-forwarded-for: 10.64.0.53
x-forwarded-proto: https
content-length: 0
user-agent: Wget

Esegui questo comando di test escluso:

# Negative test
# Expect this to fail because gateway expects TLS.
kubectl run -i --tty --rm debug --image=busybox --restart=Never  --overrides='{ "metadata": {"annotations": { "sidecar.istio.io/inject":"false" } } }'  -- /bin/sh -c "wget --no-check-certificate -qS -O - http://mesh-gateway:443/headers; echo"

L'output visualizzato è simile al seguente:

wget: error getting response: Connection reset by peer

Esegui questo comando di test escluso:

# Negative test.
# AuthorizationPolicy applied on the endpoints expect a GET request. Otherwise
# the request is denied authorization.
kubectl run -i --tty --rm debug --image=busybox --restart=Never  --overrides='{ "metadata": {"annotations": { "sidecar.istio.io/inject":"false" } } }'  -- /bin/sh -c "wget --no-check-certificate -qS -O - https://mesh-gateway --post-data=''; echo"

L'output visualizzato è simile al seguente:

HTTP/1.1 403 Forbidden
wget: server returned error: HTTP/1.1 403 Forbidden

Configurazione di un criterio di autorizzazione per il gateway in entrata

Il criterio di autorizzazione impostato qui consente al gateway in entrata di consentire le richieste nel mesh quando vengono soddisfatte tutte le seguenti condizioni:

Host: mesh-gateway
Porta: 8080
percorso: *
Metodo HTTP GET

Crea un criterio di autorizzazione nel file authz-gateway-policy.yaml:

action: ALLOW
name: authz-gateway-policy
rules:
- destinations:
  - hosts:
    - mesh-gateway
    ports:
    - 8080
    methods:
    - GET

Importa i valori nel file:

gcloud network-security authorization-policies import authz-gateway-policy \
   --source=authz-gateway-policy.yaml  --location=global

Modifica il file td-gke-https-proxy.yaml aggiungendolo:

authorizationPolicy: projects/PROJECT_ID/locations/global/authorizationPolicies/authz-gateway-policy

Importa di nuovo il file td-gke-https-proxy.yaml:

gcloud compute target-https-proxies import td-gke-https-proxy \
   --global --source=td-gke-https-proxy.yaml

Convalidare il deployment

Esegui questo comando per convalidare il tuo deployment.

# On your localhost.
kubectl run -i --tty --rm debug --image=busybox --restart=Never  --overrides='{ "metadata": {"annotations": { "sidecar.istio.io/inject":"false" } } }'  -- /bin/sh -c "wget --no-check-certificate -qS -O - https://mesh-gateway; echo"

L'output visualizzato è simile al seguente:

GET / HTTP/1.1
Host: 35.196.50.2
x-forwarded-client-cert: By=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_SERVER_KSA;Hash=Redacted;Subject="Redacted;URI=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_CLIENT_KSA
x-envoy-expected-rq-timeout-ms: 15000
user-agent: curl/7.72.0
x-forwarded-proto: https
content-length: 0
x-envoy-internal: true
x-request-id: 98bec135-6df8-4082-8edc-b2c23609295a
accept: */*
x-forwarded-for: 10.142.0.7

Esegui questo comando di test escluso:

# Negative test. Expect failure because only POST method is allowed by \
# authz-gateway-policy
kubectl run -i --tty --rm debug --image=busybox --restart=Never  --overrides='{ "metadata": {"annotations": { "sidecar.istio.io/inject":"false" } } }'  -- /bin/sh -c "wget --no-check-certificate -qS -O - https://mesh-gateway/ --post-data=''; echo"

L'output visualizzato è simile al seguente:

wget: server returned error: HTTP/1.1 403 Forbidden

Elimina il deployment

Facoltativamente, puoi eseguire questi comandi per eliminare il deployment che hai creato utilizzando questa guida.

Per eliminare il cluster, esegui questo comando:

gcloud container clusters delete CLUSTER_NAME --zone ZONE --quiet

Per eliminare le risorse che hai creato, esegui questi comandi:

gcloud compute forwarding-rules delete td-gke-forwarding-rule --global --quiet
gcloud compute forwarding-rules delete td-gke-gateway-forwarding-rule --global \
    --quiet
gcloud compute target-http-proxies delete td-gke-proxy  --quiet
gcloud compute target-https-proxies delete td-gke-https-proxy  --quiet
gcloud compute url-maps delete td-gke-url-map  --quiet
gcloud compute url-maps delete td-gke-ig-url-map  --quiet
gcloud compute backend-services delete td-gke-service --global --quiet
cloud compute network-endpoint-groups delete service-test-neg --zone ZONE --quiet
gcloud compute firewall-rules delete fw-allow-health-checks --quiet
gcloud compute health-checks delete td-gke-health-check --quiet
gcloud network-services endpoint-policies delete ep \
    --location=global --quiet
gcloud network-security authorization-policies delete authz-gateway-policy \
   --location=global --quiet
gcloud network-security authorization-policies delete authz-policy \
    --location=global --quiet
gcloud network-security client-tls-policies delete client-mtls-policy \
    --location=global --quiet
gcloud network-security server-tls-policies delete server-tls-policy \
    --location=global --quiet
gcloud network-security server-tls-policies delete server-mtls-policy \
    --location=global --quiet

Risolvere i problemi

Questa sezione contiene informazioni su come risolvere i problemi riscontrati durante la configurazione del servizio di sicurezza.

Errori di connessione

Se la connessione non riesce e restituisce un errore upstream connect o disconnect/reset before headers, esamina i log Envoy, dove potresti visualizzare uno dei seguenti messaggi di log:

gRPC config stream closed: 5, Requested entity was not found

gRPC config stream closed: 2, no credential token is found

Se visualizzi questi errori nel log di Envoy, è probabile che il token dell'account di servizio sia montato in modo errato o utilizzi un audience diverso o entrambi.

Per ulteriori informazioni, consulta I messaggi di errore nei log Envoy indicano un problema di configurazione.

Pod non creati

Per risolvere il problema, consulta Risoluzione dei problemi relativi ai deployment automatici per i pod GKE.

Envoy non esegue l'autenticazione con Traffic Director

Quando Envoy (envoy-proxy) si connette a Traffic Director per recuperare la configurazione di xDS, utilizza Workload Identity (WI) e l'account di servizio VM di Compute Engine (a meno che il bootstrap non sia stato modificato). Se l'autenticazione ha esito negativo, Envoy non passa allo stato Pronto.

Impossibile creare un cluster con `--workload-identity-certificate-authority flag`

Se visualizzi questo errore, assicurati di eseguire la versione più recente di Google Cloud CLI:

gcloud components update

###

Se i pod rimangono in attesa durante la procedura di configurazione, aumenta le risorse CPU e di memoria dei pod nella specifica del deployment.

Impossibile creare il cluster con il flag `--enable-mesh-certificates`

Assicurati di eseguire l'ultima versione di gcloud CLI:

gcloud components update

Tieni presente che il flag --enable-mesh-certificates funziona solo con gcloud beta.

I pod non si avviano

L'avvio dei pod che utilizzano i certificati mesh GKE potrebbe non riuscire se il provisioning del certificato non va a buon fine. Questo può accadere in situazioni come le seguenti:

WorkloadCertificateConfig o TrustConfig sono configurati in modo errato o mancanti.
I CSR non vengono approvati.

Puoi controllare se il provisioning del certificato ha esito negativo controllando gli eventi del pod.

Controlla lo stato del pod:
```
kubectl get pod -n POD_NAMESPACE POD_NAME
```
Sostituisci quanto segue:
- POD_NAMESPACE: lo spazio dei nomi del tuo pod.
- POD_NAME: il nome del pod.

Controlla gli eventi recenti per il tuo pod:

kubectl describe pod -n POD_NAMESPACE POD_NAME

Se il provisioning del certificato non va a buon fine, vedrai un evento con Type=Warning, Reason=FailedMount, From=kubelet e un campo Message che inizia con MountVolume.SetUp failed for volume "gke-workload-certificates". Il campo Message contiene informazioni per la risoluzione del problema.

Events:
  Type     Reason       Age                From       Message
  ----     ------       ----               ----       -------
  Warning  FailedMount  13s (x7 over 46s)  kubelet    MountVolume.SetUp failed for volume "gke-workload-certificates" : rpc error: code = Internal desc = unable to mount volume: store.CreateVolume, err: unable to create volume "csi-4d540ed59ef937fbb41a9bf5380a5a534edb3eedf037fe64be36bab0abf45c9c": caPEM is nil (check active WorkloadCertificateConfig)

Se il motivo per cui i pod non si avviano è dovuto a oggetti configurati in modo errato o a causa di CSR rifiutati, consulta la procedura di risoluzione dei problemi riportata di seguito.

`WorkloadCertificateConfig` o `TrustConfig` sono configurati in modo errato

Assicurati di aver creato correttamente gli oggetti WorkloadCertificateConfig e TrustConfig. Puoi diagnosticare gli errori di configurazione su entrambi gli oggetti utilizzando kubectl.

Recupera lo stato attuale.

Per WorkloadCertificateConfig:

kubectl get WorkloadCertificateConfig default -o yaml

Per TrustConfig:

kubectl get TrustConfig default -o yaml

Controlla l'output dello stato. Un oggetto valido avrà una condizione con type: Ready e status: "True".
```
status:
  conditions:
  - lastTransitionTime: "2021-03-04T22:24:11Z"
    message: WorkloadCertificateConfig is ready
    observedGeneration: 1
    reason: ConfigReady
    status: "True"
    type: Ready
```
Per gli oggetti non validi, viene invece visualizzato status: "False". I campi reason e message contengono ulteriori dettagli per la risoluzione dei problemi.

CSR non approvati

Se si verifica un problema durante la procedura di approvazione del CSR, puoi controllare i dettagli dell'errore nelle condizioni type: Approved e type: Issued del CSR.

Elenca i CSR pertinenti utilizzando kubectl:

kubectl get csr \
  --field-selector='spec.signerName=spiffe.gke.io/spiffe-leaf-signer'

Scegli un CSR che sia Approved e non Issued o non sia Approved.
Ottieni i dettagli per il CSR selezionato utilizzando kubectl:
```
kubectl get csr CSR_NAME -o yaml
```
Sostituisci CSR_NAME con il nome del CSR che hai scelto.

Un CSR valido ha una condizione con type: Approved e status: "True" e un certificato valido nel campo status.certificate:

status:
  certificate: <base64-encoded data>
  conditions:
  - lastTransitionTime: "2021-03-04T21:58:46Z"
    lastUpdateTime: "2021-03-04T21:58:46Z"
    message: Approved CSR because it is a valid SPIFFE SVID for the correct identity.
    reason: AutoApproved
    status: "True"
    type: Approved

Le informazioni per la risoluzione dei problemi relativi ai CSR non validi vengono visualizzate nei campi message e reason.

Le applicazioni non possono utilizzare le credenziali mTLS emesse

Verifica che il certificato non sia scaduto:

cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -text -noout | grep "Not After"

Verifica che il tipo di chiave utilizzato sia supportato dalla tua applicazione.

cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -text -noout | grep "Public Key Algorithm" -A 3

Verifica che la CA emittente utilizzi la stessa famiglia di chiavi della chiave del certificato.
1. Verifica lo stato dell'istanza del servizio CA (Anteprima):
```
gcloud privateca ISSUING_CA_TYPE describe ISSUING_CA_NAME \
  --location ISSUING_CA_LOCATION
```
  Sostituisci quanto segue:
  - ISSUING_CA_TYPE: il tipo CA emittente, che deve essere subordinates o roots.
  - ISSUING_CA_NAME: il nome della CA emittente.
  - ISSUING_CA_LOCATION: l'area geografica della CA emittente.
2. Verifica che keySpec.algorithm nell'output corrisponda allo stesso algoritmo della chiave definito nel manifest YAML WorkloadCertificateConfig. L'output ha il seguente aspetto:
```
config:
  ...
  subjectConfig:
    commonName: td-sub-ca
    subject:
      organization: TestOrgLLC
    subjectAltName: {}
createTime: '2021-05-04T05:37:58.329293525Z'
issuingOptions:
  includeCaCertUrl: true
keySpec:
  algorithm: RSA_PKCS1_2048_SHA256
 ...
```

I certificati vengono rifiutati

Verifica che l'applicazione peer utilizzi lo stesso bundle di attendibilità per verificare il certificato.

Verifica che il certificato non sia scaduto:

cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -text -noout | grep "Not After"

Verifica che il codice client, se non utilizzi l'API Credentials Reload di gRPC, aggiorna periodicamente le credenziali dal file system.
Verifica che i carichi di lavoro si trovino nello stesso dominio di attendibilità della CA. I certificati mesh GKE supportano la comunicazione tra carichi di lavoro in un singolo dominio trust.

Configura la sicurezza del servizio con Envoy

Requisiti

Preparati per la configurazione

Aggiorna lo strumento a riga di comando gcloud

Imposta le variabili

Abilita le API

Crea o aggiorna un cluster GKE

Deployment in un ambiente multi-cluster

Registra i cluster con un parco risorse

Crea autorità di certificazione per emettere i certificati

Configura Identity and Access Management

Configura Traffic Director

Installa l'iniettore sidecar Envoy nel cluster

Configura un servizio di test

Metadati proxy di Traffic Director

Usa certificati e chiavi mesh firmati da CA Service

Configurazione della porta di intercettazione del traffico in entrata

Configura i servizi GKE con NEG

Salvataggio del nome NEG

Esegui il deployment di un'applicazione client in GKE

Configurare le risorse Google Cloud Traffic Director

Configura la sicurezza da servizio a servizio

Attiva mTLS nel mesh

Formato per i riferimenti ai criteri

Proteggi il traffico in uscita verso il servizio di backend

Proteggi il traffico in entrata verso l'endpoint

Convalidare la configurazione

Configurare l'accesso al livello di servizio con un criterio di autorizzazione

Convalidare la configurazione

Configura la sicurezza del gateway in entrata

Esegui il deployment di un servizio gateway in entrata su GKE

Disabilitazione dell'iniezione di sidecar Traffic Director

Monta il volume corretto

Imposta l'indirizzo IP interno del cluster

Abilita TLS su un gateway in entrata

Convalidare il deployment del gateway in entrata

Configurazione di un criterio di autorizzazione per il gateway in entrata

Convalidare il deployment

Elimina il deployment

Risolvere i problemi

Errori di connessione

Pod non creati

Envoy non esegue l'autenticazione con Traffic Director

Impossibile creare un cluster con --workload-identity-certificate-authority flag

Impossibile creare il cluster con il flag --enable-mesh-certificates

I pod non si avviano

WorkloadCertificateConfig o TrustConfig sono configurati in modo errato

CSR non approvati

Le applicazioni non possono utilizzare le credenziali mTLS emesse

I certificati vengono rifiutati

Aggiorna lo strumento a riga di comando `gcloud`

Impossibile creare un cluster con `--workload-identity-certificate-authority flag`

Impossibile creare il cluster con il flag `--enable-mesh-certificates`

`WorkloadCertificateConfig` o `TrustConfig` sono configurati in modo errato