Configurare la sicurezza dei servizi con Envoy

Utilizza le istruzioni in questa guida per configurare l'autenticazione e l'autorizzazione per i servizi di cui è stato eseguito il deployment con Traffic Director e proxy 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:

Prepararsi per la configurazione

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

  • Aggiornamento di Google Cloud CLI
  • Impostazione delle variabili
  • Abilitazione delle API necessarie per il funzionamento di Traffic Director con Certificate Authority Service

Aggiorna lo strumento a riga di comando gcloud

Per aggiornare Google Cloud CLI, esegui il comando seguente sulla macchina locale:

gcloud components update

Imposta le variabili

Imposta le seguenti variabili in modo da poter copiare e incollare il codice con valori coerenti mentre esamini l'esempio in questo documento. Utilizza i seguenti valori.

  • PROJECT_ID: sostituisci l'ID del progetto.
  • CLUSTER_NAME: sostituisci il nome del cluster che vuoi, ad esempio secure-td-cluster.
  • ZONE: sostituisci la zona in cui si trova il cluster. si trova nel tuo cluster.
  • GKE_CLUSTER_URL: sostituisci https://container.googleapis.com/v1/projects/PROJECT_ID/locations/ZONE/clusters/CLUSTER_NAME
  • WORKLOAD_POOL: sostituisci PROJECT_ID.svc.id.goog
  • K8S_NAMESPACE: sostituisci default.
  • DEMO_CLIENT_KSA: sostituisci il nome dell'account di servizio Kubernetes del tuo client.
  • DEMO_SERVER_KSA: sostituisci il nome del tuo server account di servizio Kubernetes.

  • PROJNUM: sostituisci il numero del progetto, che puoi determinare dalla console Google Cloud o con questo comando:

    gcloud projects describe PROJECT_ID --format="value(projectNumber)"

  • SA_GKE: sostituisci service-PROJNUM@container-engine-robot.iam.gserviceaccount.com

  • CLUSTER_VERSION: sostituisci la versione più recente disponibile. Puoi trovare queste informazioni nelle Note di rilascio rapide per il 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 del servizio Traffic Director dipende dall'integrazione di CA Service con GKE. Il cluster GKE deve soddisfare i seguenti requisiti oltre ai requisiti per la configurazione:

  • Utilizza una versione minima del cluster pari a 1.21.4-gke.1801. Se hai bisogno di funzionalità disponibili in una versione successiva, puoi ottenerle tramite il canale di rilascio rapido.
  • Il cluster GKE deve essere abilitato e configurato con certificati mesh, come descritto in Creazione di autorità di certificazione per rilasciare certificati.

  1. Crea un nuovo cluster che utilizza Workload Identity. Se stai aggiornando un cluster esistente, vai al passaggio successivo. Il valore specificato 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

    La creazione del cluster potrebbe richiedere diversi minuti.

  2. Se utilizzi un cluster esistente, attiva i certificati mesh di Workload Identity e 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

  3. Esegui questo comando per passare al nuovo cluster come predefinito per i comandi kubectl:

    gcloud container clusters get-credentials CLUSTER_NAME \
  --zone ZONE

Deployment in un ambiente multi-cluster

Se esegui 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 del server siano in esecuzione nell'altro cluster.

  1. Crea o aggiorna i cluster utilizzando le istruzioni nella sezione precedente.

  2. Acquisisci gli intervalli di indirizzi IP dei pod per ogni cluster utilizzando il seguente comando:

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

    Ad esempio, per i cluster chiamati cluster-a e cluster-b, i comandi restituiscono risultati come segue:

    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

  3. 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 del 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 seguente comando crea una regola firewall che consente agli indirizzi IP del 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 in più progetti.

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

  1. Registra il cluster con il parco risorse:

    gcloud container fleet memberships register CLUSTER_NAME \
  --gke-cluster=ZONE/CLUSTER_NAME \
  --enable-workload-identity --install-connect-agent \
  --manifest-output-file=MANIFEST-FILE_NAME

    Sostituisci le variabili come segue:

    • CLUSTER_NAME: nome del 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 completato il processo di registrazione, viene visualizzato un messaggio simile al seguente:

    Finished registering the cluster CLUSTER_NAME with the fleet.

  2. Applica il file manifest generato al tuo cluster:

    kubectl apply -f MANIFEST-FILE_NAME

    Una volta che il processo di applicazione ha esito positivo, vengono visualizzati messaggi come:

    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

  3. Recupera la risorsa di appartenenza dal cluster:

    kubectl get memberships membership -o yaml

    L'output dovrebbe includere il pool di identità Workoad assegnato dal parco risorse, dove PROJECT_ID è l'ID progetto:

    workload_identity_pool: PROJECT_ID.svc.id.goog

    Ciò significa che il cluster è stato registrato correttamente.

Crea autorità di certificazione per emettere certificati

Per emettere certificati per i tuoi 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 ne hai una. Crea la CA radice nel livello enterprise, l'ideale per l'emissione di certificati a lunga durata e a basso volume.
  • CA subordinato. Questa CA emette certificati per i carichi di lavoro. Crea la CA subordinata nella regione in cui viene eseguito il deployment del cluster. Crea la CA subordinata nel livello devops, pensata per l'emissione di certificati a breve durata e con volumi elevati.

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

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

Le regioni supportate per CA Service sono le seguenti:

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
europe-west10 Berlino
europe-west12 Torino
me-central1 Doha
me-central2 Dammam
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 controllato anche eseguendo questo comando:

gcloud privateca locations list

  1. Concedi il roles/privateca.caManager IAM alle persone che creano un pool di CA e una CA. Tieni presente che per MEMBER, il formato corretto è user:userid@example.com. Se questa persona è l'utente corrente, puoi ottenere l'ID utente corrente con il comando della shell $(gcloud auth list --filter=status:ACTIVE --format="value(account)").

    gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=MEMBER \
  --role=roles/privateca.caManager

  2. Concedi il ruolo role/privateca.admin per CA Service agli utenti che devono modificare i criteri IAM, laddove MEMBER è una persona che necessita di questo accesso, in particolare a tutti coloro che eseguono i passaggi riportati di seguito per concedere i ruoli privateca.auditor e privateca.certificateManager:

    gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=MEMBER \
  --role=roles/privateca.admin

  3. Crea il pool di servizi CA radice.

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

  4. 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"

  5. 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=us-east1
    • SUBORDINATE_CA_NAME="td-ca"
    • SUBORDINATE_CA_organization="TestCorpLLC"
    • ROOT_CA_POOL_NAME=td_sec_pool
    • ROOT_CA_POOL_LOCATION=us-east1

  6. 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"

  7. 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"

  8. Salva la seguente configurazione YAML WorkloadCertificateConfig per indicare al 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 rilascia 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

  9. Salva la seguente configurazione YAML TrustConfig per indicare al 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 principale (ROOT_CA_POOL_URI). Il formato è: 
      //privateca.googleapis.com/projects/PROJECT_ID/locations/ROOT_CA_POOL_LOCATION/caPools/ROOT_CA_POOL_NAME

  10. Applica le configurazioni al 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 (ovvero in altre risorse) le risorse richieste. Se sei l'editor-proprietario del progetto, questo ruolo ti viene assegnato automaticamente.

Tieni presente che networksecurity.googleapis.com.clientTlsPolicies.use e networksecurity.googleapis.com.serverTlsPolicies.use non vengono applicati in modo forzato quando fai riferimento a queste risorse nel servizio di backend.

Se queste autorizzazioni verranno applicate in futuro e utilizzi il ruolo compute.NetworkAdmin, non noterai problemi quando viene applicato questo controllo.

Se utilizzi ruoli personalizzati e questo controllo verrà applicato in modo forzato in futuro, devi assicurarti di includere la rispettiva autorizzazione .use. Altrimenti, in futuro potresti scoprire che il tuo ruolo personalizzato non dispone delle autorizzazioni necessarie per fare riferimento a clientTlsPolicy o serverTlsPolicy dal servizio di backend o dal criterio degli endpoint.

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

  1. Configura IAM per consentire all'account di servizio predefinito di accedere all'API di sicurezza Traffic Director.

    GSA_EMAIL=PROJNUM-compute@developer.gserviceaccount.com

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

  2. Configurare gli account di servizio Kubernetes. I deployment client e server nelle seguenti sezioni utilizzano i Kname degli account server e di servizio client di Kubernetes.

    kubectl create namespace K8S_NAMESPACE
kubectl create serviceaccount --namespace K8S_NAMESPACE DEMO_SERVER_KSA
kubectl create serviceaccount --namespace K8S_NAMESPACE DEMO_CLIENT_KSA

  3. Consenti agli account di servizio Kubernetes di impersonare l'account di servizio Compute Engine predefinito creando un'associazione di criteri IAM tra i due. Questa associazione consente all'account di servizio Kubernetes di agire come 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}

  4. 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

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

Installa l'iniettore collaterale Envoy nel cluster

Segui le istruzioni in entrambe le sezioni seguenti della configurazione di Traffic Director per i pod GKE con inserimento Envoy automatico per eseguire il deployment e abilitare l'inserimento collaterale di Envoy nel tuo cluster:

  • Installazione dell'iniettore sidecar Envoy. Assicurati di configurare il nome del mesh come sidecar-mesh e la rete come "", una stringa vuota.

  • Attivazione dell'inserimento collaterale:

    kubectl label namespace K8S_NAMESPACE istio-injection=enabled

Assicurati di completare entrambi gli insiemi di istruzioni prima di configurare un servizio di test.

Configurare un servizio di prova

Dopo aver installato l'iniettore del sidecar Envoy, utilizza 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 --namespace K8S_NAMESPACE

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

Metadati proxy Traffic Director

podspec specifica l'annotazione proxyMetadata:

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

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

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

Usa chiavi e certificati mesh firmati da CA Service

podspec specifica l'annotazione enableManagedCerts:

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

Quando il pod viene inizializzato, le chiavi e i certificati firmati da CA Service vengono montati automaticamente nel file system del proxy sidecar locale.

Configurazione della porta di intercettazione del traffico in entrata

podspec specifica l'annotazione includeInboundPorts:

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

Questa è la porta sulla quale l'applicazione server rimane in ascolto delle connessioni. 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 inviare nuovamente la configurazione filtrata che intercetta tutto il traffico in entrata verso questa porta e può applicare criteri di sicurezza su questa porta.

La porta per il controllo di integrità deve essere diversa da quella dell'applicazione. In caso contrario, gli stessi criteri di sicurezza verranno applicati alle connessioni in entrata alla porta per il controllo di integrità, il che potrebbe comportare il rifiuto delle connessioni e il conseguente contrassegno erroneamente come non integro del server.

Configurare i servizi GKE con NEG

I servizi GKE devono essere esposti tramite 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 utilizza 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.

Salva il nome del NEG

Salva il nome del NEG nella variabile NEG_NAME:

NEG_NAME="service-test-neg"

Eseguire il deployment di un'applicazione client in GKE

Esegui questo comando per avviare un client dimostrativo con un proxy Envoy come file collaterale, di cui hai bisogno per 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 --namespace K8S_NAMESPACE

Il podspec client include solo l'annotazione enableManagedCerts. Questa operazione è necessaria per montare i volumi necessari per le chiavi e i certificati mesh gestiti da GKE firmati dall'istanza CA Service.

Configura controllo di integrità, regola firewall e risorse del servizio di backend

In questa sezione creerai controllo di integrità, regola firewall e risorse di servizio di backend per Traffic Director.

  1. Crea il controllo di integrità.

    gcloud compute health-checks create http td-gke-health-check \
  --use-serving-port

  2. Crea la regola firewall per consentire gli intervalli di indirizzi IP del controllo di integrità.

    gcloud compute firewall-rules create fw-allow-health-checks \
   --action ALLOW \
   --direction INGRESS \
   --source-ranges 35.191.0.0/16,130.211.0.0/22 \
  --rules tcp

  3. Crea il servizio di backend e associa il controllo di integrità al servizio di backend.

    gcloud compute backend-services create td-gke-service \
  --global \
  --health-checks td-gke-health-check \
  --load-balancing-scheme INTERNAL_SELF_MANAGED

  4. Aggiungi il NEG creato in precedenza come backend al servizio di backend. 

    gcloud compute backend-services add-backend td-gke-service \
  --global \
  --network-endpoint-group ${NEG_NAME} \
  --network-endpoint-group-zone ZONE \
  --balancing-mode RATE \
 --max-rate-per-endpoint 5

Configura risorse Mesh e HTTPRoute

In questa sezione creerai risorse Mesh e HTTPRoute.

  1. Crea la specifica della risorsa Mesh e salvala in un file denominato mesh.yaml.

    name: sidecar-mesh
interceptionPort: 15001

    Per impostazione predefinita, la porta di intercettazione è 15001 se non la specifichi nel file mesh.yaml.

  2. Crea la risorsa Mesh utilizzando la specifica mesh.yaml.

    gcloud network-services meshes import sidecar-mesh \
  --source=mesh.yaml \
  --location=global

  3. Crea la specifica HTTPRoute e salvala in un file denominato http_route.yaml.

    Puoi utilizzare PROJECT_ID o PROJECT_NUMBER.

    name: helloworld-http-route
hostnames:
- service-test
meshes:
- projects/PROJNUM/locations/global/meshes/sidecar-mesh
rules:
- action:
   destinations:
   - serviceName: "projects/PROJNUM/locations/global/backendServices/td-gke-service"

  4. Crea la risorsa HTTPRoute utilizzando la specifica nel file http_route.yaml.

    gcloud network-services http-routes import helloworld-http-route \
  --source=http_route.yaml \
  --location=global

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

Configura la sicurezza tra servizi

Utilizza le istruzioni nelle sezioni seguenti per configurare la sicurezza da un servizio a un altro.

Attiva mTLS nel mesh

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

Formato per i riferimenti ai criteri

Tieni presente il seguente formato obbligatorio per fare riferimento a TLS del server, TLS del client e ai criteri di autorizzazione:

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

Proteggere il traffico in uscita verso il servizio di backend

Per proteggere il traffico in uscita, devi prima creare un criterio TLS del client che:

  • Utilizza google_cloud_private_spiffe come plug-in per clientCertificate, che programma Envoy in modo che utilizzi i 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 del server.

Successivamente, collegherai il criterio TLS del client al servizio di backend. Ecco come:

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

  1. 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

  2. Importa il criterio TLS del client:

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

  3. Collega il criterio TLS del client al servizio di backend. Questa operazione applica 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"

  4. Importa i valori:

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

  5. Facoltativamente, esegui il comando seguente per verificare se la richiesta ha esito negativo. Questo è un errore previsto, perché il client si aspetta certificati dall'endpoint, ma quest'ultimo non è programmato con un criterio di sicurezza.

    # Get the name of the Podrunning Busybox.
BUSYBOX_POD=$(kubectl get po -n K8S_NAMESPACE -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 -n K8S_NAMESPACE $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

    Vedrai un output come il seguente:

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

Proteggere 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 Envoy in modo che utilizzi i 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 del client.

  1. 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

  2. Crea il criterio TLS del server:

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

  3. Crea un file denominato ep_mtls.yaml che contenga il matcher endpoint e allega 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

  4. Importa il matcher dell'endpoint.

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

Convalidare l'impostazione

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

# Get the name of the Podrunning Busybox.
BUSYBOX_POD=$(kubectl get po -n K8S_NAMESPACE -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 -n K8S_NAMESPACE $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

Vedrai un output come il 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 dall'envoy lato server e contiene la propria identità (server) e l'identità del client di origine. Poiché vengono visualizzate sia l'identità client che l'identità 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 criteri di autorizzazione, leggi l'avviso in Limitare l'accesso utilizzando l'autorizzazione.

  1. 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

  2. Importa il criterio:

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

  3. Aggiorna il criterio dell'endpoint per fare riferimento al nuovo criterio di autorizzazione aggiungendo quanto segue al file ep_mtls.yaml:

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

    Il criterio dell'endpoint ora specifica che è necessario applicare sia mTLS sia il criterio di autorizzazione alle richieste in entrata ai pod i cui proxy collaterali Envoy presentano l'etichetta app:payments.

  4. Importa il criterio:

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

Convalidare l'impostazione

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 -n K8S_NAMESPACE $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 i comandi seguenti 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 -n K8S_NAMESPACE $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 sulla sicurezza tra servizi, tra cui la configurazione del cluster GKE con l'autoiniettore sidecar, la creazione di un'autorità di certificazione e di un criterio dell'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 del protocollo TLS su un gateway in entrata (fai clic per ingrandire)
Terminazione di TLS su un gateway in entrata (fai clic per ingrandire)

Per configurare un gateway in entrata per la terminazione di TLS, segui questi passaggi:

  1. Eseguire il deployment di un servizio Kubernetes raggiungibile tramite un indirizzo IP interno del cluster.
    1. Il deployment è costituito da un proxy Envoy autonomo che è esposto come servizio Kubernetes e si connette a Traffic Director.
  2. Crea un criterio TLS del server per terminare TLS.
  3. Crea un criterio di autorizzazione per autorizzare le richieste in entrata.

Esegui il deployment di un servizio gateway in entrata in 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 --namespace K8S_NAMESPACE

Il file gateway_sample.yaml è la specifica per il gateway in entrata. Le seguenti sezioni descrivono alcune aggiunte alle specifiche.

Disattivazione dell'inserimento collaterale di Traffic Director

La specifica gateway_sample.yaml esegue il deployment di un proxy Envoy come unico container. Nei passaggi precedenti, Envoy è stato inserito come file collaterale di un container di applicazioni. Per evitare che più Envoy gestiscano le richieste, puoi disabilitare l'inserimento collaterale 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 collaterale, ma viene aggiunto automaticamente dall'iniettore sidecar quando vede l'annotazione cloud.google.com/enableManagedCerts: "true". Il volume gke-workload-certificates contiene i certificati e le chiavi SPIFFE gestiti da GKE firmati dall'istanza di CA Service 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 la instrada immediatamente alla porta del deployment di Envoy del gateway in entrata 8080.

Attivare TLS su un gateway in entrata

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

  1. 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

  2. Importa il criterio TLS del server:

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

  3. Crea una nuova destinazione Gateway e salvala nel file td-gke-gateway.yaml. Questo collega il criterio TLS del server e configura il gateway di ingresso del proxy Envoy per terminare il traffico TLS in entrata.

    name: td-gke-gateway
scope: gateway-proxy
ports:
- 8080
type: OPEN_MESH
serverTLSPolicy: projects/PROJECT_ID/locations/global/serverTlsPolicies/server-tls-policy

  4. Importa il gateway:

    gcloud network-services gateways import td-gke-gateway \
  --source=td-gke-gateway.yaml \
  --location=global

  5. Crea e salva un nuovo HTTPRoute denominato td-gke-route che fa riferimento al gateway e instrada tutte le richieste a td-gke-service.

    name: td-gke-route
hostnames:
- mesh-gateway
gateways:
- projects/PROJECT_NUMBER/locations/global/gateways/td-gke-gateway
rules:
- action:
    destinations:
    - serviceName: "projects/PROJECT_NUMBER/locations/global/backendServices/td-gke-service"

  6. Importa HTTPRoute:

    gcloud network-services httproutes import td-gke-route \
  --source=td-gke-route.yaml \
  --location=global

  7. Facoltativamente, aggiorna il criterio di autorizzazione sui backend per consentire le richieste quando sono 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 host mesh-gateway o service-test
    • Porta: 8000

    Non è necessario eseguire questi comandi, a meno che tu non abbia configurato un criterio di autorizzazione per i tuoi backend. Se non esistono criteri di autorizzazione sull'endpoint o se non contiene una corrispondenza host o entità di origine nel criterio di autorizzazione, le richieste sono consentite 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

  8. Importa il criterio:

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

Convalida il deployment del gateway in entrata

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

Nella specifica che segue, l'annotazione "sidecar.istio.io/inject":"false" impedisce all'iniettore collaterale di Traffic Director di inserire automaticamente un proxy collaterale. Non esiste un file collaterale che aiuta 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 del server. Il container debug non dispone dei certificati di convalida dell'autorità di certificazione necessari per i certificati validi firmati da CA Service utilizzati dal gateway in entrata per terminare TLS.

In un ambiente di produzione, ti consigliamo di scaricare il certificato di convalida del servizio CA e di montarlo o installarlo sul 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"

Vedrai un output 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 negativo:

# 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"

Vedrai un output simile al seguente:

wget: error getting response: Connection reset by peer

Esegui questo comando di test negativo:

# 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"

Vedrai un output simile al seguente:

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

Elimina il deployment

Facoltativamente, puoi eseguire questi comandi per eliminare il deployment 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 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

Limitazioni

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

Risoluzione dei 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 di Envoy, dove potresti vedere 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 vedi questi errori nel log Envoy, è probabile che il token dell'account di servizio sia montato in modo errato o che stia utilizzando 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 questo problema, consulta Risoluzione dei problemi relativi ai deployment automatici per i pod GKE.

Envoy non autentica con Traffic Director

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

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

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

gcloud components update

###

Se i pod rimangono in stato di attesa durante il processo di configurazione, aumenta le risorse di CPU e memoria per i 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

I pod che utilizzano certificati mesh GKE potrebbero non avviarsi se il provisioning dei certificati non va a buon fine. Questo può accadere in situazioni come le seguenti:

  • WorkloadCertificateConfig o TrustConfig non sono configurati correttamente o non sono presenti.
  • I CSR non vengono approvati.

Per verificare se il provisioning del certificato non va a buon fine, controlla gli eventi dei pod.

  1. Controlla lo stato del pod:

    kubectl get pod -n POD_NAMESPACE POD_NAME

    Sostituisci quanto segue:

    • POD_NAMESPACE: lo spazio dei nomi del pod.
    • POD_NAME: il nome del pod.

  2. Controlla gli eventi recenti per il pod:

    kubectl describe pod -n POD_NAMESPACE POD_NAME

  3. Se il provisioning del certificato non va a buon fine, verrà visualizzato 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 dei problemi.

    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)

  4. Consulta i passaggi per la risoluzione dei problemi riportati di seguito se il motivo per cui i pod non si avviano è imputabile a oggetti configurati in modo errato o CSR rifiutate.

Configurazione errata di WorkloadCertificateConfig o TrustConfig

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

  1. Recupera lo stato attuale.

    Per WorkloadCertificateConfig:

    kubectl get WorkloadCertificateConfig default -o yaml

    Per TrustConfig:

    kubectl get TrustConfig default -o yaml

  2. Esamina 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 visualizzato invece status: "False". I campi reason e message contengono ulteriori dettagli per la risoluzione dei problemi.

I CSR non sono approvati

Se si verifica un problema durante il processo di approvazione della richiesta di firma del prodotto, puoi controllare i dettagli dell'errore nelle condizioni type: Approved e type: Issued della richiesta di firma del certificato.

  1. Elenca le CSR pertinenti utilizzando kubectl:

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

  2. Scegli un CSR che sia Approved e non Issued oppure non sia Approved.

  3. Ottieni i dettagli della CSR selezionata 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

Nei campi message e reason vengono visualizzate informazioni sulla risoluzione dei problemi relativi a richieste di assistenza clienti non valide.

Le applicazioni non possono utilizzare le credenziali mTLS emesse

  1. Verifica che il certificato non sia scaduto:

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

  2. 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

  3. Verifica che la CA emittente utilizzi la stessa famiglia di chiavi della chiave del certificato.

    1. Recupera lo stato dell'istanza CA Service (anteprima):

      gcloud privateca ISSUING_CA_TYPE describe ISSUING_CA_NAME \
  --location ISSUING_CA_LOCATION

      Sostituisci quanto segue:

      • ISSUING_CA_TYPE: il tipo di CA emittente, che deve essere subordinates o roots.
      • ISSUING_CA_NAME: il nome della CA emittente.
      • ISSUING_CA_LOCATION: la regione della CA emittente.

    2. Verifica che keySpec.algorithm nell'output sia lo stesso algoritmo chiave che hai definito nel manifest YAML WorkloadCertificateConfig. L'output sarà simile al seguente:

      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

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

  2. Verifica che il certificato non sia scaduto:

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

  3. Verifica che il codice client, se non utilizza l'API gRPC Go per il ricaricamento delle credenziali, aggiorni periodicamente le credenziali dal file system.

  4. Verifica che i carichi di lavoro si trovino nello stesso dominio di attendibilità dell'autorità di certificazione. I certificati mesh GKE supportano la comunicazione tra carichi di lavoro in un singolo dominio di attendibilità.