Configurare la sicurezza del servizio con Envoy
Utilizza le istruzioni riportate in questa guida per configurare l'autenticazione e l'autorizzazione per i servizi di cui è stato eseguito il deployment con Cloud Service Mesh e 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 del servizio per Cloud Service Mesh con Envoy, assicurati che la 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 Google Cloud risorse service mesh per utilizzare la sicurezza del servizio, come descritto in Preparati a configurare le API di routing del servizio con Envoy e carichi di lavoro senza proxy.
Prepararsi alla configurazione
Le sezioni seguenti descrivono le attività che devi completare prima di configurare il servizio di sicurezza Cloud Service Mesh. Queste attività sono:
- Aggiornamento di Google Cloud CLI
- Configurazione delle variabili
- Abilitazione delle API necessarie per il funzionamento di Cloud Service Mesh con Certificate Authority Service
Aggiorna lo strumento a riga di comando gcloud
Per aggiornare Google Cloud CLI, esegui il seguente comando 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 mentre esegui l'esempio in questo documento. Utilizza i seguenti valori.
- PROJECT_ID: Sostituisci l'ID del tuo progetto.
- CLUSTER_NAME: sostituisci il nome del cluster che vuoi
utilizzare, ad esempio
secure-td-cluster
. - ZONE: sostituisci la zona in cui si trova il cluster.
- GKE_CLUSTER_URL: Substitute
https://container.googleapis.com/v1/projects/PROJECT_ID/locations/ZONE/clusters/CLUSTER_NAME
- WORKLOAD_POOL: Substitute
PROJECT_ID.svc.id.goog
- K8S_NAMESPACE: Substitute
default
. - DEMO_CLIENT_KSA: sostituisci il nome del tuo account di servizio Kubernetes client.
- DEMO_SERVER_KSA: Sostituisci il nome dell'account di servizio Kubernetes del server.
PROJNUM: sostituisci il numero di progetto del tuo progetto, che puoi determinare dalla console Google Cloud o con questo comando:
gcloud projects describe PROJECT_ID --format="value(projectNumber)"
SA_GKE: Substitute
service-PROJNUM@container-engine-robot.iam.gserviceaccount.com
CLUSTER_VERSION: sostituisci la versione più recente disponibile. Puoi trovare questa informazione 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=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 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 a quelli per la configurazione:
- Utilizza una versione del cluster minima di 1.21.4-gke.1801. Se hai bisogno di funzionalità presenti in una versione successiva, puoi ottenere questa versione dal canale di rilascio rapido.
- Il cluster GKE deve essere abilitato e configurato con i certificati mesh, come descritto in Creazione di autorità di certificazione per l'emissione di certificati.
Crea un nuovo cluster che utilizzi la federazione delle identità per i carichi di lavoro per GKE. Se stai aggiornando un cluster esistente, vai al passaggio successivo. Il valore che fornisci per
--tags
deve corrispondere al nome passato al flag--target-tags
per il comandofirewall-rules create
nella sezione Configurazione di Cloud Service Mesh con Cloud Load Balancing 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.
Se utilizzi un cluster esistente, attiva la federazione delle identità per i carichi di lavoro per GKE e i certificati mesh GKE. Assicurati che il cluster sia stato creato con il flag
--enable-ip-alias
, che non può essere utilizzato con il comandoupdate
.gcloud container clusters update CLUSTER_NAME \ --enable-mesh-certificates
Esegui questo comando per passare al nuovo cluster come cluster 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 i pod server siano in esecuzione nell'altro cluster.
Crea o aggiorna i cluster seguendo le istruzioni della sezione precedente.
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 denominati
cluster-a
ecluster-b
, i comandi restituiscono risultati come i seguenti:cluster-a, pod CIDR: 10.4.0.0/14, node network tag: gke-cluster-a-9cd18751-node cluster-b, pod CIDR: 10.8.0.0/14, node network tag: gke-cluster-b-acd14479-node
Crea regole firewall VPC che consentano ai cluster di comunicare tra loro. Ad esempio, il seguente comando crea una regola firewall che consente agli indirizzi IP dei pod
cluster-a
di comunicare con i nodicluster-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 dei pod
cluster-b
di comunicare con i nodicluster-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 ciascuno di questi passaggi può richiedere fino a 10 minuti.
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 tuo cluster.
- ZONE: la zona del cluster.
- MANIFEST-FILE_NAME: il percorso in cui questi comandi generano il manifest per la registrazione.
Al termine della procedura di registrazione, viene visualizzato un messaggio simile al seguente:
Finished registering the cluster CLUSTER_NAME with the fleet.
Applica il file manifest generato al tuo cluster:
kubectl apply -f MANIFEST-FILE_NAME
Se la procedura di richiesta ha esito positivo, vengono visualizzati messaggi come il seguente:
namespace/gke-connect created serviceaccount/connect-agent-sa created podsecuritypolicy.policy/gkeconnect-psp created role.rbac.authorization.k8s.io/gkeconnect-psp:role created rolebinding.rbac.authorization.k8s.io/gkeconnect-psp:rolebinding created role.rbac.authorization.k8s.io/agent-updater created rolebinding.rbac.authorization.k8s.io/agent-updater created role.rbac.authorization.k8s.io/gke-connect-agent-20210416-01-00 created clusterrole.rbac.authorization.k8s.io/gke-connect-impersonation-20210416-01-00 created clusterrolebinding.rbac.authorization.k8s.io/gke-connect-impersonation-20210416-01-00 created clusterrolebinding.rbac.authorization.k8s.io/gke-connect-feature-authorizer-20210416-01-00 created rolebinding.rbac.authorization.k8s.io/gke-connect-agent-20210416-01-00 created role.rbac.authorization.k8s.io/gke-connect-namespace-getter created rolebinding.rbac.authorization.k8s.io/gke-connect-namespace-getter created secret/http-proxy created deployment.apps/gke-connect-agent-20210416-01-00 created service/gke-connect-monitoring created secret/creds-gcp create
Recupera la risorsa di appartenenza dal cluster:
kubectl get memberships membership -o yaml
L'output deve includere il pool di identità del workload assegnato dal parco progetti, dove PROJECT_ID è l'ID progetto:
workload_identity_pool: PROJECT_ID.svc.id.goog
Ciò significa che la registrazione del cluster è riuscita.
Crea autorità di certificazione per emettere certificati
Per emettere certificati per i tuoi pod, crea un pool CA Service 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
, che è destinato all'emissione di certificati di lunga durata e a basso volume. - CA subordinata. Questa CA emette certificati per i carichi di lavoro. Crea la CA
subordinata nella regione in cui è implementato il cluster. Crea la CA
subordinata nel livello
devops
, che è destinato all'emissione di certificati di breve durata e in grandi volumi.
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 sulla configurazione predefinita rimanga consentita.
La CA subordinata può trovarsi in una regione diversa dal cluster, ma consigliamo vivamente di crearla nella stessa regione del cluster per ottimizzare le prestazioni. Tuttavia, puoi creare le CA radice e subordinate in regioni diverse senza alcun impatto su prestazioni o disponibilità.
Queste regioni sono supportate per CA Service:
Nome regione | Descrizione della 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
Concedi il ruolo IAM
roles/privateca.caManager
alle persone che creano un pool di CA e una CA. Tieni presente che per MEMBER il formato corretto èuser:userid@example.com
. Se questa persona è l'utente attuale, puoi ottenere l'ID utente attuale con il comando shell$(gcloud auth list --filter=status:ACTIVE --format="value(account)")
.gcloud projects add-iam-policy-binding PROJECT_ID \ --member=MEMBER \ --role=roles/privateca.caManager
Concedi il ruolo
role/privateca.admin
per CA Service alle persone che devono modificare i criteri IAM, doveMEMBER
è una persona che ha bisogno di questo accesso, in particolare, qualsiasi persona che esegue i passaggi successivi che concedono i ruoliprivateca.auditor
eprivateca.certificateManager
:gcloud projects add-iam-policy-binding PROJECT_ID \ --member=MEMBER \ --role=roles/privateca.admin
Crea il pool di CA radice del servizio CA.
gcloud privateca pools create ROOT_CA_POOL_NAME \ --location ROOT_CA_POOL_LOCATION \ --tier enterprise
Crea una CA radice.
gcloud privateca roots create ROOT_CA_NAME --pool ROOT_CA_POOL_NAME \ --subject "CN=ROOT_CA_NAME, O=ROOT_CA_ORGANIZATION" \ --key-algorithm="ec-p256-sha256" \ --max-chain-length=1 \ --location ROOT_CA_POOL_LOCATION
Per questa configurazione dimostrativa, utilizza i seguenti valori per le variabili:
- ROOT_CA_POOL_NAME=td_sec_pool
- ROOT_CA_NAME=pkcs2-ca
- ROOT_CA_POOL_LOCATION=us-east1
- ROOT_CA_ORGANIZATION="TestCorpLLC"
Crea il pool subordinato e la CA subordinata. Assicurati che la modalità di emissione basata sulla configurazione predefinita rimanga consentita.
gcloud privateca pools create SUBORDINATE_CA_POOL_NAME \ --location SUBORDINATE_CA_POOL_LOCATION \ --tier devops
gcloud privateca subordinates create SUBORDINATE_CA_NAME \ --pool SUBORDINATE_CA_POOL_NAME \ --location SUBORDINATE_CA_POOL_LOCATION \ --issuer-pool ROOT_CA_POOL_NAME \ --issuer-location ROOT_CA_POOL_LOCATION \ --subject "CN=SUBORDINATE_CA_NAME, O=SUBORDINATE_CA_ORGANIZATION" \ --key-algorithm "ec-p256-sha256" \ --use-preset-profile subordinate_mtls_pathlen_0
Per questa configurazione dimostrativa, utilizza i seguenti valori per le variabili:
- SUBORDINATE_CA_POOL_NAME="td-ca-pool"
- SUBORDINATE_CA_POOL_LOCATION=us-east1
- SUBORDINATE_CA_NAME="td-ca"
- SUBORDINATE_CA_ORGANIZATION="TestCorpLLC"
- ROOT_CA_POOL_NAME=td_sec_pool
- ROOT_CA_POOL_LOCATION=us-east1
Concedi il ruolo IAM
privateca.auditor
per il pool di CA radice per consentire l'accesso dalaccount di serviziot GKE:gcloud privateca pools add-iam-policy-binding ROOT_CA_POOL_NAME \ --location ROOT_CA_POOL_LOCATION \ --role roles/privateca.auditor \ --member="serviceAccount:service-PROJNUM@container-engine-robot.iam.gserviceaccount.com"
Concedi il ruolo IAM
privateca.certificateManager
per il pool di CA secondarie per consentire l'accesso dal account di servizio GKE:gcloud privateca pools add-iam-policy-binding SUBORDINATE_CA_POOL_NAME \ --location SUBORDINATE_CA_POOL_LOCATION \ --role roles/privateca.certificateManager \ --member="serviceAccount:service-PROJNUM@container-engine-robot.iam.gserviceaccount.com"
Salva la seguente configurazione YAML
WorkloadCertificateConfig
per indicare al tuo cluster come emettere certificati mesh:apiVersion: security.cloud.google.com/v1 kind: WorkloadCertificateConfig metadata: name: default spec: # Required. The CA service that issues your certificates. certificateAuthorityConfig: certificateAuthorityServiceConfig: endpointURI: ISSUING_CA_POOL_URI # Required. The key algorithm to use. Choice of RSA or ECDSA. # # To maximize compatibility with various TLS stacks, your workloads # should use keys of the same family as your root and subordinate CAs. # # To use RSA, specify configuration such as: # keyAlgorithm: # rsa: # modulusSize: 4096 # # Currently, the only supported ECDSA curves are "P256" and "P384", and the only # supported RSA modulus sizes are 2048, 3072 and 4096. keyAlgorithm: rsa: modulusSize: 4096 # Optional. Validity duration of issued certificates, in seconds. # # Defaults to 86400 (1 day) if not specified. validityDurationSeconds: 86400 # Optional. Try to start rotating the certificate once this # percentage of validityDurationSeconds is remaining. # # Defaults to 50 if not specified. rotationWindowPercentage: 50
Sostituisci quanto segue:
- L'ID progetto del progetto in cui viene eseguito il cluster:
PROJECT_ID
- L'URI completo della CA che emette i certificati mesh (ISSUING_CA_POOL_URI).
Può trattarsi della CA subordinata (opzione consigliata) o della CA principale. Il formato è:
//privateca.googleapis.com/projects/PROJECT_ID/locations/SUBORDINATE_CA_POOL_LOCATION/caPools/SUBORDINATE_CA_POOL_NAME
- L'ID progetto del progetto in cui viene eseguito il cluster:
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 progetto 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
- L'ID progetto del progetto in cui viene eseguito il cluster:
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 disporre del ruolo
compute.NetworkAdmin
. Questo ruolo contiene tutte le autorizzazioni necessarie per
creare, aggiornare, eliminare, elencare e utilizzare (ovvero fare riferimento a questa risorsa in altre
risorse) le risorse richieste. Se sei il proprietario-editor 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 quando
fai 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 questo controllo
viene applicato.
Se utilizzi ruoli personalizzati e questo controllo verrà 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
dalla policy dell'endpoint.
Le seguenti istruzioni consentono all'account di servizio predefinito di accedere all'API Cloud Service Mesh Security e creare i service account Kubernetes.
Configura IAM per consentire al account di servizio predefinito di accedere all'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
Configura i service account Kubernetes. I deployment client e server nelle sezioni seguenti utilizzano i Kname dei service account Kubernetes server e client.
kubectl create serviceaccount --namespace K8S_NAMESPACE DEMO_SERVER_KSA kubectl create serviceaccount --namespace K8S_NAMESPACE DEMO_CLIENT_KSA
Consenti ai service account Kubernetes di rappresentare il account di servizio Compute Engine predefinito creando un'associazione dei criteri IAM tra i due. Questa associazione consente al 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}
Aggiungi annotazioni agli 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 Cloud Service Mesh
Segui le istruzioni riportate di seguito per installare l'iniettore sidecar, configurare un servizio di test e completare altre attività di deployment.
Installa l'iniettore di file collaterali Envoy nel cluster
Segui le istruzioni riportate in entrambe le sezioni seguenti della configurazione di Cloud Service Mesh per i pod GKE con l'inserimento automatico di Envoy per eseguire il deployment e attivare l'inserimento di Envoy sidecar nel cluster:
- Configurare le informazioni del progetto
- Installazione di MutatingWebhookConfigurations.
Assicurati di configurare il nome della mesh come
sidecar_mesh
e la rete come "", una stringa vuota. - Attivazione dell'inserimento di sidecar
Assicurati di completare entrambi i set di istruzioni prima di configurare un servizio di test.
Configurare un servizio di test
Dopo aver installato l'iniettore sidecar Envoy, utilizza queste istruzioni per configurare un servizio di test per la tua implementazione.
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 l'applicazione del server demo. Esistono alcune annotazioni specifiche per la sicurezza di Cloud Service Mesh.
Metadati del 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 rileva questa annotazione e la trasmette a Cloud Service Mesh. Cloud Service Mesh può quindi utilizzare queste informazioni per restituire la configurazione filtrata:
- Più avanti in questa guida, tieni presente che il criterio dell'endpoint specifica un matcher dell'endpoint.
- Il matcher dell'endpoint specifica che solo i client che presentano un'etichetta con
nome
app
e valorepayments
ricevono la configurazione filtrata.
Utilizzare certificati e chiavi mesh firmati dal servizio CA
Il file 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.
Configurazione della porta di intercettazione del traffico in entrata
Il file 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 il pod viene inizializzato, il proxy sidecar rileva questa annotazione e la trasmette a Cloud Service Mesh. Cloud Service Mesh può quindi utilizzare queste informazioni per inviare una configurazione filtrata che intercetta tutto il traffico in entrata a questa porta e può applicare criteri di sicurezza.
La porta del controllo di integrità deve essere diversa dalla porta dell'applicazione. In caso contrario, alle connessioni in entrata alla porta del controllo di integrità verranno applicate le stesse norme di sicurezza, il che potrebbe comportare il rifiuto delle connessioni e la conseguente errata segnalazione del server 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 servizio di backend Cloud Service Mesh. 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"
Esegui il deployment di un'applicazione client in GKE
Esegui il seguente comando per avviare un client dimostrativo con un proxy Envoy come sidecar, necessario 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 è
necessario per montare i volumi necessari per le chiavi e i certificati mesh gestiti da GKE
firmati dall'istanza del servizio CA.
Configura le risorse di controllo di integrità, regola firewall e servizio di backend
In questa sezione, crei le risorse di controllo di integrità, regola firewall e servizio di backend per Cloud Service Mesh.
Crea il controllo di integrità.
gcloud compute health-checks create http td-gke-health-check \ --use-serving-port
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
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
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
Configurare le risorse Mesh
e HTTPRoute
In questa sezione creerai le risorse Mesh
e HTTPRoute
.
Crea la specifica della risorsa
Mesh
e salvala in un file denominatomesh.yaml
.name: sidecar-mesh interceptionPort: 15001
Se non lo specifichi nel file
mesh.yaml
, la porta di intercettazione è impostata su15001
per impostazione predefinita.Crea la risorsa
Mesh
utilizzando la specifica mesh.yaml.gcloud network-services meshes import sidecar-mesh \ --source=mesh.yaml \ --location=global
Crea la specifica
HTTPRoute
e salvala in un file denominatohttp_route.yaml
.Puoi utilizzare
PROJECT_ID
oPROJECT_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"
Crea la risorsa
HTTPRoute
utilizzando la specifica nel filehttp_route.yaml
.gcloud network-services http-routes import helloworld-http-route \ --source=http_route.yaml \ --location=global
La configurazione di Cloud Service Mesh è completa e ora puoi configurare i criteri di autenticazione e autorizzazione.
Configura la sicurezza da servizio a servizio
Segui le istruzioni riportate nelle sezioni seguenti per configurare la sicurezza da servizio a servizio.
Abilita mTLS nel mesh
Per configurare mTLS nel mesh, devi proteggere il traffico in uscita verso il servizio di backend e il traffico in entrata verso l'endpoint.
Formato per i riferimenti alle norme
Tieni presente il seguente formato obbligatorio per fare riferimento a TLS server, TLS client e alle policy 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 una policy TLS del client che esegua le seguenti operazioni:
- Utilizza
google_cloud_private_spiffe
come plug-in perclientCertificate
, che programma Envoy per utilizzare i certificati mesh gestiti da GKE come identità client. - Utilizza
google_cloud_private_spiffe
come plug-in perserverValidationCa
che programma Envoy per utilizzare i certificati mesh gestiti da GKE per la convalida del server.
Successivamente, collega la policy TLS del client al servizio di backend. In questo modo:
- Applica il criterio di autenticazione dal criterio TLS client alle connessioni in uscita agli endpoint del servizio di backend.
- I SAN (Subject Alternative Names) indicano al client di asserire l'identità esatta del server a cui si connette.
Crea la policy TLS del client in un file
client-mtls-policy.yaml
:name: "client-mtls-policy" clientCertificate: certificateProviderInstance: pluginInstance: google_cloud_private_spiffe serverValidationCa: - certificateProviderInstance: pluginInstance: google_cloud_private_spiffe
Importa la policy TLS del client:
gcloud network-security client-tls-policies import client-mtls-policy \ --source=client-mtls-policy.yaml --location=global
Collega la policy TLS del client al servizio di backend. In questo modo viene applicata l'autenticazione mTLS a tutte le richieste in uscita dal client a questo servizio di backend.
gcloud compute backend-services export td-gke-service \ --global --destination=demo-backend-service.yaml
Aggiungi le seguenti righe a
demo-backend-service.yaml
:securitySettings: clientTlsPolicy: projects/PROJECT_ID/locations/global/clientTlsPolicies/client-mtls-policy subjectAltNames: - "spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_SERVER_KSA"
Importa i valori:
gcloud compute backend-services import td-gke-service \ --global --source=demo-backend-service.yaml
(Facoltativo) Esegui questo comando per verificare se la richiesta non va a buon fine. Si tratta di un errore previsto, perché il client si aspetta 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"
Visualizzi 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 una policy TLS del server che esegua le seguenti operazioni:
- Utilizza
google_cloud_private_spiffe
come plug-in perserverCertificate
, che programma Envoy per utilizzare i certificati mesh gestiti da GKE come identità del server. - Utilizza
google_cloud_private_spiffe
come plug-in perclientValidationCa
, che programma Envoy per utilizzare i certificati mesh gestiti da GKE per la convalida del client.
Salva i valori del criterio TLS del server in un file denominato
server-mtls-policy.yaml
.name: "server-mtls-policy" serverCertificate: certificateProviderInstance: pluginInstance: google_cloud_private_spiffe mtlsPolicy: clientValidationCa: - certificateProviderInstance: pluginInstance: google_cloud_private_spiffe
Crea la policy TLS del server:
gcloud network-security server-tls-policies import server-mtls-policy \ --source=server-mtls-policy.yaml --location=global
Crea un file denominato
ep_mtls.yaml
contenente il matcher dell'endpoint e collega la policy TLS del server.endpointMatcher: metadataLabelMatcher: metadataLabelMatchCriteria: MATCH_ALL metadataLabels: - labelName: app labelValue: payments name: "ep" serverTlsPolicy: projects/PROJECT_ID/locations/global/serverTlsPolicies/server-mtls-policy type: SIDECAR_PROXY
Importa il matcher di 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, 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 -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"
Vedi un output simile al seguente:
GET /get HTTP/1.1 Host: service-test content-length: 0 x-envoy-internal: true accept: */* x-forwarded-for: 10.48.0.6 x-envoy-expected-rq-timeout-ms: 15000 user-agent: curl/7.35.0 x-forwarded-proto: http x-request-id: redacted x-forwarded-client-cert: By=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_SERVER_KSA;Hash=Redacted;Subject="Redacted;URI=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_CLIENT_KSA
Tieni presente che l'intestazione x-forwarded-client-cert
viene inserita da Envoy lato server e contiene la propria identità (server) e l'identità del client di origine. Poiché vediamo sia l'identità del client che quella del server, questo è un segnale
di una connessione mTLS.
Configura l'accesso a livello di servizio con una policy di autorizzazione
Queste istruzioni creano una policy 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.
Crea una policy di autorizzazione creando un file denominato
authz-policy.yaml
.action: ALLOW name: authz-policy rules: - sources: - principals: - spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_CLIENT_KSA destinations: - hosts: - service-test ports: - 8000 methods: - GET
Importa la policy:
gcloud network-security authorization-policies import authz-policy \ --source=authz-policy.yaml \ --location=global
Aggiorna la policy dell'endpoint in modo che faccia riferimento alla nuova policy 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
.Importa la policy:
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 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 seguenti comandi per verificare se la policy di autorizzazione rifiuta correttamente le richieste non valide:
# Failure case # Command to execute that tests connectivity to the service service-test. # This is an invalid request and server will reject because the server # authorization policy only allows GET requests. TEST_CMD="wget -q -O - service-test --post-data='' ; echo" # Execute the test command on the pod. kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"
L'output previsto è simile a questo:
<RBAC: access denied HTTP/1.1 403 Forbidden>
Configurare la sicurezza del gateway in entrata
Questa sezione presuppone che tu abbia completato la sezione sulla sicurezza da servizio a servizio, inclusa la configurazione del cluster GKE con l'iniettore automatico di sidecar, la creazione di un'autorità di certificazione e la creazione di una policy endpoint.
In questa sezione, esegui il deployment di un proxy Envoy come gateway di ingresso che termina le connessioni TLS e autorizza le richieste dai client interni di un cluster.
Per configurare un gateway in entrata per terminare TLS:
- Esegui il deployment di un servizio Kubernetes raggiungibile utilizzando un indirizzo IP interno del cluster.
- Il deployment è costituito da un proxy Envoy autonomo esposto come servizio Kubernetes e si connette a Cloud Service Mesh.
- Crea una policy TLS del server per terminare TLS.
- Crea un criterio di autorizzazione per autorizzare le richieste in entrata.
Esegui il deployment di un servizio di 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
Il file gateway_sample.yaml
è la specifica per il gateway in entrata. Le sezioni seguenti descrivono alcune aggiunte alla specifica.
Disattivazione dell'inserimento del sidecar di Cloud Service Mesh
La specifica gateway_sample.yaml
esegue il deployment di un proxy Envoy come unico container. Nei
passaggi precedenti, Envoy è stato inserito come sidecar in un container dell'applicazione. Per
evitare che più Envoy gestiscano le richieste, puoi disattivare l'inserimento di sidecar
per questo servizio Kubernetes utilizzando la seguente istruzione:
sidecar.istio.io/inject: "false"
Montare il volume corretto
La specifica gateway_sample.yaml
monta il volume gke-workload-certificates
.
Questo volume viene utilizzato anche nel deployment sidecar, ma viene aggiunto automaticamente
dall'iniettore sidecar quando rileva 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 del servizio CA che hai configurato.
Imposta 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 8080
del deployment del gateway di ingresso Envoy.
Abilita TLS su un gateway in entrata
Segui queste istruzioni per abilitare TLS su un gateway in entrata.
Crea una risorsa policy TLS del server per terminare le connessioni TLS, con i valori in un file denominato
server-tls-policy.yaml
:description: tls server policy name: server-tls-policy serverCertificate: certificateProviderInstance: pluginInstance: google_cloud_private_spiffe
Importa la policy TLS del server:
gcloud network-security server-tls-policies import server-tls-policy \ --source=server-tls-policy.yaml --location=global
Crea un nuovo target
Gateway
e salvalo nel filetd-gke-gateway.yaml
. In questo modo viene allegata la policy TLS del server e viene configurato il gateway in entrata 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
Importa il gateway:
gcloud network-services gateways import td-gke-gateway \ --source=td-gke-gateway.yaml \ --location=global
Crea e salva un nuovo
HTTPRoute
chiamatotd-gke-route
che fa riferimento al gateway e indirizza tutte le richieste atd-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"
Importa il file
HTTPRoute
:gcloud network-services http-routes import td-gke-route \ --source=td-gke-route.yaml \ --location=global
(Facoltativo) 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 il account di servizioDEMO_CLIENT_KSA
. - Richieste con host
mesh-gateway
oservice-test
- Porta:
8000
Non è necessario eseguire questi comandi a meno che tu non abbia configurato un criterio di autorizzazione per i backend. Se non sono presenti criteri di autorizzazione sull'endpoint o se non contengono la corrispondenza dell'entità host o di origine nei criteri 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
- Richieste inviate da
Importa la policy:
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 denominato debug
per inviare richieste al gateway di ingresso
per convalidare il deployment.
Nella seguente specifica, l'annotazione "sidecar.istio.io/inject":"false"
impedisce
all'iniettore sidecar di Cloud Service Mesh di inserire automaticamente un proxy
sidecar. Non è presente alcun sidecar per aiutare il container debug
nel routing delle richieste.
Per il routing, il contenitore deve connettersi al gateway di ingresso.
La specifica include il flag --no-check-certificate
, che ignora la convalida del certificato del server. Il container debug
non dispone dei certificati di convalida dell'autorità di certificazione necessari per certificati validi firmati dal servizio CA 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 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"
Viene visualizzato 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
Puoi eseguire questi comandi facoltativi 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 Cloud Service Mesh è supportata solo con GKE. Non puoi eseguire il deployment della sicurezza del servizio 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 con un erroreupstream connect
o disconnect/reset
before headers
, esamina i log di Envoy, dove potresti visualizzare uno dei seguenti messaggi di log:
gRPC config stream closed: 5, Requested entity was not found
gRPC config stream closed: 2, no credential token is found
Se visualizzi questi errori nel log di Envoy, è probabile che il token del service account sia montato in modo errato o che utilizzi un audience
diverso o entrambi.
Per ulteriori informazioni, vedi I messaggi di errore nei log di Envoy indicano un problema di configurazione.
Pod non creati
Per risolvere il problema, consulta Risoluzione dei problemi relativi ai deployment automatici per i pod GKE.
Envoy non esegue l'autenticazione con 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 il account di servizio predefinito della VM Compute Engine (a meno che il bootstrap non sia stato modificato). Se l'autenticazione non va a buon fine, Envoy non entra nello stato pronto.
Impossibile creare un cluster con --workload-identity-certificate-authority flag
Se visualizzi questo errore, assicurati di utilizzare la versione più recente di Google Cloud CLI:
gcloud components update
I pod rimangono in stato In attesa
Se i pod rimangono in stato di attesa durante la procedura di configurazione, aumenta le risorse di CPU e memoria per i pod nella specifica di deployment.
Impossibile creare il cluster con il flag --enable-mesh-certificates
Assicurati di utilizzare l'ultima versione della 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 i certificati mesh GKE potrebbero non avviarsi se il provisioning dei certificati non va a buon fine. Ciò può verificarsi in situazioni come le seguenti:
WorkloadCertificateConfig
oTrustConfig
non è configurato correttamente o manca.- Le richieste CSR non vengono approvate.
Puoi verificare se il provisioning del certificato non riesce controllando gli eventi del pod.
Controllare lo stato del tuo 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.
Controlla gli eventi recenti del tuo pod:
kubectl describe pod -n POD_NAMESPACE POD_NAME
Se il provisioning dei certificati non va a buon fine, vedrai un evento con
Type=Warning
,Reason=FailedMount
,From=kubelet
e un campoMessage
che inizia conMountVolume.SetUp failed for volume "gke-workload-certificates"
. Il campoMessage
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)
Consulta i seguenti passaggi per la risoluzione dei problemi se il motivo per cui i pod non vengono avviati è dovuto a oggetti configurati in modo errato o a CSR rifiutate.
WorkloadCertificateConfig
o TrustConfig
è configurato in modo errato
Assicurati di aver creato correttamente gli oggetti WorkloadCertificateConfig
e TrustConfig
. Puoi diagnosticare le configurazioni errate su uno di questi
oggetti utilizzando kubectl
.
Recupera lo stato attuale.
Per
WorkloadCertificateConfig
:kubectl get WorkloadCertificateConfig default -o yaml
Per
TrustConfig
:kubectl get TrustConfig default -o yaml
Controlla l'output dello stato. Un oggetto valido avrà una condizione con
type: Ready
estatus: "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
status: "False"
. I campireason
emessage
contengono ulteriori dettagli per la risoluzione dei problemi.
Le CSR non sono approvate
Se si verifica un problema durante la procedura di approvazione della CSR, puoi controllare i dettagli dell'errore nelle condizioni type: Approved
e type: Issued
della CSR.
Elenca i CSR pertinenti utilizzando
kubectl
:kubectl get csr \ --field-selector='spec.signerName=spiffe.gke.io/spiffe-leaf-signer'
Scegli un CSR che sia
Approved
e nonIssued
oppure che non siaApproved
.Recupera i dettagli della CSR selezionata utilizzando kubectl:
kubectl get csr CSR_NAME -o yaml
Sostituisci
CSR_NAME
con il nome della CSR che hai scelto.
Una CSR valida 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 alle richieste CSR non valide vengono visualizzate nei campi message
e
reason
.
Le applicazioni non possono utilizzare le credenziali mTLS emesse
Verifica che il certificato non sia scaduto:
cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -text -noout | grep "Not After"
Verifica che il tipo di chiave che hai utilizzato sia supportato dalla tua applicazione.
cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -text -noout | grep "Public Key Algorithm" -A 3
Verifica che la CA emittente utilizzi la stessa famiglia di chiavi della chiave del certificato.
Ottieni lo stato dell'istanza del servizio CA (anteprima):
gcloud privateca ISSUING_CA_TYPE describe ISSUING_CA_NAME \ --location ISSUING_CA_LOCATION
Sostituisci quanto segue:
ISSUING_CA_TYPE
: il tipo di CA emittente, che deve esseresubordinates
oroots
.ISSUING_CA_NAME
: il nome della CA emittente.ISSUING_CA_LOCATION
: la regione della CA emittente.
Verifica che
keySpec.algorithm
nell'output sia lo stesso algoritmo della chiave che hai definito nel manifest YAMLWorkloadCertificateConfig
. L'output ha il seguente aspetto:config: ... subjectConfig: commonName: td-sub-ca subject: organization: TestOrgLLC subjectAltName: {} createTime: '2021-05-04T05:37:58.329293525Z' issuingOptions: includeCaCertUrl: true keySpec: algorithm: RSA_PKCS1_2048_SHA256 ...
I certificati vengono rifiutati
- Verifica che l'applicazione peer utilizzi lo stesso bundle di attendibilità per verificare il certificato.
Verifica che il certificato non sia scaduto:
cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -text -noout | grep "Not After"
Verifica che il codice client, se non utilizza l'API per il ricaricamento delle credenziali gRPC Go, aggiorni periodicamente le credenziali dal file system.
Verifica che i tuoi carichi di lavoro si trovino nello stesso dominio di attendibilità della tua CA. I certificati mesh GKE supportano la comunicazione tra i carichi di lavoro in un singolo dominio di attendibilità.