Configura la sicurezza dei servizi con Envoy
Usa le istruzioni di 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 completamento informazioni sulla sicurezza del servizio Cloud Service Mesh, vedi 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, vedi Preparati 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.
Preparati per la configurazione
Le seguenti sezioni descrivono le attività da completare prima di configurare Servizio di sicurezza Cloud Service Mesh. Le seguenti 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 sul server macchina:
gcloud components update
Imposta le variabili
Imposta le seguenti variabili in modo da poter copiare e incollare il codice in modo mentre lavori nell'esempio in questo documento. Utilizza quanto segue e i relativi valori.
- PROJECT_ID: sostituisci l'ID del progetto.
- CLUSTER_NAME: sostituisci il nome del cluster che vuoi
ad esempio
secure-td-cluster
. - ZONE: sostituisci la zona in cui si trova il cluster. in cui si trova il cluster.
- GKE_CLUSTER_URL: sostituisci
https://container.googleapis.com/v1/projects/PROJECT_ID/locations/ZONE/clusters/CLUSTER_NAME
- WORKLOAD_POOL: sostituisci
PROJECT_ID.svc.id.goog
- K8S_NAMESPACE: sostituisci
default
. - DEMO_CLIENT_KSA: sostituisci il nome 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
service-PROJNUM@container-engine-robot.iam.gserviceaccount.com
CLUSTER_VERSION: sostituisci la versione più recente disponibili. Puoi trovare queste informazioni nelle note di rilascio del canale rapido. La versione minima richiesta è 1.21.4-gke.1801. Questo è il cluster GKE del cluster da usare 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 la gcloud services enable
per abilitare tutte le API necessarie per configurare 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 dal servizio CA integrazione con GKE. Il cluster GKE deve devono soddisfare i seguenti requisiti, i 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 mesh come descritto in Creazione di autorità di certificazione per emettere certificati.
Crea un nuovo cluster che utilizza Workload Identity. Se stai aggiornando una esistente, vai al passaggio successivo. Il valore che assegni a
--tags
deve corrispondere al nome trasmesso al flag--target-tags
per il Comandofirewall-rules create
nella sezione Configurazione di Cloud Service Mesh con i componenti di Cloud Load Balancing.# Create a GKE cluster with GKE managed mesh certificates. gcloud container clusters create CLUSTER_NAME \ --release-channel=rapid \ --scopes=cloud-platform \ --image-type=cos_containerd \ --machine-type=e2-standard-2 \ --zone=ZONE \ --workload-pool=PROJECT_ID.svc.id.goog \ --enable-mesh-certificates \ --cluster-version=CLUSTER_VERSION \ --enable-ip-alias \ --tags=allow-health-checks \ --workload-metadata=GKE_METADATA
La creazione del cluster potrebbe richiedere diversi minuti.
Se utilizzi un cluster esistente, attiva Workload Identity e Certificati mesh GKE. Assicurati che il cluster sia stato creato con il flag
--enable-ip-alias
, che non può essere usato conupdate
.gcloud container clusters update CLUSTER_NAME \ --enable-mesh-certificates
Esegui questo comando per passare al nuovo cluster come cluster predefinito per i tuoi comandi
kubectl
:gcloud container clusters get-credentials CLUSTER_NAME \ --zone ZONE
Deployment in un ambiente multi-cluster
Se esegui il deployment in un ambiente multi-cluster, segui le procedura descritta in questa sezione. Queste istruzioni presuppongono che i pod client sono in esecuzione in un cluster e i pod server sono in esecuzione in un altro cluster.
Crea o aggiorna i cluster utilizzando le istruzioni nella precedente .
Acquisisci gli intervalli di indirizzi IP del 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 chiamati
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
Creare regole firewall VPC che consentono ai cluster di comunicare tra loro. Ad esempio, il comando seguente crea un regola firewall che consente agli indirizzi IP del pod
cluster-a
di comunicare concluster-b
nodi:gcloud compute firewall-rules create per-cluster-a-pods \ --allow="tcp,udp,icmp,esp,ah,sctp" \ --target-tags="gke-cluster-b-acd14479-node"
Il comando seguente crea una regola firewall che consente all'
cluster-b
indirizzi IP dei pod per comunicare concluster-a
nodi:gcloud compute firewall-rules create per-cluster-b-pods \ --allow="tcp,udp,icmp,esp,ah,sctp" \ --target-tags="gke-cluster-a-9cd18751-node"
Registra i cluster con un parco risorse
Registra il cluster che hai creato o aggiornato in Creazione di un cluster GKE con un parco risorse. La registrazione del cluster semplifica la configurazione dei cluster più progetti.
Tieni presente che il completamento di questi passaggi può richiedere fino a dieci minuti ciascuno.
Registra il tuo 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.
Applica al cluster il file manifest generato:
kubectl apply -f MANIFEST-FILE_NAME
Quando la procedura di richiesta ha esito positivo, vengono visualizzati messaggi come il seguenti:
namespace/gke-connect created serviceaccount/connect-agent-sa created podsecuritypolicy.policy/gkeconnect-psp created role.rbac.authorization.k8s.io/gkeconnect-psp:role created rolebinding.rbac.authorization.k8s.io/gkeconnect-psp:rolebinding created role.rbac.authorization.k8s.io/agent-updater created rolebinding.rbac.authorization.k8s.io/agent-updater created role.rbac.authorization.k8s.io/gke-connect-agent-20210416-01-00 created clusterrole.rbac.authorization.k8s.io/gke-connect-impersonation-20210416-01-00 created clusterrolebinding.rbac.authorization.k8s.io/gke-connect-impersonation-20210416-01-00 created clusterrolebinding.rbac.authorization.k8s.io/gke-connect-feature-authorizer-20210416-01-00 created rolebinding.rbac.authorization.k8s.io/gke-connect-agent-20210416-01-00 created role.rbac.authorization.k8s.io/gke-connect-namespace-getter created rolebinding.rbac.authorization.k8s.io/gke-connect-namespace-getter created secret/http-proxy created deployment.apps/gke-connect-agent-20210416-01-00 created service/gke-connect-monitoring created secret/creds-gcp create
Recupera la risorsa di appartenenza dal cluster:
kubectl get memberships membership -o yaml
L'output dovrebbe includere il pool di identità Workoad assegnato dal parco risorse dove PROJECT_ID è il tuo ID progetto:
workload_identity_pool: PROJECT_ID.svc.id.goog
Ciò significa che il cluster è stato registrato correttamente.
Crea 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. Questa è la radice di attendibilità per tutti i certificati mesh emessi. Tu
puoi utilizzare una CA radice
esistente, se disponibile. Crea la CA radice nel
Livello
enterprise
, pensato per i certificati di lunga durata e con volumi bassi una determinata emissione. - CA subordinata. Questa CA emette certificati per i carichi di lavoro. Crea il
nella regione in cui è stato eseguito il deployment del cluster. Crea il
una CA subordinata nel livello
devops
, pensata per le applicazioni di breve durata, l'emissione di certificati in volumi elevati.
La creazione di una CA subordinata è facoltativa, ma consigliamo vivamente di crearne una anziché utilizzare la tua CA radice per emettere i certificati 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 subordinata può trovarsi in una regione diversa dal tuo cluster, ti consigliamo vivamente di crearlo nella stessa regione del cluster per ottimizzare delle prestazioni. Tuttavia, puoi creare le CA radice e subordinate in diverse regioni senza alcun impatto su prestazioni o 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
Concedi
roles/privateca.caManager
IAM a singoli utenti che creano un pool di CA e una CA. Tieni presente che per MEMBER, il valore il formato corretto èuser:userid@example.com
. Se la persona in questione è l'attuale puoi ottenere l'ID utente corrente con il comando shell$(gcloud auth list --filter=status:ACTIVE --format="value(account)")
.gcloud projects add-iam-policy-binding PROJECT_ID \ --member=MEMBER \ --role=roles/privateca.caManager
Concedi il ruolo
role/privateca.admin
per CA Service ai privati che devono modificare i criteri IAM, doveMEMBER
è persona che ha bisogno di questo accesso, in particolare individui che eseguono i passaggi che seguono per concedere leprivateca.auditor
Ruoliprivateca.certificateManager
:gcloud projects add-iam-policy-binding PROJECT_ID \ --member=MEMBER \ --role=roles/privateca.admin
Crea il pool di servizi CA radice.
gcloud privateca pools create ROOT_CA_POOL_NAME \ --location ROOT_CA_POOL_LOCATION \ --tier enterprise
Crea una CA radice.
gcloud privateca roots create ROOT_CA_NAME --pool ROOT_CA_POOL_NAME \ --subject "CN=ROOT_CA_NAME, O=ROOT_CA_ORGANIZATION" \ --key-algorithm="ec-p256-sha256" \ --max-chain-length=1 \ --location ROOT_CA_POOL_LOCATION
Per la configurazione di questa 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"
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 la configurazione di questa 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
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:service-PROJNUM@container-engine-robot.iam.gserviceaccount.com"
Concedi a IAM
privateca.certificateManager
ruolo per il pool di CA subordinato al fine di consentire l'accesso da GKE account di servizio: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 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 della CA che emette i certificati mesh (ISSUING_CA_POOL_URI).
Può essere la tua CA subordinata (consigliato) o la tua CA principale. Il formato è:
//privateca.googleapis.com/projects/PROJECT_ID/locations/SUBORDINATE_CA_POOL_LOCATION/caPools/SUBORDINATE_CA_POOL_NAME
- L'ID del progetto in cui viene eseguito il cluster:
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 principale (ROOT_CA_POOL_URI).
Il formato è:
//privateca.googleapis.com/projects/PROJECT_ID/locations/ROOT_CA_POOL_LOCATION/caPools/ROOT_CA_POOL_NAME
- L'ID 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 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 verranno applicate in futuro e utilizzi
ruolo compute.NetworkAdmin
, non noterai problemi durante questo controllo
in modo forzato.
Se utilizzi ruoli personalizzati e questo controllo verrà applicato in futuro, devi
assicurati di includere la rispettiva autorizzazione di .use
. Altrimenti, in futuro,
potresti scoprire che il tuo ruolo personalizzato non dispone delle autorizzazioni necessarie
fare riferimento a clientTlsPolicy
o serverTlsPolicy
del servizio di backend oppure
criterio endpoint.
Le seguenti istruzioni consentono all'account di servizio predefinito di accedere l'API Cloud Service Mesh Security e creare gli account di servizio Kubernetes.
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
Configurare 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
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}
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'injector sidecar di Envoy nel cluster
Segui le istruzioni in entrambe le sezioni seguenti della Configurazione di Cloud Service Mesh per pod GKE con inserimento Envoy automatico per eseguire il deployment e attivare l'inserimento di sidecar Envoy nel tuo cluster:
- Installazione dell'iniettore sidecar di Envoy.
Assicurati di configurare il nome della rete mesh
sidecar_mesh
e la rete come "", una stringa vuota. - Attivazione dell'inserimento di file collaterali
Assicurati di completare entrambe le istruzioni prima di configurare di prova del prodotto.
Configurare un servizio di prova
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
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 nella guida, noterai che il criterio endpoint specifica un matcher endpoint.
- Lo strumento di abbinamento degli endpoint specifica che solo i client che presentano un'etichetta con
il nome
app
e il valorepayments
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 firmati dal servizio CA le chiavi vengono montate 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 rimane in ascolto delle 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 una configurazione filtrata che intercetta tutto il traffico in entrata verso questa porta e 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.
Configura i servizi GKE con NEG
I servizi GKE devono essere esposti tramite gruppi di endpoint di rete
(NEG) in modo da poterli configurare come backend di un backend Cloud Service Mesh
completamente gestito di Google Cloud. Il pacchetto service_sample.yaml
fornito in 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 controllo di integrità, regola firewall e risorse del servizio di backend
In questa sezione creerai il controllo di integrità, la regola firewall e il 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 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
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 creerai le risorse Mesh
e HTTPRoute
.
Crea la specifica della risorsa
Mesh
e salvala in un file denominatomesh.yaml
.name: sidecar-mesh interceptionPort: 15001
La porta di intercettazione è impostata su
15001
per impostazione predefinita se non la specifichi nelmesh.yaml
file.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 nelhttp_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.
Configura la sicurezza service-to-service
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
Nota il seguente formato obbligatorio per fare riferimento a TLS server, client TLS e i criteri di autorizzazione:
projects/PROJECT_ID/locations/global/[serverTlsPolicies|clientTlsPolicies|authorizationPolicies]/[server-tls-policy|client-mtls-policy|authz-policy]
Ad esempio:
projects/PROJECT_ID/locations/global/serverTlsPolicies/server-tls-policy
projects/PROJECT_ID/locations/global/clientTlsPolicies/client-mtls-policy
projects/PROJECT_ID/locations/global/authorizationPolicies/authz-policy
Proteggere il traffico in uscita verso il servizio di backend
Per proteggere il traffico in uscita, devi prima creare un criterio TLS del client che esegua le seguenti:
- Usa
google_cloud_private_spiffe
come plug-in perclientCertificate
, quale programma Envoy per utilizzare i certificati mesh gestiti da GKE. come identità client. - Usa
google_cloud_private_spiffe
come plug-in perserverValidationCa
quale programma Envoy per utilizzare i certificati mesh gestiti da GKE. per la convalida del server.
Successivamente, collegherai il criterio TLS del client al servizio di backend. In questo modo seguenti:
- Applica il criterio di autenticazione del criterio TLS del client alla posta in uscita e le connessioni agli endpoint del servizio di backend.
- SAN (Subject Alternative Name) indica al client di asserire le esatte e l'identità del server a cui si connette.
Crea il criterio TLS del client in un file
client-mtls-policy.yaml
:name: "client-mtls-policy" clientCertificate: certificateProviderInstance: pluginInstance: google_cloud_private_spiffe serverValidationCa: - certificateProviderInstance: pluginInstance: google_cloud_private_spiffe
Importa il criterio TLS del client:
gcloud network-security client-tls-policies import client-mtls-policy \ --source=client-mtls-policy.yaml --location=global
Collega il criterio TLS del client al servizio di backend. Questa operazione applica mTLS autenticazione su tutte le richieste in uscita dal client a questo backend completamente gestito di Google Cloud.
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
Facoltativamente, esegui questo comando per verificare se la richiesta non riesce. Si tratta di un errore previsto, perché il client si aspetta certificati dalla ma quest'ultimo 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"
Verrà visualizzato un output come il seguente:
wget: server returned error: HTTP/1.1 503 Service Unavailable
Proteggere il traffico in entrata verso l'endpoint
Per proteggere il traffico in entrata, devi prima creare un criterio TLS del server che esegua le seguenti:
- Usa
google_cloud_private_spiffe
come plug-in perserverCertificate
, quale programma Envoy per utilizzare i certificati mesh gestiti da GKE. come identità del server. - Usa
google_cloud_private_spiffe
come plug-in perclientValidationCa
, quale 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 il criterio 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 endpoint e per collegare il criterio TLS del server.endpointMatcher: metadataLabelMatcher: metadataLabelMatchCriteria: MATCH_ALL metadataLabels: - labelName: app labelValue: payments name: "ep" serverTlsPolicy: projects/PROJECT_ID/locations/global/serverTlsPolicies/server-mtls-policy type: SIDECAR_PROXY
Importa il matcher degli 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"
Verrà visualizzato 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
è inserita dal lato server
Envoy e contiene la propria identità (server) e l'identità dell'origine
di alto profilo. 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.
Crea un criterio di autorizzazione creando un file denominato
authz-policy.yaml
.action: ALLOW name: authz-policy rules: - sources: - principals: - spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_CLIENT_KSA destinations: - hosts: - service-test ports: - 8000 methods: - GET
Importa il criterio:
gcloud network-security authorization-policies import authz-policy \ --source=authz-policy.yaml \ --location=global
Aggiorna il criterio dell'endpoint per fare riferimento al nuovo criterio di autorizzazione aggiungendo il seguente codice 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 protocollo deve essere applicato in modo forzato alle richieste in entrata ai pod il cui sidecar Envoy i proxy presentano l'etichetta
app:payments
.Importa il criterio:
gcloud network-services endpoint-policies import ep \ --source=ep_mtls.yaml --location=global
Convalida la configurazione
Esegui questi comandi per convalidare la configurazione.
# Get the name of the Podrunning Busybox. BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}') # Command to execute that tests connectivity to the service service-test. # This is a valid request and will be allowed. TEST_CMD="wget -q -O - service-test; echo" # Execute the test command on the pod. kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"
L'output previsto è simile 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 questi comandi per verificare se il criterio di autorizzazione è rifiutando 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 la sicurezza del gateway in entrata
In questa sezione si presuppone che tu abbia completato la sezione sulla sicurezza tra servizi, tra cui la configurazione del cluster GKE con l'auto-injector del sidecar, creando un'autorità di certificazione e la creazione di un criterio endpoint.
In questa sezione eseguirai il deployment di un proxy Envoy come gateway in entrata che termina Connessioni TLS e autorizza le richieste dai client interni di un cluster.
Per configurare un gateway in entrata per terminare TLS, segui questi passaggi:
- Esegui il deployment di un servizio Kubernetes raggiungibile utilizzando un IP interno del cluster
.
- Il deployment consiste in un proxy Envoy autonomo esposto come un Kubernetes e si connette a Cloud Service Mesh.
- Crea un criterio TLS del server per terminare TLS.
- Crea un criterio di autorizzazione per autorizzare le richieste in entrata.
Esegui il deployment di un servizio gateway in entrata in GKE
Esegui questo comando per eseguire il deployment del servizio gateway in entrata 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 seguenti
le sezioni 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 container. Nel
passaggi precedenti, Envoy è stato inserito come file collaterale di un container di applicazioni. A
evitare che più Envoy gestiscono le richieste, puoi disattivare l'inserimento collaterale
per questo servizio Kubernetes usando la seguente istruzione:
sidecar.istio.io/inject: "false"
Monta il volume corretto
La specifica gateway_sample.yaml
monta il volume gke-workload-certificates
.
Questo volume viene utilizzato anche nel deployment collaterale, ma viene aggiunto automaticamente
dall'iniettore collaterale quando vede l'annotazione
cloud.google.com/enableManagedCerts: "true"
. gke-workload-certificates
contiene i certificati e le chiavi SPIFFE gestiti da GKE firmati
di CA Service che hai configurato.
Imposta l'indirizzo IP interno del cluster
Configura il gateway in entrata con un servizio di tipo ClusterInternal
. Questo
crea 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
.
Abilita TLS su un gateway in entrata
Utilizza queste istruzioni per abilitare TLS su un gateway in entrata.
Crea una risorsa di criterio TLS del server per terminare le connessioni TLS, con il in un file denominato
server-tls-policy.yaml
:description: tls server policy name: server-tls-policy serverCertificate: certificateProviderInstance: pluginInstance: google_cloud_private_spiffe
Importa il criterio TLS del server:
gcloud network-security server-tls-policies import server-tls-policy \ --source=server-tls-policy.yaml --location=global
Crea un nuovo target
Gateway
e salvalo nel filetd-gke-gateway.yaml
. Questa operazione collega il criterio TLS del server e configura il traffico proxy in entrata 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
denominatotd-gke-route
che fa riferimento il gateway e instrada 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
HTTPRoute
:gcloud network-services httproutes import td-gke-route \ --source=td-gke-route.yaml \ --location=global
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 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'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
- Richieste inviate da
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 esiste un file collaterale che aiuti il container debug
nel routing delle richieste.
Il container deve connettersi al gateway in entrata per il routing.
La specifica include il flag --no-check-certificate
, che ignora il server
la convalida dei certificati. Il container debug
non dispone del certificato
certificati di convalida dell'autorità necessari per convalidare i certificati firmati da
Servizio CA utilizzato dal gateway in entrata per la terminazione
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 il
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 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"
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 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
token dell'account è stato montato in modo errato o sta utilizzando un altro audience
, oppure
entrambi.
Per ulteriori informazioni, vedi I messaggi di errore nei log di Envoy indicano che problema.
Pod non creati
Per risolvere questo problema, consulta Risoluzione dei problemi dei 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 xDS
automaticamente, utilizza Workload Identity e la VM
account di servizio predefinito (a meno che non sia stato modificato il bootstrap). 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 eseguire l'ultima versione di gcloud CLI:
gcloud components update
Tieni presente che il flag --enable-mesh-certificates
funziona solo con gcloud beta
.
I pod non si avviano
I pod che utilizzano i certificati mesh GKE potrebbero non avviarsi se il provisioning dei certificati non funziona. Ciò può verificarsi in situazioni come le seguenti:
WorkloadCertificateConfig
oTrustConfig
non sono configurati correttamente o mancante.- I CSR non vengono approvati.
Puoi verificare se il provisioning del certificato non è andato a buon fine controllando il pod eventi.
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.
Controlla gli eventi recenti per il tuo pod:
kubectl describe pod -n POD_NAMESPACE POD_NAME
Se il provisioning del certificato non riesce, verrà visualizzato 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)
Se il motivo per cui i pod non si avviano, consulta i seguenti passaggi per la risoluzione dei problemi a causa di oggetti configurati in modo errato o di CSR rifiutati.
La configurazione di WorkloadCertificateConfig
o TrustConfig
non è corretta
Assicurati di aver creato i campi WorkloadCertificateConfig
e TrustConfig
correttamente gli oggetti. Puoi diagnosticare gli errori di configurazione su una di queste opzioni
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
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 invece visualizzato
status: "False"
. Lereason
e Il campomessage
contiene ulteriori dettagli sulla risoluzione dei problemi.
I CSR non sono approvati
Se si verifica un problema 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.
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 non siaApproved
.Ottieni i dettagli della CSR selezionata con 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 a CSR non valide vengono visualizzate in message
e
reason
campi.
Le applicazioni non possono utilizzare le credenziali mTLS emesse
Verifica che il certificato non sia scaduto:
cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -text -noout | grep "Not After"
Verifica che il tipo di chiave utilizzato sia supportato dalla tua applicazione.
cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -text -noout | grep "Public Key Algorithm" -A 3
Verifica che la CA emittente utilizzi la stessa famiglia di chiavi della chiave del certificato.
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 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 chiave definito nel manifest YAMLWorkloadCertificateConfig
. L'output avrà il seguente aspetto:config: ... subjectConfig: commonName: td-sub-ca subject: organization: TestOrgLLC subjectAltName: {} createTime: '2021-05-04T05:37:58.329293525Z' issuingOptions: includeCaCertUrl: true keySpec: algorithm: RSA_PKCS1_2048_SHA256 ...
I certificati vengono rifiutati
- Verifica che l'applicazione peer utilizzi lo stesso bundle di attendibilità per verificare il certificato.
Verifica che il certificato non sia scaduto:
cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -text -noout | grep "Not After"
Verifica che il codice client, se non utilizzi l'API di ricaricamento credenziali gRPC Go, aggiorni periodicamente le credenziali dal file system.
Verifica che i carichi di lavoro si trovino nello stesso dominio attendibile della CA. I certificati mesh GKE supportano la comunicazione tra carichi di lavoro in un singolo dominio di attendibilità.