Configura la sicurezza dei servizi con Envoy

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

Requisiti

Prima di configurare la sicurezza dei servizi per Cloud Service Mesh con Envoy, esegui assicurati che la tua configurazione soddisfi i seguenti prerequisiti:

• Puoi soddisfare tutti i requisiti per il deployment di Cloud Service Mesh. Per informazioni complete su questi requisiti, consulta Prepararsi alla configurazione delle API di routing dei servizi con Envoy e carichi di lavoro senza proxy.

• Disponi di autorizzazioni sufficienti per creare o aggiornare Cloud Service Mesh e Risorse mesh di servizi Google Cloud per utilizzare la sicurezza del servizio, come descritto in Prepararsi alla configurazione delle API di routing dei servizi con Envoy e carichi di lavoro senza proxy.

Prepararsi alla configurazione

Le sezioni seguenti descrivono le attività da completare prima di configurare il servizio di sicurezza Cloud Service Mesh. Queste attività sono:

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

Aggiorna lo strumento a riga di comando gcloud

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

gcloud components update

Configurare le variabili

Imposta le seguenti variabili in modo da poter copiare e incollare il codice con valori coerenti man mano che esamini l'esempio in questo documento. Utilizza quanto segue e i relativi valori.

• PROJECT_ID: sostituisci l'ID del tuo 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. in cui si trova il cluster.
• GKE_CLUSTER_URL: sostitutivo 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 del cliente l'account di servizio Kubernetes.
• DEMO_SERVER_KSA: sostituisci il nome del server l'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 [e-mail]

• CLUSTER_VERSION: sostituisci la versione più recente disponibili. Puoi trovarlo nelle note di rilascio del canale rapido. 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=[e-mail]

Abilita le API

Utilizza il comando gcloud services enable per attivare tutte le API necessarie per configurare la sicurezza di Cloud Service Mesh 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 Cloud Service Mesh 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 1.21.4-gke.1801. Se hai bisogno di funzionalità sono in una versione successiva, la puoi ottenere dalla release rapida canale.
• Il cluster GKE deve essere abilitato e configurato con i certificati mesh, come descritto in Creare autorità di certificazione per emettere certificati.

1. Crea un nuovo cluster che utilizzi la federazione delle identità per i carichi di lavoro per GKE. Se stai aggiornando una 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 Cloud Service Mesh con i componenti di bilanciamento del carico di Cloud.

   # 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 la federazione delle identità per i carichi di lavoro per GKE e i certificati GKE Mesh. 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 cluster predefinito per i tuoi 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 le procedura descritta in questa sezione. Queste istruzioni presuppongono che i pod client siano in esecuzione in un cluster e i pod server nell'altro cluster.

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

2. Acquisisci gli intervalli di indirizzi IP dei pod per ogni cluster utilizzando quanto segue :

   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 restituiranno 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
   

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 in 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 dieci minuti ciascuno.

1. Registra il cluster nel 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 in questo modo:

   • CLUSTER_NAME: il nome del cluster.
   • ZONE: la zona del tuo cluster.
   • MANIFEST-FILE_NAME: il percorso in cui questi comandi generare il manifest per la registrazione.

   Al termine del processo di registrazione, viene visualizzato un messaggio come seguenti:

   Finished registering the cluster CLUSTER_NAME with the fleet.

2. Applica al cluster il file manifest generato:

   kubectl apply -f MANIFEST-FILE_NAME
   

   Quando la procedura di richiesta va a buon fine, vengono 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
   

3. Recupera la risorsa di appartenenza dal cluster:

   kubectl get memberships membership -o yaml
   

   L'output deve includere il pool Workload Identity 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.

Creare autorità di certificazione per emettere certificati

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

• CA radice. Si tratta della 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, progettato per l'emissione di certificati di lunga durata e a basso volume.
• CA subordinata. Questa CA emette certificati per i carichi di lavoro. Crea il nella regione in cui è stato eseguito il deployment del cluster. Crea la CA subordinata nel livello devops, progettato per l'emissione di certificati di breve durata e ad alto volume.

La creazione di una CA subordinata è facoltativa, ma ti consigliamo vivamente di crearne una anziché utilizzare la CA radice per emettere i certificati del mesh GKE. Se di utilizzare la CA radice per emettere certificati mesh, accertati che modalità di emissione basata sulla configurazione predefinita rimangono consentite.

La CA secondaria 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 le CA principali e secondarie in regioni diverse senza alcun impatto sul rendimento o sulla disponibilità.

Il servizio CA è supportato per le seguenti regioni:

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

Puoi controllare l'elenco delle località supportate anche eseguendo questo comando :

gcloud privateca locations list

1. Concedi roles/privateca.caManager IAM a singoli utenti che creano un pool di CA e una CA. Tieni presente che per MEMBER, il formato corretto è user:[e-mail]. Se questa 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
   

2. 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 a tutte le persone che eseguono i passaggi che seguono 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 di dimostrazione, 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 l'impostazione predefinita modalità di emissione basata sulla configurazione rimangono consentite.

   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 di dimostrazione, 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 a consenti 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:[e-mail]"
   

7. Concedi il ruolo IAM privateca.certificateManager per il pool CA secondario 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:[e-mail]"
   

8. Salva la seguente configurazione YAML WorkloadCertificateConfig per come emettere certificati mesh per il tuo cluster:

   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 dell'autorità di certificazione che emette i certificati mesh (ISSUING_CA_POOL_URI). Può essere la CA subordinata (opzione consigliata) o la CA principale. 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 per 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

10. Applica le configurazioni al cluster:

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

Configurare Identity and Access Management

Per creare le risorse richieste per la configurazione, devi disporre Ruolo compute.NetworkAdmin. Questo ruolo contiene tutte le autorizzazioni necessarie creare, aggiornare, eliminare, elencare e utilizzare (ovvero, ci si riferisce a questo risorse) le risorse richieste. Se sei l'editor proprietario del progetto, questo ruolo viene assegnato automaticamente.

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

Se queste autorizzazioni vengono applicate in futuro e utilizzi il ruolo compute.NetworkAdmin, non noterai alcun problema quando verrà applicato questo controllo.

Se utilizzi ruoli personalizzati e questo controllo viene applicato in futuro, devi assicurarti di includere la rispettiva autorizzazione .use. In caso contrario, 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 dalle norme relative agli endpoint.

Le istruzioni riportate di seguito consentono all'account di servizio predefinito di accedere all'API Cloud Service Mesh Security e di creare gli account di servizio Kubernetes.

1. Configura IAM per consentire all'account di servizio predefinito di accedere l'API Cloud Service Mesh 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
   

2. Configura gli account di servizio Kubernetes. I deployment di client e server Nelle sezioni seguenti vengono usati i Kname del server e del client Kubernetes account di servizio.

   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 Compute Engine predefinito un account di servizio creando un'associazione di criteri IAM tra i due. Questo consente all'account di servizio Kubernetes di agire come Account di servizio Compute Engine.

   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 predefinito Account di servizio Compute Engine.

   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 Cloud Service Mesh

Usa le seguenti istruzioni per installare l'iniettore collaterale, configura un test e completare altre attività di deployment.

Installa l'iniettore sidecar Envoy nel cluster

Segui le istruzioni riportate in entrambe le sezioni seguenti della configurazione di Cloud Service Mesh per i pod GKE con l'iniezione automatica di Envoy per eseguire il deployment e attivare l'iniezione di sidecar Envoy nel cluster:

• Installazione dell'iniettore sidecar di Envoy. Assicurati di configurare il nome della mesh come sidecar_mesh e la rete come "", una stringa vuota.
• Attivazione dell'inserimento di file collaterali

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

Configurare un servizio di test

Dopo aver installato l'iniettore collaterale di 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

Il file service_sample.yaml contiene il podspec per il server demo un'applicazione. Esistono alcune annotazioni specifiche di Cloud Service Mesh sicurezza.

Metadati proxy Cloud Service Mesh

Il file podspec specifica l'annotazione proxyMetadata:

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

Quando il pod viene inizializzato, il proxy sidecar raccoglie questa annotazione e la trasmette a Cloud Service Mesh. Cloud Service Mesh può quindi utilizzare informazioni per inviare la configurazione filtrata:

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

Utilizza i certificati mesh e le chiavi firmati da CA Service

Podspec specifica l'annotazione enableManagedCerts:

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

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

Configurare la porta di intercettazione del traffico in entrata

Podspec specifica l'annotazione includeInboundPorts:

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

Questa è la porta su cui l'applicazione server è in ascolto per le connessioni. Quando del pod viene inizializzato, il proxy sidecar raccoglie questa annotazione e trasmette in Cloud Service Mesh. Cloud Service Mesh può quindi utilizzare queste informazioni per inviare nuovamente la configurazione filtrata che intercetta tutto il traffico in entrata su questa porta e può applicare criteri di sicurezza.

La porta del controllo di integrità deve essere diversa dalla porta dell'applicazione. Altrimenti, gli stessi criteri di sicurezza si applicheranno alle connessioni in entrata controlla la porta che potrebbe comportare il rifiuto delle connessioni e, di conseguenza, il server è erroneamente contrassegnato come non integro.

Configurare i servizi GKE con i NEG

I servizi GKE devono essere esposti tramite gruppi di endpoint di rete (NEG) in modo da poterli configurare come backend di un backend Cloud Service Mesh completamente gestito di Google Cloud. 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

La specifica pod del client include solo l'annotazione enableManagedCerts. Questo è necessaria per montare i volumi necessari per il mesh gestito da GKE e chiavi firmati dall'istanza di servizio CA.

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

In questa sezione, crei risorse di controllo di integrità, regole firewall e servizi di backend per Cloud Service Mesh.

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 di 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 del 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 le risorse Mesh e HTTPRoute

In questa sezione dovrai creare le risorse Mesh e HTTPRoute.

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

   name: sidecar-mesh
   interceptionPort: 15001
   

   La porta di intercettazione è impostata su 15001 per impostazione predefinita se non la specifichi nel mesh.yaml file.

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 http_route.yaml file.

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

La configurazione di Cloud Service Mesh è stata completata e ora puoi configurarla di autenticazione e autorizzazione.

Configurare la sicurezza tra servizi

Utilizza le istruzioni nelle sezioni seguenti per configurare l'attributo service-to-service sicurezza.

Attiva mTLS nella rete mesh

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

Formato per i riferimenti alle norme

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

Proteggi il traffico in uscita verso il servizio di backend

Per proteggere il traffico in uscita, crea innanzitutto un criterio TLS del client che svolga quanto segue:

• Usa google_cloud_private_spiffe come plug-in per clientCertificate, quale programma Envoy per utilizzare i certificati mesh gestiti da GKE. come identità client.
• Usa google_cloud_private_spiffe come plug-in per serverValidationCa quale programma Envoy per utilizzare i certificati mesh gestiti da GKE. per la convalida del server.

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

• Applica il criterio di autenticazione del criterio TLS del client alle connessioni in uscita agli endpoint del servizio di backend.
• SAN (Subject Alternative Name) indica al client di affermare l'esatto e l'identità 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. In questo modo 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"
   

4. Importa i valori:

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

5. Facoltativamente, esegui questo comando per verificare se la richiesta non riesce. Si tratta di un errore previsto, perché il client si aspetta 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"
   

   Vedrai un output simile al 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, crea innanzitutto un criterio TLS del server che svolga quanto segue:

• Utilizza google_cloud_private_spiffe come plug-in per serverCertificate, che programma Envoy per utilizzare i certificati mesh gestiti da GKE come identità del server.
• Utilizza google_cloud_private_spiffe come plug-in per clientValidationCa, che programma Envoy per utilizzare i certificati mesh gestiti da GKE per la convalida del client.

1. Salva i valori dei criteri 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 contenente il corrispettivo dell'endpoint e alliga 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 corrispettivo dell'endpoint.

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

Convalida la configurazione

Esegui questo comando curl. Se la richiesta viene completata correttamente, vedi x-forwarded-client-cert nell'output. L'intestazione viene stampata solo quando La 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"

Viene visualizzato 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 da Envoy lato server e contiene la propria identità (server) e l'identità del client di origine. Poiché si vedono sia l'identità client che l'identità del server, questo è un segnale di una connessione mTLS.

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

Queste istruzioni creano un criterio di autorizzazione che consente le richieste vengono inviati dall'account DEMO_CLIENT_KSA in cui il nome host è service-test, la porta è 8000 e il metodo HTTP è GET. Prima di per creare criteri di autorizzazione, leggi l'attenzione Limitare l'accesso tramite 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 sia mTLS sia il criterio di autorizzazione devono essere applicati alle richieste in entrata ai pod i cui proxy sidecar Envoy presentano l'etichetta app:payments.

4. Importa il criterio:

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

Convalida la configurazione

Esegui i seguenti 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 al seguente:

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 seguenti 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 al seguente:

<RBAC: access denied HTTP/1.1 403 Forbidden>

Configura i criteri di autorizzazione sui sidecar su GKE

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Questa sezione mostra come configurare diversi tipi di criteri di autorizzazione nei sidecar di Cloud Service Mesh su GKE.

Prima di poter creare un criterio di autorizzazione, devi installare la risorsa personalizzata CustomResourceDefinition (CRD) GCPAuthzPolicy:

curl https://github.com/GoogleCloudPlatform/gke-networking-recipes/blob/main/gateway-api/config/mesh/crd/experimental/gcpauthzpolicy.yaml \
| kubectl apply -f -

Criterio di autorizzazione per rifiutare le richieste

Quando hai un carico di lavoro che dovrebbe effettuare solo chiamate in uscita, ad esempio cron job, puoi configurare un criterio di autorizzazione per rifiutare qualsiasi HTTP richieste al carico di lavoro. L'esempio seguente nega le richieste HTTP in entrata a il carico di lavoro example-app.

Per creare e applicare il criterio di autorizzazione di rifiuto:

1. Crea un criterio personalizzato creando un file denominato deny-all-authz-policy.yaml:

   cat >deny-all-authz-policy.yaml <<EOF
   apiVersion: networking.gke.io/v1
   kind: GCPAuthzPolicy
   metadata:
     name: my-workload-authz
     namespace: ns1
   spec:
   targetRefs:
   - kind: Deployment
     name: example-app
   httpRules:
   - to:
       operations:
       - paths:
         - type: Prefix
           value: "/"
   action: DENY
   EOF
   

2. Applica il criterio:

   kubectl apply -f deny-all-authz-policy.yaml
   

Criterio di autorizzazione per consentire le richieste

Puoi anche configurare un criterio di autorizzazione che consenta solo le richieste che soddisfano criteri specifici e ne rifiuti le altre. L'esempio seguente configura un criterio di autorizzazione sul deployment example-app per consentire solo richieste mTLS dai pod con l'identità spiffee://cluster.local/ns1/pod1.

Per creare e applicare il criterio di autorizzazione Consenti:

1. Crea un criterio personalizzato creando un file denominato allow-authz-policy.yaml:

   cat >allow-authz-policy.yaml <<EOF
   apiVersion: networking.gke.io/v1
   kind: GCPAuthzPolicy
   metadata:
     name: my-workload-authz
     namespace: ns1
   spec:
   targetRefs:
   - kind: Deployment
     name: example-app
   httpRules:
   - from:
       sources:
       - principals:
         - type: Exact
           value: "spiffee://cluster.local/ns1/pod1"
   action: ALLOW
   EOF
   

2. Applica il criterio:

   kubectl apply -f allow-authz-policy.yaml
   

Configura la sicurezza del gateway in entrata

Questa sezione presuppone che tu abbia completato la sezione sulla sicurezza tra servizi, incluso il setup del cluster GKE con l'autoiniettore sidecar, la creazione di un'autorità di certificazione e di un criterio endpoint.

In questa sezione, esegui il deployment di un proxy Envoy come gateway di ingresso che termina le connessioni TLS e autorizza le richieste dei client interni di un cluster.

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

Per configurare un gateway di ingresso per terminare TLS:

1. Esegui il deployment di un servizio Kubernetes raggiungibile utilizzando un indirizzo IP interno del cluster.
   1. Il deployment è costituito da un proxy Envoy autonomo esposto come servizio Kubernetes e connesso a Cloud Service Mesh.
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 il seguente comando per eseguire il deployment del servizio gateway di ingresso 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 di ingresso. Le sezioni seguenti descrivono alcune aggiunte alle specifiche.

Disattivazione dell'inserimento collaterale di Cloud Service Mesh

La specifica gateway_sample.yaml esegue il deployment di un proxy Envoy come unico contenitore. Nella passaggi precedenti, Envoy è stato inserito come file collaterale di un container di applicazioni. Per evitare che più Envoy gestiscano le richieste, puoi disattivare l'iniezione 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 per il deployment di sidecar, ma viene aggiunto automaticamente dall'iniettore sidecar quando vede l'annotazionecloud.google.com/enableManagedCerts: "true". gke-workload-certificates contiene i certificati e le chiavi SPIFFE gestiti da GKE firmati di CA Service che hai configurato.

Impostare l'indirizzo IP interno del cluster

Configura il gateway in entrata con un servizio di tipo ClusterInternal. In questo modo viene creato un nome host DNS risolvibile internamente per mesh-gateway. Quando un client invia una richiesta a mesh-gateway:443, Kubernetes instrada immediatamente la richiesta 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 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 un nuovo target Gateway e salvalo nel file td-gke-gateway.yaml. Questo collega il criterio TLS del server e configura il gateway di accesso al 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 il 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 il HTTPRoute:

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

7. Facoltativamente, aggiorna i criteri di autorizzazione nei backend per consentire le richieste se 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'autorizzazione per i tuoi backend. Se non è presente un criterio di autorizzazione nell'endpoint o non contiene la corrispondenza dell'host o dell'entità di origine 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

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

Nella specifica seguente, l'annotazione "sidecar.istio.io/inject":"false" mantiene l'iniettore collaterale di Cloud Service Mesh affinché inserisca automaticamente un file collaterale proxy. Non è presente un sidecar per aiutare il contenitore debug nel routing delle richieste. Il contenitore deve connettersi al gateway di ingresso per il routing.

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

In un ambiente di produzione, ti consigliamo di scaricare il servizio CA certificato di convalida e montarlo o installarlo il cliente. 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 a questo:

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 il seguente 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"

Verrà visualizzato 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"

Verrà visualizzato 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 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 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 Cloud Service Mesh è 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 viene restituito un errore upstream connect o disconnect/reset before headers, esamina i log di Envoy, dove potresti visualizzare uno di i 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 di Envoy, è probabile che il servizio il token dell'account è stato montato in modo errato o sta utilizzando un altro audience, oppure entrambi.

Per ulteriori informazioni, consulta Messaggi di errore nei log di Envoy che indicano un problema di configurazione.

Pod non creati

Per risolvere questo problema, consulta Risoluzione dei problemi dei deployment automatici per i pod GKE.

Envoy non si autentica con Cloud Service Mesh

Quando Envoy (envoy-proxy) si connette a Cloud Service Mesh per recuperare la configurazione xDS, utilizza la federazione delle identità per i carichi di lavoro per GKE e l'account di servizio predefinito della VM Compute Engine (a meno che il bootstrap non sia stato modificato). Se l'autenticazione non riesce, Envoy non passa allo stato di pronto.

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

Se viene visualizzato questo errore, assicurati che sia in esecuzione la versione più recente di Google Cloud CLI:

gcloud components update

I pod rimangono in stato di attesa

Se i pod rimangono in stato di attesa durante il processo di configurazione, aumenta il Risorse di CPU e memoria per i pod nella specifica del deployment.

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

Assicurati di utilizzare la versione più recente della CLI gcloud:

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 del mesh GKE potrebbe non riuscire se il provisioning dei certificati non va a buon fine. Ciò può accadere in situazioni come le seguenti:

• WorkloadCertificateConfig o TrustConfig non sono configurati correttamente o mancante.
• Le RP non vengono approvate.

Puoi verificare se il provisioning del certificato non è andato a buon fine controllando il pod eventi.

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 del tuo pod:

   kubectl describe pod -n POD_NAMESPACE POD_NAME
   

3. Se il provisioning del certificato non riesce, 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 seguenti passaggi per la risoluzione dei problemi se i pod non si avviano a causa di oggetti configurati in modo errato o di CSR rifiutate.

La configurazione di WorkloadCertificateConfig o TrustConfig non è corretta

Assicurati di aver creato correttamente gli oggetti WorkloadCertificateConfig e TrustConfig. Puoi diagnosticare le configurazioni errate su 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. Controlla l'output dello stato. Un oggetto valido avrà una condizione 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 campireasone message contengono ulteriori dettagli sulla risoluzione dei problemi.

I CSR non sono approvati

Se si verificano problemi durante la procedura di approvazione di CSR, puoi controllare l'errore dettagli nelle condizioni type: Approved e type: Issued della richiesta di firma del certificato.

1. Elenca i 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. Visualizza 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

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

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. Visualizza lo stato del servizio CA (anteprima) istanza:

      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 di chiave che hai definito nel WorkloadCertificateConfig manifest YAML. L'output è il 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 di ricaricamento delle credenziali gRPC Go, aggiorni periodicamente le credenziali dal file system.

4. Verifica che i tuoi carichi di lavoro si trovino nello stesso dominio attendibile della CA. I certificati del mesh GKE supportano la comunicazione tra i carichi di lavoro in un singolo dominio attendibile.