Configura la sicurezza dei servizi con gRPC senza proxy
Questa guida mostra come configurare un servizio di sicurezza per proxyless mesh di servizi gRPC.
Requisiti
Prima di configurare la sicurezza del servizio per il mesh di servizi senza proxy gRPC, assicurati di soddisfare i seguenti requisiti.
- Il tuo deployment soddisfa i requisiti descritti in Prepararsi a configurare le API di routing dei servizi con Envoy e carichi di lavoro proxyless.
- Devi utilizzare xDS 3.
- Hai accesso alla versione di xDS e al provider di certificati richiesti
di Google Cloud con una delle seguenti lingue:
- Java gRPC
- gRPC C++
- gRPC Python
- gRPC Go Puoi trovare le versioni in lingua richieste su GitHub
- Hai accesso al generatore di bootstrap, versione 0.16.0. L'immagine del generatore di bootstrap si trova nel repository di container di Google Cloud.
- Soddisfi tutti i prerequisiti per il load balancing del mesh di servizi gRPC senza proxy.
- Disponi delle autorizzazioni sufficienti per creare o aggiornare le risorse Cloud Service Mesh e del mesh di servizi Google Cloud per utilizzare la sicurezza PSM. Per informazioni complete sulle autorizzazioni richieste, consulta Prepararsi a configurare Cloud Service Mesh con servizi gRPC proxyless.
- Disponi delle autorizzazioni necessarie per utilizzare Certificate Authority Service, che sono descritto in Creare autorità di certificazione per emettere certificati
Configurare Identity and Access Management
Devi disporre delle autorizzazioni necessarie per utilizzare Google Kubernetes Engine. Devi disporre almeno dei seguenti ruoli:
roles/container.clusterAdmin
ruolo GKEroles/compute.instanceAdmin
Ruolo Compute Engine- Ruolo
roles/iam.serviceAccountUser
Per creare le risorse necessarie per la configurazione, devi disporre del 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 il proprietario-editor del progetto,
disponi automaticamente di questo ruolo.
Tieni presente che networksecurity.googleapis.com.clientTlsPolicies.use
e
networksecurity.googleapis.com.serverTlsPolicies.use
non vengono applicate in modo forzato
e fare riferimento a queste risorse
nella risorsa del servizio di backend.
Se questa impostazione verrà applicata in futuro e utilizzi il ruolo compute.NetworkAdmin
, non noterai alcun problema quando verrà applicato questo controllo.
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
per fare riferimento a clientTlsPolicy
o serverTlsPolicy
del servizio di backend.
Prepararsi alla configurazione
La sicurezza del mesh di servizi senza proxy (PSM) aggiunge sicurezza a un mesh di servizi che
per il bilanciamento del carico in base ai servizi gRPC senza proxy
documentazione. In un servizio mesh senza proxy, un client gRPC utilizza lo schema xds:
nell'URI per accedere al servizio, il che abilita le funzionalità di bilanciamento del carico e di rilevamento degli endpoint del PSM.
Aggiorna i client e i server gRPC alla versione corretta
Crea o ricrea le tue applicazioni utilizzando la versione minima di gRPC supportata per la tua lingua.
Aggiorna il file di bootstrap
Le applicazioni gRPC utilizzano un unico file di bootstrap, che deve contenere tutti i campi richiesti dal codice lato client e lato server gRPC. Un generatore di bootstrap genera automaticamente il file di bootstrap per includere i flag e i valori necessari per la sicurezza PSM. Per ulteriori informazioni, consulta la sezione Bootstrap file, che include un file di bootstrap di esempio.
Panoramica della configurazione
Questa procedura di configurazione è un'estensione della configurazione di Cloud Service Mesh con GKE e servizi gRPC proxyless. I passaggi esistenti non modificati della procedura di configurazione vengono richiamati ovunque siano applicabili.
I principali miglioramenti alla configurazione di Cloud Service Mesh con GKE sono i seguenti:
- Configurazione di CA Service, in cui crei pool di CA private e le autorità di certificazione richieste.
- Creazione di un cluster GKE con GKE Federazione delle identità per i carichi di lavoro per le funzionalità di GKE e dei certificati mesh e il servizio CA e integrazione.
- Configurazione dell'emissione dei certificati mesh sul cluster.
- Creazione degli account di servizio client e server.
- Configurazione del server di esempio che utilizza le API xDS e le credenziali del server xDS per acquisire la configurazione di sicurezza da Cloud Service Mesh.
- Configurare il client di esempio che utilizza le credenziali xDS.
- Aggiornamento della configurazione di Cloud Service Mesh per includere la configurazione della sicurezza.
Puoi trovare esempi di codice per l'utilizzo delle credenziali xDS nelle seguenti posizioni:
Aggiorna Google Cloud CLI
Per aggiornare Google Cloud CLI, esegui il seguente comando:
gcloud components update
Imposta le variabili di ambiente
In questa guida utilizzerai i comandi Cloud Shell e le informazioni ripetute nei comandi sono rappresentate da varie variabili di ambiente. Imposta il tuo alle seguenti variabili di ambiente nell'ambiente shell eseguirai i comandi. Ogni riga di commento indica il significato della variabile di ambiente associata.
# Your project ID PROJECT_ID=PROJECT_ID # GKE cluster name and zone for this example. CLUSTER_NAME=CLUSTER_NAME ZONE=ZONE gcloud config set compute/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='default' DEMO_BACKEND_SERVICE_NAME='grpc-gke-helloworld-service' # Compute other values # Project number for your project PROJNUM=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)") # VERSION is the GKE cluster version. Install and use the most recent version # from the rapid release channel and substitute its version for # CLUSTER_VERSION, for example: # VERSION=latest available version # Note that the minimum required cluster version is 1.21.4-gke.1801. VERSION="CLUSTER_VERSION" SA_GKE=service-${PROJNUM}@container-engine-robot.iam.gserviceaccount.com
Attivare l'accesso alle API richieste
Questa sezione spiega come abilitare l'accesso alle API necessarie.
Esegui il seguente comando per abilitare Cloud Service Mesh e altre API obbligatorie per la sicurezza del mesh di servizi gRPC senza proxy.
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
Esegui il comando seguente per consentire all'account di servizio predefinito di accedere all'API di sicurezza Cloud Service Mesh.
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
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 la federazione delle identità per i carichi di lavoro per GKE. Se stai aggiornando un cluster esistente, vai al passaggio successivo. Il valore specificato per
--tags
deve corrispondere al nome passato al flag--target-tags
per il comandofirewall-rules create
nella sezione Configurazione di Cloud Service Mesh con i componenti di bilanciamento del carico di Cloud.# Create a GKE cluster with GKE managed mesh certificates. gcloud container clusters create CLUSTER_NAME \ --release-channel=rapid \ --scopes=cloud-platform \ --image-type=cos_containerd \ --machine-type=e2-standard-2 \ --zone=ZONE \ --workload-pool=PROJECT_ID.svc.id.goog \ --enable-mesh-certificates \ --cluster-version=CLUSTER_VERSION \ --enable-ip-alias \ --tags=allow-health-checks \ --workload-metadata=GKE_METADATA
La creazione del cluster potrebbe richiedere diversi minuti.
Se utilizzi un cluster esistente, attiva la federazione delle identità per i carichi di lavoro per GKE e i certificati GKE Mesh. Assicurati che il cluster sia stato creato con il flag
--enable-ip-alias
, che non può essere 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
Registra i cluster in un parco risorse
Registra il cluster che hai creato o aggiornato in Creazione di un cluster GKE con un parco risorse. La registrazione del cluster semplifica la configurazione dei cluster in più progetti.
Tieni presente che il completamento di questi passaggi può richiedere fino a dieci minuti ciascuno.
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.
Se la procedura di registrazione va a buon fine, viene visualizzato un messaggio simile al seguente:
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 va a buon fine, vengono visualizzati messaggi come i seguenti:
namespace/gke-connect created serviceaccount/connect-agent-sa created podsecuritypolicy.policy/gkeconnect-psp created role.rbac.authorization.k8s.io/gkeconnect-psp:role created rolebinding.rbac.authorization.k8s.io/gkeconnect-psp:rolebinding created role.rbac.authorization.k8s.io/agent-updater created rolebinding.rbac.authorization.k8s.io/agent-updater created role.rbac.authorization.k8s.io/gke-connect-agent-20210416-01-00 created clusterrole.rbac.authorization.k8s.io/gke-connect-impersonation-20210416-01-00 created clusterrolebinding.rbac.authorization.k8s.io/gke-connect-impersonation-20210416-01-00 created clusterrolebinding.rbac.authorization.k8s.io/gke-connect-feature-authorizer-20210416-01-00 created rolebinding.rbac.authorization.k8s.io/gke-connect-agent-20210416-01-00 created role.rbac.authorization.k8s.io/gke-connect-namespace-getter created rolebinding.rbac.authorization.k8s.io/gke-connect-namespace-getter created secret/http-proxy created deployment.apps/gke-connect-agent-20210416-01-00 created service/gke-connect-monitoring created secret/creds-gcp create
Recupera la risorsa appartenenza dal cluster:
kubectl get memberships membership -o yaml
L'output deve includere il pool Workload Identity assegnato dal parco risorse, dove PROJECT_ID è l'ID progetto:
workload_identity_pool: PROJECT_ID.svc.id.goog
Ciò significa che il cluster è stato registrato correttamente.
Creare autorità di certificazione per emettere certificati
Per emettere certificati ai tuoi pod, crea un pool di servizi CA e le seguenti autorità di certificazione (CA):
- CA radice. Si tratta della radice di attendibilità per tutti i certificati mesh emessi. Puoi utilizzare una CA radice esistente, se ne hai una. Crea la CA radice nel
Livello
enterprise
, 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 decidi di utilizzare la CA radice per emettere i certificati mesh, assicurati che la modalità di emissione basata sulla configurazione predefinita rimanga consentita.
La CA secondaria può trovarsi in una regione diversa dal cluster, ma ti consigliamo vivamente di crearla nella stessa regione del cluster per ottimizzare le prestazioni. Tuttavia, puoi creare le CA radice e subordinate in diverse regioni senza alcun impatto su prestazioni o disponibilità.
Il servizio CA è supportato per le seguenti regioni:
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 il seguente 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 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 della CA radice.
gcloud privateca pools create ROOT_CA_POOL_NAME \ --location ROOT_CA_POOL_LOCATION \ --tier enterprise
Crea una CA radice.
gcloud privateca roots create ROOT_CA_NAME --pool ROOT_CA_POOL_NAME \ --subject "CN=ROOT_CA_NAME, O=ROOT_CA_ORGANIZATION" \ --key-algorithm="ec-p256-sha256" \ --max-chain-length=1 \ --location ROOT_CA_POOL_LOCATION
Per questa configurazione di dimostrazione, utilizza i seguenti valori per le variabili:
- ROOT_CA_POOL_NAME=td_sec_pool
- ROOT_CA_NAME=pkcs2-ca
- ROOT_CA_POOL_LOCATION=us-east1
- ROOT_CA_ORGANIZATION="TestCorpLLC"
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 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 indicare al tuo cluster come emettere i certificati del mesh:apiVersion: security.cloud.google.com/v1 kind: WorkloadCertificateConfig metadata: name: default spec: # Required. The CA service that issues your certificates. certificateAuthorityConfig: certificateAuthorityServiceConfig: endpointURI: ISSUING_CA_POOL_URI # Required. The key algorithm to use. Choice of RSA or ECDSA. # # To maximize compatibility with various TLS stacks, your workloads # should use keys of the same family as your root and subordinate CAs. # # To use RSA, specify configuration such as: # keyAlgorithm: # rsa: # modulusSize: 4096 # # Currently, the only supported ECDSA curves are "P256" and "P384", and the only # supported RSA modulus sizes are 2048, 3072 and 4096. keyAlgorithm: rsa: modulusSize: 4096 # Optional. Validity duration of issued certificates, in seconds. # # Defaults to 86400 (1 day) if not specified. validityDurationSeconds: 86400 # Optional. Try to start rotating the certificate once this # percentage of validityDurationSeconds is remaining. # # Defaults to 50 if not specified. rotationWindowPercentage: 50
Sostituisci quanto segue:
- L'ID del progetto in cui viene eseguito il cluster:
PROJECT_ID
- L'URI completo della CA che emette i certificati mesh (ISSUING_CA_POOL_URI).
Può essere la tua CA subordinata (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 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
Crea un servizio gRPC senza proxy con NEG
Per la sicurezza PSM, è necessario un server gRPC proxyless in grado di utilizzare xDS per
per acquisire la configurazione di sicurezza da Cloud Service Mesh. Questo passaggio è simile alla configurazione dei servizi GKE con NEG nella guida alla configurazione del bilanciamento del carico PSM, ma utilizza il server helloworld
abilitato per xDS nell'esempio xDS nel repository grpc-java
anziché l'immagine java-example-hostname
.
Questo server viene creato ed eseguito in un contenitore creato da un'immagine openjdk:8-jdk
.
Utilizza anche la funzionalità NEG con nome, che ti consente di specificare un nome per il NEG. In questo modo, i passaggi successivi vengono semplificati perché il deployment conosce il nome del gruppo di esclusione geografica senza dover eseguire ricerche.
Di seguito è riportato un esempio completo della specifica Kubernetes del server gRPC. Tieni presente quanto segue:
- La specifica crea un account di servizio Kubernetes
example-grpc-server
, usato dal pod del server gRPC. - La specifica utilizza il campo
name
nell'annotazionecloud.google.com/neg
del per specificare il nome NEGexample-grpc-server
. - La variabile
${PROJNUM}
rappresenta il numero del progetto. - La specifica utilizza la sezione
initContainers
per eseguire un generatore di bootstrap compilare il file di bootstrap di cui ha bisogno la libreria gRPC proxyless. Questo il file di bootstrap si trova nella posizione/tmp/grpc-xds/td-grpc-bootstrap.json
della un contenitore di server denominatoexample-grpc-server
.
Aggiungi la seguente annotazione alla specifica del pod:
annotations: security.cloud.google.com/use-workload-certificates: ""
Puoi vedere il posizionamento corretto nelle specifiche complete riportate di seguito.
Al momento della creazione, a ogni pod viene assegnato un volume in /var/run/secrets/workload-spiffe-credentials
.
Questo volume contiene:
private_key.pem
è una chiave privata generata automaticamente.certificates.pem
è un bundle di certificati in formato PEM che possono essere presentati a un altro pod come catena di certificati client o utilizzato come server della catena di certificati.ca_certificates.pem
è un insieme di certificati in formato PEM da utilizzare come ancore di attendibilità per convalidare la catena di certificati client presentata da un altro pod o la catena di certificati del server ricevuta quando ci si connette a un altro pod.
Tieni presente che ca_certificates.pem
contiene i certificati per il dominio di attendibilità locale per i carichi di lavoro, ovvero il pool di carichi di lavoro del cluster.
Il certificato finale in certificates.pem
contiene la seguente affermazione di identità SPIFFE in testo normale:
spiffe://WORKLOAD_POOL/ns/NAMESPACE/sa/KUBERNETES_SERVICE_ACCOUNT
In questa asserzione:
- WORKLOAD_POOL è il nome del pool di carichi di lavoro del cluster.
- NAMESPACE è lo spazio dei nomi del tuo account di servizio Kubernetes.
- KUBERNETES_SERVICE_ACCOUNT è il nome del tuo account di servizio Kubernetes.
Le seguenti istruzioni relative alla tua lingua creano la specifica da utilizzare in questo esempio.
Java
Esegui il seguente comando per assicurarti che il numero del progetto sia impostato correttamente:
if [ -z "$PROJNUM" ] ; then export PROJNUM=$(gcloud projects describe $(gcloud info --format='value(config.project)') --format="value(projectNumber)") ; fi ; echo $PROJNUM
Crea la specifica:
cat << EOF > example-grpc-server.yaml apiVersion: v1 kind: ServiceAccount metadata: name: example-grpc-server namespace: default annotations: iam.gke.io/gcp-service-account: ${PROJNUM}-compute@developer.gserviceaccount.com --- apiVersion: v1 kind: Service metadata: name: example-grpc-server namespace: default labels: k8s-app: example-grpc-server annotations: cloud.google.com/neg: '{"exposed_ports":{"8080":{"name": "example-grpc-server"}}}' spec: ports: - name: helloworld port: 8080 protocol: TCP targetPort: 50051 selector: k8s-app: example-grpc-server type: ClusterIP --- apiVersion: apps/v1 kind: Deployment metadata: name: example-grpc-server namespace: default labels: k8s-app: example-grpc-server spec: replicas: 1 selector: matchLabels: k8s-app: example-grpc-server strategy: {} template: metadata: annotations: security.cloud.google.com/use-workload-certificates: "" labels: k8s-app: example-grpc-server spec: containers: - image: openjdk:8-jdk imagePullPolicy: IfNotPresent name: example-grpc-server command: - /bin/sleep - inf env: - name: GRPC_XDS_BOOTSTRAP value: "/tmp/grpc-xds/td-grpc-bootstrap.json" ports: - protocol: TCP containerPort: 50051 resources: limits: cpu: 800m memory: 512Mi requests: cpu: 100m memory: 512Mi volumeMounts: - name: grpc-td-conf mountPath: /tmp/grpc-xds/ initContainers: - name: grpc-td-init image: gcr.io/trafficdirector-prod/td-grpc-bootstrap:0.16.0 imagePullPolicy: Always args: - --config-mesh-experimental - "grpc-mesh" - --output - "/tmp/bootstrap/td-grpc-bootstrap.json" - --node-metadata=app=helloworld resources: limits: cpu: 100m memory: 100Mi requests: cpu: 10m memory: 100Mi volumeMounts: - name: grpc-td-conf mountPath: /tmp/bootstrap/ serviceAccountName: example-grpc-server volumes: - name: grpc-td-conf emptyDir: medium: Memory EOF
C++
Esegui questo comando per assicurarti che il numero del progetto sia impostato correttamente:
if [ -z "$PROJNUM" ] ; then export PROJNUM=$(gcloud projects describe $(gcloud info --format='value(config.project)') --format="value(projectNumber)") ; fi ; echo $PROJNUM
Crea la specifica:
cat << EOF > example-grpc-server.yaml apiVersion: v1 kind: ServiceAccount metadata: name: example-grpc-server namespace: default annotations: iam.gke.io/gcp-service-account: ${PROJNUM}-compute@developer.gserviceaccount.com --- apiVersion: v1 kind: Service metadata: name: example-grpc-server namespace: default labels: k8s-app: example-grpc-server annotations: cloud.google.com/neg: '{"exposed_ports":{"8080":{"name": "example-grpc-server"}}}' spec: ports: - name: helloworld port: 8080 protocol: TCP targetPort: 50051 selector: k8s-app: example-grpc-server type: ClusterIP --- apiVersion: apps/v1 kind: Deployment metadata: name: example-grpc-server namespace: default labels: k8s-app: example-grpc-server spec: replicas: 1 selector: matchLabels: k8s-app: example-grpc-server strategy: {} template: metadata: annotations: security.cloud.google.com/use-workload-certificates: "" labels: k8s-app: example-grpc-server spec: containers: - image: phusion/baseimage:18.04-1.0.0 imagePullPolicy: IfNotPresent name: example-grpc-server command: - /bin/sleep - inf env: - name: GRPC_XDS_BOOTSTRAP value: "/tmp/grpc-xds/td-grpc-bootstrap.json" ports: - protocol: TCP containerPort: 50051 resources: limits: cpu: 8 memory: 8Gi requests: cpu: 300m memory: 512Mi volumeMounts: - name: grpc-td-conf mountPath: /tmp/grpc-xds/ initContainers: - name: grpc-td-init image: gcr.io/trafficdirector-prod/td-grpc-bootstrap:0.16.0 imagePullPolicy: Always args: - --config-mesh-experimental - "grpc-mesh" - --output - "/tmp/bootstrap/td-grpc-bootstrap.json" - --node-metadata=app=helloworld resources: limits: cpu: 100m memory: 100Mi requests: cpu: 10m memory: 100Mi volumeMounts: - name: grpc-td-conf mountPath: /tmp/bootstrap/ serviceAccountName: example-grpc-server volumes: - name: grpc-td-conf emptyDir: medium: Memory EOF
Python
Esegui il seguente comando per assicurarti che il numero del progetto sia impostato correttamente:
if [ -z "$PROJNUM" ] ; then export PROJNUM=$(gcloud projects describe $(gcloud info --format='value(config.project)') --format="value(projectNumber)") ; fi ; echo $PROJNUM
Crea la specifica:
cat << EOF > example-grpc-server.yaml apiVersion: v1 kind: ServiceAccount metadata: name: example-grpc-server namespace: default annotations: iam.gke.io/gcp-service-account: ${PROJNUM}-compute@developer.gserviceaccount.com --- apiVersion: v1 kind: Service metadata: name: example-grpc-server namespace: default labels: k8s-app: example-grpc-server annotations: cloud.google.com/neg: '{"exposed_ports":{"8080":{"name": "example-grpc-server"}}}' spec: ports: - name: helloworld port: 8080 protocol: TCP targetPort: 50051 selector: k8s-app: example-grpc-server type: ClusterIP --- apiVersion: apps/v1 kind: Deployment metadata: name: example-grpc-server namespace: default labels: k8s-app: example-grpc-server spec: replicas: 1 selector: matchLabels: k8s-app: example-grpc-server strategy: {} template: metadata: annotations: security.cloud.google.com/use-workload-certificates: "" labels: k8s-app: example-grpc-server spec: containers: - image: phusion/baseimage:18.04-1.0.0 imagePullPolicy: IfNotPresent name: example-grpc-server command: - /bin/sleep - inf env: - name: GRPC_XDS_BOOTSTRAP value: "/tmp/grpc-xds/td-grpc-bootstrap.json" ports: - protocol: TCP containerPort: 50051 resources: limits: cpu: 8 memory: 8Gi requests: cpu: 300m memory: 512Mi volumeMounts: - name: grpc-td-conf mountPath: /tmp/grpc-xds/ initContainers: - name: grpc-td-init image: gcr.io/trafficdirector-prod/td-grpc-bootstrap:0.16.0 imagePullPolicy: Always args: - --config-mesh-experimental - "grpc-mesh" - --output - "/tmp/bootstrap/td-grpc-bootstrap.json" - --node-metadata=app=helloworld resources: limits: cpu: 100m memory: 100Mi requests: cpu: 10m memory: 100Mi volumeMounts: - name: grpc-td-conf mountPath: /tmp/bootstrap/ serviceAccountName: example-grpc-server volumes: - name: grpc-td-conf emptyDir: medium: Memory EOF
Vai
Esegui questo comando per assicurarti che il numero del progetto sia impostato correttamente:
if [ -z "$PROJNUM" ] ; then export PROJNUM=$(gcloud projects describe $(gcloud info --format='value(config.project)') --format="value(projectNumber)") ; fi ; echo $PROJNUM
Crea la specifica:
cat << EOF > example-grpc-server.yaml apiVersion: v1 kind: ServiceAccount metadata: name: example-grpc-server namespace: default annotations: iam.gke.io/gcp-service-account: ${PROJNUM}-compute@developer.gserviceaccount.com --- apiVersion: v1 kind: Service metadata: name: example-grpc-server namespace: default labels: k8s-app: example-grpc-server annotations: cloud.google.com/neg: '{"exposed_ports":{"8080":{"name": "example-grpc-server"}}}' spec: ports: - name: helloworld port: 8080 protocol: TCP targetPort: 50051 selector: k8s-app: example-grpc-server type: ClusterIP --- apiVersion: apps/v1 kind: Deployment metadata: name: example-grpc-server namespace: default labels: k8s-app: example-grpc-server spec: replicas: 1 selector: matchLabels: k8s-app: example-grpc-server strategy: {} template: metadata: annotations: security.cloud.google.com/use-workload-certificates: "" labels: k8s-app: example-grpc-server spec: containers: - image: golang:1.16-alpine imagePullPolicy: IfNotPresent name: example-grpc-server command: - /bin/sleep - inf env: - name: GRPC_XDS_BOOTSTRAP value: "/tmp/grpc-xds/td-grpc-bootstrap.json" ports: - protocol: TCP containerPort: 50051 resources: limits: cpu: 8 memory: 8Gi requests: cpu: 300m memory: 512Mi volumeMounts: - name: grpc-td-conf mountPath: /tmp/grpc-xds/ initContainers: - name: grpc-td-init image: gcr.io/trafficdirector-prod/td-grpc-bootstrap:0.16.0 imagePullPolicy: Always args: - --config-mesh-experimental - "grpc-mesh" - --output - "/tmp/bootstrap/td-grpc-bootstrap.json" - --node-metadata=app=helloworld resources: limits: cpu: 100m memory: 100Mi requests: cpu: 10m memory: 100Mi volumeMounts: - name: grpc-td-conf mountPath: /tmp/bootstrap/ serviceAccountName: example-grpc-server volumes: - name: grpc-td-conf emptyDir: medium: Memory EOF
Completa la procedura come segue.
Applica la specifica:
kubectl apply -f example-grpc-server.yaml
Concedi i ruoli richiesti all'account di servizio:
gcloud iam service-accounts add-iam-policy-binding \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:${PROJECT_ID}.svc.id.goog[default/example-grpc-server]" \ ${PROJNUM}-compute@developer.gserviceaccount.com gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member "serviceAccount:${PROJECT_ID}.svc.id.goog[default/example-grpc-server]" \ --role roles/trafficdirector.client
Esegui questi comandi per verificare che il servizio e il pod siano stati creati correttamente:
kubectl get deploy/example-grpc-server kubectl get svc/example-grpc-server
Verifica che il nome del NEG sia corretto:
gcloud compute network-endpoint-groups list \ --filter "name=example-grpc-server" --format "value(name)"
Il comando dovrebbe restituire il nome NEG
example-grpc-server
.
Configura Cloud Service Mesh con i componenti di bilanciamento del carico di Google Cloud
I passaggi descritti in questa sezione sono simili a quelli descritti in Configurazione di Cloud Service Mesh con componenti di bilanciamento del carico, ma sono presenti alcune modifiche, come descritto nelle sezioni seguenti.
Crea il controllo di integrità, la regola firewall e il servizio di backend
Quando il server gRPC è configurato per utilizzare mTLS, i controlli di integrità gRPC non funzionano perché il client di controllo dell'integrità non può presentare un certificato client valido ai server. Puoi risolvere il problema in due modi.
Nel primo approccio, il server crea un'ulteriore porta di pubblicazione designata come porta di controllo di integrità. È associato a un attributo servizio di controllo di integrità, come testo normale o TLS.
Il helloworld
server di esempio xDS utilizza PORT_NUMBER
+ 1 come porta per il controllo di integrità in testo normale. L'esempio utilizza
50052 come porta per il controllo di integrità, perché 50051 è il server delle applicazioni gRPC
una porta.
Nel secondo approccio, configuri il controllo di integrità in modo da controllare solo TCP. e la connettività alla porta di gestione dell'applicazione. Questo controlla solo la connettività e genera anche traffico non necessario sul server quando gli handshake TLS non vanno a buon fine. Per questo motivo, ti consigliamo di utilizzare il primo approccio.
Crea il controllo di integrità. Tieni presente che i controlli di integrità non vengono avviati finché non crei e avvii il server.
Se stai creando una porta di servizio designata per il controllo di integrità, che è l'approccio consigliato, utilizza questo comando:
gcloud compute health-checks create grpc grpc-gke-helloworld-hc \ --enable-logging --port 50052
Se stai creando un controllo di integrità TCP, che sconsigliamo, utilizza questo comando:
gcloud compute health-checks create tcp grpc-gke-helloworld-hc \ --use-serving-port
Crea il firewall. Assicurati che il valore di
--target-tags
corrisponda a fornito per--tags
nella sezione Creare o aggiornare un cluster GKE.gcloud compute firewall-rules create grpc-gke-allow-health-checks \ --network default --action allow --direction INGRESS \ --source-ranges 35.191.0.0/16,130.211.0.0/22 \ --target-tags allow-health-checks \ --rules tcp:50051-50052
Crea il servizio di backend:
gcloud compute backend-services create grpc-gke-helloworld-service \ --global \ --load-balancing-scheme=INTERNAL_SELF_MANAGED \ --protocol=GRPC \ --health-checks grpc-gke-helloworld-hc
Collega il NEG al servizio di backend:
gcloud compute backend-services add-backend grpc-gke-helloworld-service \ --global \ --network-endpoint-group example-grpc-server \ --network-endpoint-group-zone ${ZONE} \ --balancing-mode RATE \ --max-rate-per-endpoint 5
Crea le risorse Mesh
e GRPCRoute
Questa operazione è simile alla configurazione delle risorse Mesh
e GRPCRoute
in
Configurare i servizi gRPC proxyless.
Crea la specifica
Mesh
e salvala in un file denominatomesh.yaml
.name: grpc-mesh
Importa la risorsa
Mesh
dalla specifica.gcloud network-services meshes import grpc-mesh \ --source=mesh.yaml \ --location=global
Crea la specifica
GRPCRoute
e salvala in un file denominatogrpc_route.yaml
.name: helloworld-grpc-route hostnames: - helloworld-gke:8000 meshes: - projects/PROJECT_NUMBER/locations/global/meshes/grpc-mesh rules: - action: destinations: - serviceName: projects/PROJECT_NUMBER/locations/global/backendServices/grpc-gke-helloworld-service
Importa la risorsa
GRPCRoute
dalla specificagrpc_route.yaml
.gcloud network-services grpc-routes import helloworld-grpc-route \ --source=grpc_route.yaml \ --location=global
Configura Cloud Service Mesh con sicurezza gRPC senza proxy
Questo esempio mostra come configurare mTLS lato client e lato server.
Formato per i riferimenti alle norme
Tieni presente il seguente formato obbligatorio per fare riferimento ai criteri TLS del server e TLS del client:
projects/PROJECT_ID/locations/global/[serverTlsPolicies|clientTlsPolicies]/[server-tls-policy|client-mtls-policy]
Ad esempio:
projects/PROJECT_ID/locations/global/serverTlsPolicies/server-tls-policy
projects/PROJECT_ID/locations/global/clientTlsPolicies/client-mtls-policy
Configurare mTLS sul lato server
Per prima cosa, crei un criterio TLS del server. Il criterio chiede al lato server gRPC di
utilizza la configurazione del plug-in certificateProvicerInstance
identificata dal nome
google_cloud_private_spiffe
per il certificato di identità, che fa parte del
serverCertificate
. La sezione mtlsPolicy
indica la sicurezza mTLS e utilizza
lo stesso google_cloud_private_spiffe
della configurazione del plug-in
clientValidationCa
, che è la specifica del certificato radice (convalida).
A questo punto, crea un criterio endpoint. Questo specifica che un backend, ad esempio un server gRPC, che utilizza la porta 50051
con eventuali etichette dei metadati o nessuna, riceve il criterio TLS del server associato denominato server-mtls-policy
. Sei tu a specificare i metadati
etichette utilizzando MATCH_ALL
o un valore supportato. Puoi trovare le etichette dei metadati supportate nel campo endpointMatcher.metadataLabelMatcher.metadataLabelMatchCriteria
del documento NetworkServicesEndpointPolicy. Crea il criterio endpoint con un file temporaneoep-mtls-psms.yaml
contenente i valori per la risorsa del criterio endpoint utilizzando il criterio già definito.
Crea un file temporaneo
server-mtls-policy.yaml
nella directory attuale con i valori della risorsa del criterio TLS del server:name: "projects/PROJECT_ID/locations/global/serverTlsPolicies/server-mtls-policy" serverCertificate: certificateProviderInstance: pluginInstance: google_cloud_private_spiffe mtlsPolicy: clientValidationCa: - certificateProviderInstance: pluginInstance: google_cloud_private_spiffe
Crea una risorsa del criterio TLS del server denominata
server-mtls-policy
importando il file temporaneoserver-mtls-policy.yaml
:gcloud network-security server-tls-policies import server-mtls-policy \ --source=server-mtls-policy.yaml --location=global
Crea il criterio endpoint creando il file temporaneo
ep-mtls-psms.yaml
:name: "ep-mtls-psms" type: "GRPC_SERVER" serverTlsPolicy: "projects/PROJECT_ID/locations/global/serverTlsPolicies/server-mtls-policy" trafficPortSelector: ports: - "50051" endpointMatcher: metadataLabelMatcher: metadataLabelMatchCriteria: "MATCH_ALL" metadataLabels: - labelName: app labelValue: helloworld
Crea la risorsa del criterio dell'endpoint importando il file
ep-mtls-psms.yaml
:gcloud beta network-services endpoint-policies import ep-mtls-psms \ --source=ep-mtls-psms.yaml --location=global
Configurare mTLS lato client
Il criterio di sicurezza lato client è collegato al servizio di backend. Quando un client accede a un backend (il server gRPC) tramite il servizio di backend, il criterio di sicurezza lato client allegato viene inviato al client.
Crea i contenuti della risorsa del criterio TLS del client in un file temporaneo denominato
client-mtls-policy.yaml
nella directory attuale:name: "client-mtls-policy" clientCertificate: certificateProviderInstance: pluginInstance: google_cloud_private_spiffe serverValidationCa: - certificateProviderInstance: pluginInstance: google_cloud_private_spiffe
Crea la risorsa del criterio TLS del client denominata
client-mtls-policy
importando il file temporaneoclient-mtls-policy.yaml
:gcloud network-security client-tls-policies import client-mtls-policy \ --source=client-mtls-policy.yaml --location=global
Crea uno snippet in un file temporaneo per fare riferimento a questo criterio e aggiungi dettagli per
subjectAltNames
nel messaggioSecuritySettings
come nell' dall'esempio seguente. Sostituisci${PROJECT_ID}
con il valore dell'ID progetto, ovvero il valore della variabile di ambiente${PROJECT_ID}
descritta in precedenza. Tieni presente cheexample-grpc-server
insubjectAltNames
è il nome dell'account di servizio Kubernetes utilizzato per il pod del server gRPC nella specifica di deployment.if [ -z "$PROJECT_ID" ] ; then echo Please make sure PROJECT_ID is set. ; fi cat << EOF > client-security-settings.yaml securitySettings: clientTlsPolicy: projects/${PROJECT_ID}/locations/global/clientTlsPolicies/client-mtls-policy subjectAltNames: - "spiffe://${PROJECT_ID}.svc.id.goog/ns/default/sa/example-grpc-server" EOF
Aggiungi il messaggio
securitySettings
al servizio di backend che hai già è stato creato. Questi passaggi esportano i contenuti attuali del servizio di backend, aggiungi clientsecuritySetting
e reimporta i nuovi contenuti da aggiornare il servizio di backend.gcloud compute backend-services export grpc-gke-helloworld-service --global \ --destination=/tmp/grpc-gke-helloworld-service.yaml cat /tmp/grpc-gke-helloworld-service.yaml client-security-settings.yaml \ >/tmp/grpc-gke-helloworld-service1.yaml gcloud compute backend-services import grpc-gke-helloworld-service --global \ --source=/tmp/grpc-gke-helloworld-service1.yaml -q
Verificare la configurazione
La configurazione di Cloud Service Mesh è stata completata, includendo la sicurezza lato client. Successivamente, preparerai ed eseguirai i carichi di lavoro server e client. L'esempio termina qui.
Crea un client gRPC senza proxy
Questo passaggio è simile al passaggio precedente Creare un servizio gRPC senza proxy.
Utilizzi il client helloworld
abilitato per xDS dell'esempio xDS
nel repository grpc-java
. Puoi creare ed eseguire il client in un container
generato da un'immagine openjdk:8-jdk
. La specifica Kubernetes del client gRPC
seguire.
- Crea un account di servizio Kubernetes
example-grpc-client
utilizzato il pod del client gRPC. ${PROJNUM}
rappresenta il numero del progetto e deve essere sostituito con il numero effettivo.
Aggiungi la seguente annotazione alla specifica del pod:
annotations: security.cloud.google.com/use-workload-certificates: ""
Al momento della creazione, a ogni pod viene assegnato un volume in /var/run/secrets/workload-spiffe-credentials
.
Questo volume contiene:
private_key.pem
è una chiave privata generata automaticamente.certificates.pem
è un bundle di certificati in formato PEM che possono essere presentati a un altro pod come catena di certificati client o utilizzato come server della catena di certificati.ca_certificates.pem
è un pacchetto di certificati in formato PEM da utilizzare come attendibilità gli ancoraggi durante la convalida della catena di certificati client presentata da un altro pod, o la catena di certificati del server ricevuta durante la connessione a un altro pod.
Tieni presente che ca_certificates.pem
contiene i certificati radice per l'amministratore locale
attendibile per i carichi di lavoro, ovvero il pool di carichi di lavoro del cluster.
Il certificato finale in certificates.pem
contiene la seguente affermazione di identità SPIFFE in testo normale:
spiffe://WORKLOAD_POOL/ns/NAMESPACE/sa/KUBERNETES_SERVICE_ACCOUNT
In questa asserzione:
- WORKLOAD_POOL è il nome del pool di carichi di lavoro del cluster.
- NAMESPACE è il nome del tuo account di servizio Kubernetes.
- KUBERNETES_SERVICE_ACCOUNT è lo spazio dei nomi del tuo cluster Kubernetes l'account di servizio.
Le istruzioni riportate di seguito per la tua lingua creano la specifica da utilizzare in questo esempio.
Java
Esegui il seguente comando per assicurarti che il numero del progetto sia impostato correttamente:
if [ -z "$PROJNUM" ] ; then export PROJNUM=$(gcloud projects describe $(gcloud info --format='value(config.project)') --format="value(projectNumber)") ; fi ; echo $PROJNUM
Crea la seguente specifica:
cat << EOF > example-grpc-client.yaml apiVersion: v1 kind: ServiceAccount metadata: name: example-grpc-client namespace: default annotations: iam.gke.io/gcp-service-account: ${PROJNUM}-compute@developer.gserviceaccount.com --- apiVersion: apps/v1 kind: Deployment metadata: name: example-grpc-client namespace: default labels: k8s-app: example-grpc-client spec: replicas: 1 selector: matchLabels: k8s-app: example-grpc-client strategy: {} template: metadata: annotations: security.cloud.google.com/use-workload-certificates: "" labels: k8s-app: example-grpc-client spec: containers: - image: openjdk:8-jdk imagePullPolicy: IfNotPresent name: example-grpc-client command: - /bin/sleep - inf env: - name: GRPC_XDS_BOOTSTRAP value: "/tmp/grpc-xds/td-grpc-bootstrap.json" resources: limits: cpu: 800m memory: 512Mi requests: cpu: 100m memory: 512Mi volumeMounts: - name: grpc-td-conf mountPath: /tmp/grpc-xds/ initContainers: - name: grpc-td-init image: gcr.io/trafficdirector-prod/td-grpc-bootstrap:0.16.0 imagePullPolicy: Always args: - --config-mesh-experimental - "grpc-mesh" - --output - --config-mesh-experimental - "grpc-mesh" - "/tmp/bootstrap/td-grpc-bootstrap.json" resources: limits: cpu: 100m memory: 100Mi requests: cpu: 10m memory: 100Mi volumeMounts: - name: grpc-td-conf mountPath: /tmp/bootstrap/ serviceAccountName: example-grpc-client volumes: - name: grpc-td-conf emptyDir: medium: Memory EOF
C++
Esegui questo comando per assicurarti che il numero del progetto sia impostato correttamente:
if [ -z "$PROJNUM" ] ; then export PROJNUM=$(gcloud projects describe $(gcloud info --format='value(config.project)') --format="value(projectNumber)") ; fi ; echo $PROJNUM
Crea la seguente specifica:
cat << EOF > example-grpc-client.yaml apiVersion: v1 kind: ServiceAccount metadata: name: example-grpc-client namespace: default annotations: iam.gke.io/gcp-service-account: ${PROJNUM}-compute@developer.gserviceaccount.com --- apiVersion: apps/v1 kind: Deployment metadata: name: example-grpc-client namespace: default labels: k8s-app: example-grpc-client spec: replicas: 1 selector: matchLabels: k8s-app: example-grpc-client strategy: {} template: metadata: annotations: security.cloud.google.com/use-workload-certificates: "" labels: k8s-app: example-grpc-client spec: containers: - image: phusion/baseimage:18.04-1.0.0 imagePullPolicy: IfNotPresent name: example-grpc-client command: - /bin/sleep - inf env: - name: GRPC_XDS_BOOTSTRAP value: "/tmp/grpc-xds/td-grpc-bootstrap.json" resources: limits: cpu: 8 memory: 8Gi requests: cpu: 300m memory: 512Mi volumeMounts: - name: grpc-td-conf mountPath: /tmp/grpc-xds/ initContainers: - name: grpc-td-init image: gcr.io/trafficdirector-prod/td-grpc-bootstrap:0.16.0 imagePullPolicy: Always args: - --config-mesh-experimental - "grpc-mesh" - --output - "/tmp/bootstrap/td-grpc-bootstrap.json" resources: limits: cpu: 100m memory: 100Mi requests: cpu: 10m memory: 100Mi volumeMounts: - name: grpc-td-conf mountPath: /tmp/bootstrap/ serviceAccountName: example-grpc-client volumes: - name: grpc-td-conf emptyDir: medium: Memory EOF
Python
Esegui questo comando per assicurarti che il numero del progetto sia corretto imposta:
if [ -z "$PROJNUM" ] ; then export PROJNUM=$(gcloud projects describe $(gcloud info --format='value(config.project)') --format="value(projectNumber)") ; fi ; echo $PROJNUM
Crea la seguente specifica:
cat << EOF > example-grpc-client.yaml apiVersion: v1 kind: ServiceAccount metadata: name: example-grpc-client namespace: default annotations: iam.gke.io/gcp-service-account: ${PROJNUM}-compute@developer.gserviceaccount.com --- apiVersion: apps/v1 kind: Deployment metadata: name: example-grpc-client namespace: default labels: k8s-app: example-grpc-client spec: replicas: 1 selector: matchLabels: k8s-app: example-grpc-client strategy: {} template: metadata: annotations: security.cloud.google.com/use-workload-certificates: "" labels: k8s-app: example-grpc-client spec: containers: - image: phusion/baseimage:18.04-1.0.0 imagePullPolicy: IfNotPresent name: example-grpc-client command: - /bin/sleep - inf env: - name: GRPC_XDS_BOOTSTRAP value: "/tmp/grpc-xds/td-grpc-bootstrap.json" resources: limits: cpu: 8 memory: 8Gi requests: cpu: 300m memory: 512Mi volumeMounts: - name: grpc-td-conf mountPath: /tmp/grpc-xds/ initContainers: - name: grpc-td-init image: gcr.io/trafficdirector-prod/td-grpc-bootstrap:0.16.0 imagePullPolicy: Always args: - --config-mesh-experimental - "grpc-mesh" - --output - "/tmp/bootstrap/td-grpc-bootstrap.json" resources: limits: cpu: 100m memory: 100Mi requests: cpu: 10m memory: 100Mi volumeMounts: - name: grpc-td-conf mountPath: /tmp/bootstrap/ serviceAccountName: example-grpc-client volumes: - name: grpc-td-conf emptyDir: medium: Memory EOF
Vai
Esegui il seguente comando per assicurarti che il numero del progetto sia impostato correttamente:
if [ -z "$PROJNUM" ] ; then export PROJNUM=$(gcloud projects describe $(gcloud info --format='value(config.project)') --format="value(projectNumber)") ; fi ; echo $PROJNUM
Crea la seguente specifica:
cat << EOF > example-grpc-client.yaml apiVersion: v1 kind: ServiceAccount metadata: name: example-grpc-client namespace: default annotations: iam.gke.io/gcp-service-account: ${PROJNUM}-compute@developer.gserviceaccount.com --- apiVersion: apps/v1 kind: Deployment metadata: name: example-grpc-client namespace: default labels: k8s-app: example-grpc-client spec: replicas: 1 selector: matchLabels: k8s-app: example-grpc-client strategy: {} template: metadata: annotations: security.cloud.google.com/use-workload-certificates: "" labels: k8s-app: example-grpc-client spec: containers: - image: golang:1.16-alpine imagePullPolicy: IfNotPresent name: example-grpc-client command: - /bin/sleep - inf env: - name: GRPC_XDS_BOOTSTRAP value: "/tmp/grpc-xds/td-grpc-bootstrap.json" resources: limits: cpu: 8 memory: 8Gi requests: cpu: 300m memory: 512Mi volumeMounts: - name: grpc-td-conf mountPath: /tmp/grpc-xds/ initContainers: - name: grpc-td-init image: gcr.io/trafficdirector-prod/td-grpc-bootstrap:0.16.0 imagePullPolicy: Always args: - --config-mesh-experimental - "grpc-mesh" - --output - "/tmp/bootstrap/td-grpc-bootstrap.json" resources: limits: cpu: 100m memory: 100Mi requests: cpu: 10m memory: 100Mi volumeMounts: - name: grpc-td-conf mountPath: /tmp/bootstrap/ serviceAccountName: example-grpc-client volumes: - name: grpc-td-conf emptyDir: medium: Memory EOF
Completa la procedura come descritto di seguito.
Applica la specifica:
kubectl apply -f example-grpc-client.yaml
Concedi i ruoli richiesti all'account di servizio:
gcloud iam service-accounts add-iam-policy-binding \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:${PROJECT_ID}.svc.id.goog[default/example-grpc-client]" \ ${PROJNUM}-compute@developer.gserviceaccount.com gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member "serviceAccount:${PROJECT_ID}.svc.id.goog[default/example-grpc-client]" \ --role roles/trafficdirector.client
Verifica che il pod del client sia in esecuzione:
kubectl get pods
Il comando restituisce un testo simile al seguente:
NAMESPACE NAME READY STATUS RESTARTS AGE default example-grpc-client-7c969bb997-9fzjv 1/1 Running 0 104s [..skip..]
Esegui il server
Crea ed esegui il server helloworld
abilitato per xDS nel pod del server che hai creato
in precedenza.
Java
Recupera il nome del pod creato per il servizio
example-grpc-server
:kubectl get pods | grep example-grpc-server
Visualizzi un feedback come il seguente:
default example-grpc-server-77548868d-l9hmf 1/1 Running 0 105s
Apri una shell nel pod del server:
kubectl exec -it example-grpc-server-77548868d-l9hmf -- /bin/bash
Nella shell, verifica che il file di bootstrap
/tmp/grpc-xds/td-grpc-bootstrap.json
corrisponde allo schema descritto in sezione File di bootstrap.Scarica gRPC Java versione 1.42.1 e crea il server
xds-hello-world
un'applicazione.curl -L https://github.com/grpc/grpc-java/archive/v1.42.1.tar.gz | tar -xz cd grpc-java-1.42.1/examples/example-xds ../gradlew --no-daemon installDist
Esegui il server con il flag
--xds-creds
per indicare la sicurezza abilitata per xDS utilizzando50051
come porta di ascolto exds-server
come server nome identificativo:./build/install/example-xds/bin/xds-hello-world-server --xds-creds 50051 xds-server
Dopo che il server ha ottenuto la configurazione necessaria Cloud Service Mesh, viene visualizzato il seguente output:
Listening on port 50051 plain text health service listening on port 50052
C++
Recupera il nome del pod creato per il servizio
example-grpc-server
:kubectl get pods | grep example-grpc-server
Visualizzi un feedback come il seguente:
default example-grpc-server-77548868d-l9hmf 1/1 Running 0 105s
Apri una shell nel pod del server:
kubectl exec -it example-grpc-server-77548868d-l9hmf -- /bin/bash
Nella shell, verifica che il file di bootstrap in
/tmp/grpc-xds/td-grpc-bootstrap.json
corrisponda allo schema descritto nella sezione File di bootstrap.Scarica gRPC C++ e crea l'applicazione server
xds-hello-world
.apt-get update -y && \ apt-get install -y \ build-essential \ clang \ python3 \ python3-dev curl -L https://github.com/grpc/grpc/archive/master.tar.gz | tar -xz cd grpc-master tools/bazel build examples/cpp/helloworld:xds_greeter_server
Esegui il server utilizzando
50051
come porta di ascolto exds_greeter_server
come nome di identificazione del server:bazel-bin/examples/cpp/helloworld/xds_greeter_server --port=50051 --maintenance_port=50052 --secure
Per eseguire il server senza credenziali, puoi specificare quanto segue:
bazel-bin/examples/cpp/helloworld/xds_greeter_server --nosecure
Dopo che il server ha ottenuto la configurazione necessaria da Cloud Service Mesh, viene visualizzato il seguente output:
Listening on port 50051 plain text health service listening on port 50052
Python
Recupera il nome del pod creato per il servizio
example-grpc-server
:kubectl get pods | grep example-grpc-server
Visualizzi un feedback come il seguente:
default example-grpc-server-77548868d-l9hmf 1/1 Running 0 105s
Apri una shell nel pod del server:
kubectl exec -it example-grpc-server-77548868d-l9hmf -- /bin/bash
Nella shell, verifica che il file di bootstrap in
/tmp/grpc-xds/td-grpc-bootstrap.json
corrisponda allo schema descritto nella sezione File di bootstrap.Scarica gRPC Python versione 1.41.0 e crea l'applicazione di esempio.
apt-get update -y
apt-get install -y python3 python3-pip
curl -L https://github.com/grpc/grpc/archive/v1.41.x.tar.gz | tar -xz
cd grpc-1.41.x/examples/python/xds/
python3 -m virtualenv venv
source venv/bin/activate
python3 -m pip install -r requirements.txt
Esegui il server con il flag
--xds-creds
per indicare che supporta xDS usando50051
come porta di ascolto.python3 server.py 50051 --xds-creds
Dopo che il server ha ottenuto la configurazione necessaria Cloud Service Mesh, viene visualizzato il seguente output:
2021-05-06 16:10:34,042: INFO Running with xDS Server credentials 2021-05-06 16:10:34,043: INFO Greeter server listening on port 50051 2021-05-06 16:10:34,046: INFO Maintenance server listening on port 50052
Vai
Recupera il nome del pod creato per il servizio
example-grpc-server
:kubectl get pods | grep example-grpc-server
Visualizzi un feedback come il seguente:
default example-grpc-server-77548868d-l9hmf 1/1 Running 0 105s
Apri una shell nel pod del server:
kubectl exec -it example-grpc-server-77548868d-l9hmf -- /bin/sh
Nella shell, verifica che il file di bootstrap in
/tmp/grpc-xds/td-grpc-bootstrap.json
corrisponda allo schema descritto nella sezione File di bootstrap.Scaricare gRPC Go versione 1.41.0 e passare alla directory contenente l'applicazione server
xds-hello-world
.apk add curl curl -L https://github.com/grpc/grpc-go/archive/v1.42.0.tar.gz | tar -xz cd grpc-go-1.42.0/examples/features/xds/server
Compila ed esegui il server con il flag
--xds_creds
per indicare la sicurezza abilitata per xDS, utilizzando50051
come porta di ascolto:GRPC_GO_LOG_VERBOSITY_LEVEL=2 GRPC_GO_LOG_SEVERITY_LEVEL="info" \ go run main.go \ -xds_creds \ -port 50051
Dopo che il server ha ottenuto la configurazione necessaria Cloud Service Mesh, viene visualizzato il seguente output:
Using xDS credentials... Serving GreeterService on 0.0.0.0:50051 and HealthService on 0.0.0.0:50052
Il processo di controllo di integrità richiede da 3 a 5 minuti per verificare che il servizio sia operativo dopo l'avvio del server.
Esegui il client e verifica la configurazione
Compila ed esegui il client helloworld
abilitato per xDS nel pod client creato
in precedenza.
Java
Ottieni il nome del pod del client:
kubectl get pods | grep example-grpc-client
Visualizzi un feedback come questo:
default example-grpc-client-7c969bb997-9fzjv 1/1 Running 0 105s
Apri una shell sul pod del client:
kubectl exec -it example-grpc-client-7c969bb997-9fzjv -- /bin/bash
Nella shell dei comandi, scarica la versione 1.42.1 di gRPC Java e compila l'applicazione client
xds-hello-world
.curl -L https://github.com/grpc/grpc-java/archive/v1.42.1.tar.gz | tar -xz cd grpc-java-1.42.1/examples/example-xds ../gradlew --no-daemon installDist
Esegui il client con il flag
--xds-creds
per indicare la sicurezza abilitata per xDS, il nome del client e la stringa di connessione di destinazione:./build/install/example-xds/bin/xds-hello-world-client --xds-creds xds-client \ xds:///helloworld-gke:8000
Dovresti visualizzare un output simile al seguente:
Greeting: Hello xds-client, from xds-server
C++
Ottieni il nome del pod del client:
kubectl get pods | grep example-grpc-client
Visualizzi un feedback come questo:
default example-grpc-client-7c969bb997-9fzjv 1/1 Running 0 105s
Apri una shell sul pod del client:
kubectl exec -it example-grpc-client-7c969bb997-9fzjv -- /bin/bash
Una volta all'interno della shell, scarica gRPC C++ e crea l'applicazione client
xds-hello-world
.apt-get update -y && \ apt-get install -y \ build-essential \ clang \ python3 \ python3-dev
curl -L https://github.com/grpc/grpc/archive/master.tar.gz | tar -xz
cd grpc-master
tools/bazel build examples/cpp/helloworld:xds_greeter_client
Esegui il client con il flag
--xds-creds
per indicare la sicurezza abilitata per xDS, il nome del client e la stringa di connessione di destinazione:bazel-bin/examples/cpp/helloworld/xds_greeter_client --target=xds:///helloworld-gke:8000
Per eseguire il client senza credenziali, utilizza quanto segue:
bazel-bin/examples/cpp/helloworld/xds_greeter_client --target=xds:///helloworld-gke:8000 --nosecure
Dovresti visualizzare un output simile al seguente:
Greeter received: Hello world
Python
Recupera il nome del pod del cliente:
kubectl get pods | grep example-grpc-client
Visualizzi un feedback come questo:
default example-grpc-client-7c969bb997-9fzjv 1/1 Running 0 105s
Apri una shell sul pod del client:
kubectl exec -it example-grpc-client-7c969bb997-9fzjv -- /bin/bash
Una volta all'interno della shell, scarica gRPC Python versione 1.41.0 e per creare l'applicazione client di esempio.
apt-get update -y apt-get install -y python3 python3-pip python3 -m pip install virtualenv curl -L https://github.com/grpc/grpc/archive/v1.41.x.tar.gz | tar -xz cd grpc-1.41.x/examples/python/xds/ python3 -m virtualenv venv source venv/bin/activate python3 -m pip install -r requirements.txt
Esegui il client con il flag
--xds-creds
per indicare la sicurezza abilitata per xDS, il nome del client e la stringa di connessione di destinazione:python3 client.py xds:///helloworld-gke:8000 --xds-creds
Dovresti visualizzare un output simile al seguente:
Greeter client received: Hello you from example-host!
Vai
Ottieni il nome del pod del client:
kubectl get pods | grep example-grpc-client
Visualizzi un feedback come questo:
default example-grpc-client-7c969bb997-9fzjv 1/1 Running 0 105s
Apri una shell per il pod del client:
kubectl exec -it example-grpc-client-7c969bb997-9fzjv -- /bin/sh
Una volta all'interno della shell, scarica la versione 1.42.0 di gRPC Go e vai alla directory contenente l'applicazione client
xds-hello-world
.apk add curl curl -L https://github.com/grpc/grpc-go/archive/v1.42.0.tar.gz | tar -xz cd grpc-go-1.42.0/examples/features/xds/client
Compila ed esegui il client con il flag
--xds_creds
per indicare la sicurezza abilitata per xDS, il nome del client e la stringa di connessione di destinazione:GRPC_GO_LOG_VERBOSITY_LEVEL=2 GRPC_GO_LOG_SEVERITY_LEVEL="info" \ go run main.go \ -xds_creds \ -name xds-client \ -target xds:///helloworld-gke:8000
Dovresti vedere un output simile al seguente:
Greeting: Hello xds-client, from example-grpc-server-77548868d-l9hmf
Configurare l'accesso a livello di servizio con un criterio di autorizzazione
Per il supporto dei criteri di autorizzazione è richiesto il supporto gRFC A41. Puoi trovare le versioni delle lingue richieste su github
Segui queste istruzioni per configurare l'accesso a livello di servizio con i criteri di autorizzazione. Prima di creare i criteri di autorizzazione, leggi l'avviso in Limitare l'accesso utilizzando l'autorizzazione.
Per semplificare la verifica della configurazione, crea un nome host aggiuntivo
che il client può utilizzare per fare riferimento al servizio helloworld-gke
.
Aggiorna la specifica
GRPCRoute
precedentemente memorizzata ingrpc_route.yaml
name: helloworld-grpc-route hostnames: - helloworld-gke:8000 - helloworld-gke-noaccess:8000 meshes: - projects/PROJECT_NUMBER/locations/global/meshes/grpc-mesh rules: - action: destinations: - serviceName: projects/PROJECT_NUMBER/locations/global/backendServices/grpc-gke-helloworld-service
Importa di nuovo la risorsa
GRPCRoute
dalla specificagrpc_route.yaml
.gcloud network-services grpc-routes import helloworld-grpc-route \ --source=grpc_route.yaml \ --location=global
Le seguenti istruzioni creano un criterio di autorizzazione che consente le richieste
inviate dall'account example-grpc-client
in cui è presente il nome host
helloworld-gke:8000
e la porta è 50051
.
gcloud
Crea un criterio di autorizzazione creando un file denominato
helloworld-gke-authz-policy.yaml
.action: ALLOW name: helloworld-gke-authz-policy rules: - sources: - principals: - spiffe://PROJECT_ID.svc.id.goog/ns/default/sa/example-grpc-client destinations: - hosts: - helloworld-gke:8000 ports: - 50051
Importa il criterio.
gcloud network-security authorization-policies import \ helloworld-gke-authz-policy \ --source=helloworld-gke-authz-policy.yaml \ --location=global
Aggiorna il criterio endpoint in modo che faccia riferimento al nuovo criterio di autorizzazione aggiungendo quanto segue al file
ep-mtls-psms.yaml
.authorizationPolicy: projects/${PROJECT_ID}/locations/global/authorizationPolicies/helloworld-gke-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 bootstrap gRPC file contengono l'etichetta
app:helloworld
.Importa il criterio:
gcloud network-services endpoint-policies import ep-mtls-psms \ --source=ep-mtls-psms.yaml --location=global
Convalida il criterio di autorizzazione
Segui queste istruzioni per verificare che il criterio di autorizzazione funzioni correttamente.
Java
Apri una shell sul pod client che hai utilizzato in precedenza.
kubectl exec -it example-grpc-client-7c969bb997-9fzjv -- /bin/bash
Nella shell dei comandi, esegui i seguenti comandi per convalidare la configurazione.
cd grpc-java-1.42.1/examples/example-xds ./build/install/example-xds/bin/xds-hello-world-client --xds-creds xds-client \ xds:///helloworld-gke:8000
Dovresti visualizzare un output simile al seguente:
Greeting: Hello xds-client, from xds-server
Esegui di nuovo il client con il nome del server alternativo. Tieni presente che si tratta di un caso di errore. La richiesta non è valida perché il criterio di autorizzazione consente solo l'accesso al nome host
helloworld-gke:8000
../build/install/example-xds/bin/xds-hello-world-client --xds-creds xds-client \ xds:///helloworld-gke-noaccess:8000
Dovresti visualizzare un output simile al seguente:
WARNING: RPC failed: Status{code=PERMISSION_DENIED}
Se non vedi questo output, è possibile che il criterio di autorizzazione non sia in . Attendi qualche minuto e prova l'intera procedura di verifica di nuovo.
Vai
Apri una shell sul pod client che hai utilizzato in precedenza.
kubectl exec -it example-grpc-client-7c969bb997-9fzjv -- /bin/bash
Nella shell dei comandi, esegui i seguenti comandi per convalidare la configurazione.
cd grpc-go-1.42.0/examples/features/xds/client GRPC_GO_LOG_VERBOSITY_LEVEL=2 GRPC_GO_LOG_SEVERITY_LEVEL="info" \ go run main.go \ -xds_creds \ -name xds-client \ -target xds:///helloworld-gke:8000
Dovresti visualizzare un output simile al seguente:
Greeting: Hello xds-client, from example-grpc-server-77548868d-l9hmf
Esegui di nuovo il client con il nome del server alternativo. Tieni presente che si tratta di un caso di errore. La richiesta non è valida perché il criterio di autorizzazione consente solo l'accesso al nome host
helloworld-gke:8000
.GRPC_GO_LOG_VERBOSITY_LEVEL=2 GRPC_GO_LOG_SEVERITY_LEVEL="info" \ go run main.go \ -xds_creds \ -name xds-client \ -target xds:///helloworld-gke-noaccess:8000
Dovresti visualizzare un output simile al seguente:
could not greet: rpc error: code = PermissionDenied desc = Incoming RPC is not allowed: rpc error: code = PermissionDenied desc = incoming RPC did not match an allow policy exit status 1
Se non vedi questo output, è possibile che il criterio di autorizzazione non sia ancora in uso. Attendi qualche minuto e prova l'intera procedura di verifica di nuovo.
Utilizza TLS anziché mTLS
In questo esempio, l'utilizzo di TLS richiede solo una piccola modifica.
In
ServerTlsPolicy
, inseriscimtlsPolicy
:cat << EOF > server-tls-policy.yaml name: "server-tls-policy" serverCertificate: certificateProviderInstance: pluginInstance: google_cloud_private_spiffe EOF
Utilizza invece questo criterio in
EndpointPolicy
:cat << EOF > ep-tls-psms.yaml name: "ep-mtls-psms" type: "GRPC_SERVER" serverTlsPolicy: "projects/${PROJECT_ID}/locations/global/serverTlsPolicies/server-tls-policy" trafficPortSelector: ports: - "50051" endpointMatcher: metadataLabelMatcher: metadataLabelMatchCriteria: "MATCH_ALL" metadataLabels: [] EOF
ClientTlsPolicy
per mTLS funziona anche nel caso TLS, maclientCertificate
sezione del criterio può essere eliminata perché non è richiesto per TLS:cat << EOF > client-tls-policy.yaml name: "client-tls-policy" serverValidationCa: - certificateProviderInstance: pluginInstance: google_cloud_private_spiffe EOF
Utilizzare la sicurezza del servizio con l'esempio di Wallet
Questa sezione fornisce una panoramica generale su come attivare l'esempio di Wallet con la sicurezza del servizio, per Java, C++ e Go.
Java
Puoi trovare il codice sorgente di esempio per Java su github.
Il codice utilizza già le credenziali XdsChannel
e XdsServer
quando
configurare la sicurezza senza proxy.
Queste istruzioni descrivono la configurazione dell'esempio di Wallet con Go. La procedura è simile per Java. Le istruzioni utilizzano un Docker preesistente un'immagine reperibile dal repository di container di Google Cloud.
Per creare l'esempio, segui queste istruzioni:
- clona il repository e recupera i file nella directory Esempi di gRPC.
- Modifica il file
00-common-env.sh
. Commenta la riga esistente che imposta il valore diWALLET_DOCKER_IMAGE
sull'immagine Docker Go e rimuovi il commento dalla riga che imposta il valore diWALLET_DOCKER_IMAGE
su Immagine Docker Java. - Crea e configura le istanze Cloud Router seguendo le istruzioni riportate in Creare e configurare istanze Cloud Router o utilizzando la funzione
create_cloud_router_instances
nello script10.apis.sh
. - Crea un cluster utilizzando le istruzioni per l'esempio
hello world
. o la funzionecreate_cluster
nello script20-cluster.sh
. - Crea autorità di certificazione private seguendo le istruzioni per il servizio CA o utilizzando lo script
30-private-ca-setup.sh
. - Creare risorse Kubernetes, inclusi account di servizio, spazi dei nomi
Servizi Kubernetes, NEG e deployment lato server per tutti i servizi:
account
,stats
,stats_premium
,wallet_v1
,wallet_v2
, utilizzando il script40-k8s-resources.sh
. - Per ciascuno dei servizi che hai creato, crea un controllo di integrità e un servizio di backend
utilizzando
create_health_check
ecreate_backend_service
nello script50-td-components.sh
. - Crea i componenti di routing di Cloud Service Mesh utilizzando
create_routing_components
nello script60-routing-components.sh
. - Crea i componenti di sicurezza di Cloud Service Mesh per ciascun servizio di backend
utilizzando
create_security_components
nello script70-security-components.sh
. - Crea il deployment del client Wallet utilizzando
create_client_deployment
in script75-client-deployment.sh
. - Verifica la configurazione avviando il client come descritto in Esegui la verifica con i clienti grpc-wallet.
C++
Puoi trovare il codice sorgente di esempio per C++ in github. Il codice utilizza già
Credenziali di XdsChannel
e XdsServer
quando configuri la sicurezza senza proxy.
Queste istruzioni descrivono la configurazione dell'esempio di Wallet con Go. La è simile a quello di C++. Le istruzioni utilizzano un Docker preesistente un'immagine reperibile dal repository di container di Google Cloud.
Per creare l'esempio, segui queste istruzioni:
- clona il repository e recupera i file nella directory Esempi di gRPC.
- Modifica il file
00-common-env.sh
. Commenta la riga esistente che imposta il valore diWALLET_DOCKER_IMAGE
sull'immagine Docker Go e rimuovi il commento dalla riga che imposta il valore diWALLET_DOCKER_IMAGE
sull'immagine Docker C++. - Crea e configura le istanze Cloud Router seguendo le istruzioni riportate in Creare e configurare istanze Cloud Router o utilizzando la funzione
create_cloud_router_instances
nello script10.apis.sh
. - Crea un cluster utilizzando le istruzioni per l'esempio
hello world
. o la funzionecreate_cluster
nello script20-cluster.sh
. - Crea autorità di certificazione private seguendo le istruzioni per il servizio CA o utilizzando lo script
30-private-ca-setup.sh
. - Creare risorse Kubernetes, inclusi account di servizio, spazi dei nomi
Servizi Kubernetes, NEG e deployment lato server per tutti i servizi:
account
,stats
,stats_premium
,wallet_v1
,wallet_v2
, utilizzando il script40-k8s-resources.sh
. - Per ciascuno dei servizi che hai creato, crea un controllo di integrità e un servizio di backend
utilizzando
create_health_check
ecreate_backend_service
nello script50-td-components.sh
. - Crea i componenti di routing di Cloud Service Mesh utilizzando
create_routing_components
nello script60-routing-components.sh
. - Crea i componenti di sicurezza di Cloud Service Mesh per ciascun servizio di backend
utilizzando
create_security_components
nello script70-security-components.sh
. - Crea il deployment del client Wallet utilizzando
create_client_deployment
nello script75-client-deployment.sh
. - Verifica la configurazione avviando il client come descritto in Esegui la verifica con i clienti grpc-wallet.
Vai
Puoi trovare un codice sorgente di esempio per Go su GitHub. Il codice utilizza già le credenziali XdsChannel
eXdsServer
quando configuri la sicurezza senza proxy.
Le istruzioni utilizzano un'immagine Docker preesistente che puoi ottenere dal repository di container di Google Cloud.
Per creare l'esempio, segui queste istruzioni:
- Clona il repository e recupera i file nella directory gRPC examples.
- Modifica il file
00-common-env.sh
per impostare i valori corretti per il campo variabili di ambiente. - Crea e configura le istanze del router Cloud utilizzando le istruzioni in
Crea e configura istanze del router Cloud
o utilizzando la funzione
create_cloud_router_instances
nello script10.apis.sh
. - Crea un cluster utilizzando le istruzioni per l'esempio
hello world
. o la funzionecreate_cluster
nello script20-cluster.sh
. - Crea autorità di certificazione private utilizzando le istruzioni per
CA Service
o utilizzando lo script
30-private-ca-setup.sh
. - Crea risorse Kubernetes, tra cui account di servizio, spazi dei nomi, servizi Kubernetes, NEG e deployment lato server per tutti i servizi:
account
,stats
,stats_premium
,wallet_v1
,wallet_v2
utilizzando lo script40-k8s-resources.sh
. - Per ciascuno dei servizi che hai creato, crea un controllo di integrità e un servizio di backend
utilizzando
create_health_check
ecreate_backend_service
nello script50-td-components.sh
. - Crea i componenti di routing di Cloud Service Mesh utilizzando
create_routing_components
nello script60-routing-components.sh
. - Crea i componenti di sicurezza di Cloud Service Mesh per ciascun servizio di backend
utilizzando
create_security_components
nello script70-security-components.sh
. - Crea il deployment del client Wallet utilizzando
create_client_deployment
nello script75-client-deployment.sh
. - Verifica la configurazione avviando il client come descritto in Eseguire la verifica con i client grpc-wallet.
File di bootstrap
La procedura di configurazione in questa guida utilizza un generatore di bootstrap per creare il file di bootstrap richiesto. Questa sezione fornisce informazioni di riferimento sul file di bootstrap stesso.
Il file di bootstrap contiene le informazioni di configurazione richieste da gRPC proxyless del codice, incluse le informazioni di connessione per il server xDS. Il file di bootstrap contiene la configurazione di sicurezza richiesta dalla funzionalità di sicurezza gRPC senza proxy. Il server gRPC richiede un campo aggiuntivo. Un file di bootstrap di esempio ha il seguente aspetto:
{ "xds_servers": [ { "server_uri": "trafficdirector.googleapis.com:443", "channel_creds": [ { "type": "google_default" } ], "server_features": [ "xds_v3" ] } ], "authorities": { "traffic-director-c2p.xds.googleapis.com": { "xds_servers": [ { "server_uri": "dns:///directpath-pa.googleapis.com", "channel_creds": [ { "type": "google_default" } ], "server_features": [ "xds_v3", "ignore_resource_deletion" ] } ], "client_listener_resource_name_template": "xdstp://traffic-director-c2p.xds.googleapis.com/envoy.config.listener.v3.Listener/%s" } }, "node": { "id": "projects/9876012345/networks/mesh:grpc-mesh/nodes/b59f49cc-d95a-4462-9126-112f794d5dd3", "cluster": "cluster", "metadata": { "INSTANCE_IP": "10.28.2.8", "TRAFFICDIRECTOR_DIRECTPATH_C2P_IPV6_CAPABLE": true, "TRAFFICDIRECTOR_GCP_PROJECT_NUMBER": "223606568246", "TRAFFICDIRECTOR_NETWORK_NAME": "default", "app": "helloworld" }, "locality": { "zone": "us-central1-c" } }, "certificate_providers": { "google_cloud_private_spiffe": { "plugin_name": "file_watcher", "config": { "certificate_file": "/var/run/secrets/workload-spiffe-credentials/certificates.pem", "private_key_file": "/var/run/secrets/workload-spiffe-credentials/private_key.pem", "ca_certificate_file": "/var/run/secrets/workload-spiffe-credentials/ca_certificates.pem", "refresh_interval": "600s" } } }, "server_listener_resource_name_template": "grpc/server?xds.resource.listening_address=%s" }
Aggiornamenti al file di bootstrap per il servizio di sicurezza
I seguenti campi riflettono le modifiche relative alla sicurezza e all'utilizzo di xDS v3:
Il campo id
all'interno di node
fornisce un'identità unica per il client gRPC per
Cloud Service Mesh. Devi fornire il numero di progetto Google Cloud e
utilizzando l'ID nodo nel seguente formato:
projects/{project number}/networks/{network name}/nodes/[UNIQUE_ID]
Un esempio per il numero di progetto 1234 e la rete predefinita è:
projects/1234/networks/default/nodes/client1
Il campo INSTANCE_IP
è l'indirizzo IP del pod o 0.0.0.0
per indicare
INADDR_ANY
. Questo campo viene utilizzato dal server gRPC per recuperare il listener
di Cloud Service Mesh per la sicurezza lato server.
Campi di configurazione della sicurezza nel file di bootstrap
Chiave JSON | Tipo | Valore | Note |
---|---|---|---|
server_listener_resource_name_template |
Stringa | grpc/server?xds.resource.listening_address=%s |
Obbligatorio per i server gRPC. gRPC utilizza questo valore per comporre il nome della risorsa per il recupero della risorsa "Listener" da Cloud Service Mesh per la sicurezza lato server e altre configurazioni. gRPC lo utilizza per formare la stringa del nome della risorsa |
certificate_providers |
Struttura JSON | google_cloud_private_spiffe |
Obbligatorio. Il valore è una struttura JSON che rappresenta una mappa di nomi per le istanze del provider di certificati. Viene utilizzata un'istanza del provider di certificati per recuperare i certificati radice e dell'identità. L'esempio di file di bootstap contiene un nome: google_cloud_private_spiffe , con lo struct JSON dell'istanza del provider di certificati come valore. Ogni struct JSON dell'istanza del provider di certificati ha due campi:
|
I contenuti della struttura JSON config
per il plug-in file_watcher
sono:
certificate_file
: stringa obbligatoria. Questo valore è la posizione certificato di identità.private_key_file
: stringa obbligatoria. Il valore è la posizione dell'oggetto che deve corrispondere al certificato di identità.ca_certificate_file
: stringa obbligatoria. Il valore è la posizione certificato radice, anche noto come bundle di attendibilità.refresh_interval
: stringa facoltativa. Il valore indica l'intervallo di aggiornamento, specificato utilizzando la rappresentazione stringa della mappatura JSON di una durata. Il valore predefinito è "600s", con una durata di 10 minuti.
Generatore di bootstrap
L'immagine del container del generatore di bootstrap è disponibile all'indirizzo
gcr.io/trafficdirector-prod/td-grpc-bootstrap:0.16.0
. Il codice sorgente è disponibile all'indirizzo https://github.com/GoogleCloudPlatform/traffic-director-grpc-bootstrap
.
Le opzioni della riga di comando più comuni sono le seguenti:
--output
: utilizza questa opzione per specificare la posizione in cui viene scritto il file di bootstrap di output. Ad esempio, il comando--output /tmp/bootstrap/td-grpc-bootstrap.json
genera il file di bootstrap in/tmp/bootstrap/td-grpc-bootstrap.json
nel file system del pod.--config-mesh-experimental
: utilizza questa opzione per specificare il nome della maglia corrispondente alla risorsaMesh
.--node-metadata
: utilizza questo flag per completare i metadati del nodo in il file di bootstrap. Questo è necessario quando utilizzi i corrispondenti delle etichette dei metadati inEndpointPolicy
, dove Cloud Service Mesh utilizza i dati delle etichette forniti nella sezione dei metadati del nodo del file di bootstrap. L'argomento è specificato nel formato chiave=valore, ad esempio:--node-metadata version=prod --node-metadata type=grpc
Le informazioni precedenti aggiungono quanto segue nella sezione dei metadati del nodo della file di bootstrap:
{ "node": { ... "metadata": { "version": "prod", "type": "grpc", ... }, ... }, ... }
Elimina il deployment
Se vuoi, puoi eseguire questi comandi per eliminare il deployment creato con 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 grpc-gke-helloworld-service --global --quiet gcloud compute network-endpoint-groups delete example-grpc-server --zone ZONE --quiet gcloud compute firewall-rules delete grpc-gke-allow-health-checks --quiet gcloud compute health-checks delete grpc-gke-helloworld-hc --quiet gcloud network-services endpoint-policies delete ep-mtls-psms \ --location=global --quiet gcloud network-security authorization-policies delete helloworld-gke-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
Risoluzione dei problemi
Segui queste istruzioni per risolvere i problemi relativi al deployment della sicurezza.
I carichi di lavoro non riescono a recuperare la configurazione da Cloud Service Mesh
Se viene visualizzato un errore simile al seguente:
PERMISSION_DENIED: Request had insufficient authentication scopes.
Assicurati di quanto segue:
- Hai creato il cluster GKE con l'argomento
--scopes=cloud-platform
. - Hai assegnato
roles/trafficdirector.client
al tuo servizio Kuberneters . - Hai assegnato
roles/trafficdirector.client
al tuo servizio Google Cloud predefinito account (${GSA_EMAIL} sopra). - Hai attivato il servizio (API)
trafficdirector.googleapis.com
.
Il server gRPC non utilizza TLS/mTLS anche con la configurazione corretta di Cloud Service Mesh
Assicurati di specificare GRPC_SERVER
nella configurazione dei criteri dell'endpoint. Se hai specificato SIDECAR_PROXY
, gRPC ignora la configurazione.
Non puoi creare il cluster GKE con la versione cluster richiesta
Il comando di creazione del cluster GKE potrebbe non riuscire e restituire un errore ad esempio:
Node version "1.20.5-gke.2000" is unsupported.
Assicurati di utilizzare l'argomento --release-channel rapid
nel tuo
di creazione del cluster. Devi utilizzare il canale di rilascio rapido per ottenere
la versione corretta per questa release.
Viene visualizzato un errore di tipo No usable endpoint
Se un client non è in grado di comunicare con il server a causa di un No usable endpoint
significa che il controllo di integrità potrebbe aver contrassegnato i backend del server come non integro.
Per controllare l'integrità dei backend, esegui questo comando gcloud
:
gcloud compute backend-services get-health grpc-gke-helloworld-service --global
Se il comando restituisce lo stato del backend non integro, potrebbe essere per uno dei motivi per cui:
- Il firewall non è stato creato o non contiene l'intervallo IP di origine corretto.
- I tag di destinazione sul firewall non corrispondono ai tag del cluster che hai creato.
I carichi di lavoro non sono in grado di comunicare nella configurazione di sicurezza
Se i tuoi carichi di lavoro non sono in grado di comunicare dopo aver configurato la sicurezza per dalla rete mesh di servizi senza proxy, segui queste istruzioni per determinarne la causa.
- Disattiva la sicurezza senza proxy ed elimina i problemi nei casi d'uso del bilanciamento del carico del mesh di servizi senza proxy. Per disattivare la sicurezza nella mesh, procedi in uno dei seguenti modi:
- Utilizza le credenziali in testo normale lato client e lato server OPPURE
- Non configurare la sicurezza per il servizio di backend e il criterio endpoint nella configurazione di Cloud Service Mesh.
Segui i passaggi descritti in Risolvere i problemi di deployment di Cloud Service Mesh senza proxy, poiché non è presente alcuna configurazione di sicurezza nel deployment.
Modifica i carichi di lavoro in modo da utilizzare le credenziali xDS con credenziali non sicure o in testo non criptato come credenziali di riserva. Mantieni la configurazione di Cloud Service Mesh con la sicurezza disattivata come discusso in precedenza. In questo caso, sebbene gRPC consenta a Cloud Service Mesh di configurare la sicurezza, Cloud Service Mesh non invia informazioni di sicurezza; in questo caso gRPC devono ricorrere a credenziali in testo normale (o non sicure), che dovrebbero funzionare in modo simile al primo caso precedente. Se questa soluzione non funziona, svolgi quanto segue:
- Aumenta il livello di logging sia sul lato client che sul lato server in modo da possono vedere i messaggi xDS scambiati tra gRPC e Cloud Service Mesh.
- Assicurati che Cloud Service Mesh non abbia la sicurezza abilitata in CDS che vengono inviate ai carichi di lavoro.
- Assicurati che i carichi di lavoro non utilizzino le modalità TLS o mTLS nelle relative i canali di notifica. Se visualizzi messaggi di log relativi agli handshake TLS, controlla il codice sorgente dell'applicazione e assicurati di utilizzare credenziali non sicure o in testo normale come credenziali di riserva. Se il codice sorgente dell'applicazione è corretto, potrebbe trattarsi di un bug nella libreria gRPC
Verifica che l'integrazione del servizio CA con GKE funzioni correttamente per il cluster GKE seguendo la procedura di risoluzione dei problemi Guida dell'utente. Assicurati che i certificati e le chiavi forniti da quella funzionalità vengono resi disponibili nella directory specificata,
/var/run/secrets/workload-spiffe-credentials/
.Attiva TLS (invece di mTLS) nel mesh, come descritto in precedenza, e riavvia dai carichi di lavoro client e server.
- Aumenta il livello di logging sia sul lato client che sul lato server per poter per vedere i messaggi xDS scambiati tra gRPC e Cloud Service Mesh.
- Assicurati che Cloud Service Mesh abbia attivato la sicurezza nelle risposte CDS e LDS inviate ai carichi di lavoro.
Il client ha errore e appare un CertificateException
e un messaggio Peer certificate SAN check failed
Ciò indica un problema con i valori subjectAltNames
nel messaggioSecuritySettings
. Tieni presente che questi valori si basano sui servizi Kubernetes che hai creato per il servizio di backend. Per ogni servizio Kubernetes di questo tipo
che hai creato, è associato un ID SPIFFE nel seguente formato:
spiffe://${WORKLOAD_POOL}/ns/${K8S_NAMESPACE}/sa/${SERVICE_ACCOUNT}
Questi valori sono:
WORKLOAD_POOL
: il pool di workload per il cluster, ovvero${PROJECT_ID}.svc.id.goog
K8S_NAMESPACE
: lo spazio dei nomi Kubernetes utilizzato per il deployment dell'oggetto servizioSERVICE_ACCOUNT
: l'account di servizio Kubernetes che hai utilizzato nel deployment. del servizio
Per ogni servizio Kubernetes collegato al servizio di backend come rete
di aver calcolato correttamente l'ID SPIFFE e di aver aggiunto
quell'ID SPIFFE nel campo subjectAltNames
del messaggio SecuritySettings
.
Le applicazioni non possono utilizzare i certificati mTLS con la libreria gRPC
Se le tue applicazioni non sono in grado di utilizzare i certificati mTLS con il tuo gRPC libreria, procedi nel seguente modo:
Verifica che la specifica del pod contenga l'elemento
security.cloud.google.com/use-workload-certificates
l'annotazione descritta in Creazione di un servizio gRPC senza proxy con NEG.Verifica che i file contenenti la catena di certificati insieme alla foglia il certificato, la chiave privata e i certificati CA attendibili sono accessibili all'indirizzo i seguenti percorsi dall'interno del pod:
- Catena di certificati insieme al certificato dell'entità finale: "/var/run/secrets/workload-spiffe-credentials/certificates.pem"
- Chiave privata: "/var/run/secrets/workload-spiffe-credentials/private_key.pem"
- Bundle CA: "/var/run/secrets/workload-spiffe-credentials/ca_certificates.pem"
Se i certificati nel passaggio precedente non sono disponibili, svolgi i seguenti passaggi:
gcloud privateca subordinates describe SUBORDINATE_CA_POOL_NAME
--location=LOCATIONVerifica che il piano di controllo di GKE disponga dell'associazione del ruolo IAM corretta, la concessione dell'accesso a CA Service:
# Get the IAM policy for the CA gcloud privateca roots get-iam-policy ROOT_CA_POOL_NAME # Verify that there is an IAM binding granting access in the following format - members: - serviceAccount:service-projnumber@container-engine-robot.iam.gserviceaccount.com role: roles/privateca.certificateManager # Where projnumber is the project number (e.g. 2915810291) for the GKE cluster.
Verifica che il certificato non sia scaduto. Questa è la catena di certificati e certificato foglia all'indirizzo
/var/run/secrets/workload-spiffe-credentials/certificates.pem
. Per verificare, esegui questo comando:cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -text -noout | grep "Not After"
Verifica che il tipo di chiave sia supportato dalla tua applicazione eseguendo questo comando:
cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -text -noout | grep "Public Key Algorithm" -A 3
Verifica che l'applicazione Java gRPC abbia il seguente
keyAlgorithm
nel file YAMLWorkloadCertificateConfig
:
keyAlgorithm: rsa: modulusSize: 4096
Verifica che la CA utilizzi la stessa famiglia di chiavi della chiave del certificato.
Il certificato di un'applicazione viene rifiutato dal client, dal server o dal peer
- Verifica che l'applicazione peer utilizzi lo stesso bundle di attendibilità per verificare certificato.
- Verificare che il certificato in uso non sia scaduto (catena di certificati lungo con certificato foglia: "/var/run/secrets/workload-spiffe-credentials/certificates.pem").
I pod rimangono in uno stato di attesa
Se i pod rimangono in uno stato in 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 la versione più recente della CLI gcloud:
gcloud components update
Tieni presente che il flag --enable-mesh-certificates
funziona solo con gcloud beta
.
I pod non si avviano
L'avvio dei pod che utilizzano i certificati del mesh GKE potrebbe non riuscire se il provisioning dei certificati non va a buon fine. Ciò può verificarsi in situazioni come le seguenti:
WorkloadCertificateConfig
oTrustConfig
non sono configurati correttamente o mancante.- I CSR non vengono approvati.
Puoi verificare se il provisioning dei certificati non va a buon fine controllando gli eventi del pod.
Controlla lo stato del pod:
kubectl get pod -n POD_NAMESPACE POD_NAME
Sostituisci quanto segue:
POD_NAMESPACE
: lo spazio dei nomi del 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, viene 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)
Consulta i seguenti passaggi per la risoluzione dei problemi se i pod non si avviano a causa di oggetti configurati in modo errato o di CSR rifiutate.
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 invece visualizzato
status: "False"
. Lereason
e Il campomessage
contiene ulteriori dettagli sulla risoluzione dei problemi.
I CSR non sono approvati
Se si verificano problemi durante la procedura di approvazione di CSR, puoi controllare l'errore
dettagli nelle condizioni type: Approved
e type: Issued
della richiesta di firma del certificato.
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
.Visualizza i dettagli della CSR selezionata utilizzando kubectl:
kubectl get csr CSR_NAME -o yaml
Sostituisci
CSR_NAME
con il nome del CSR che hai scelto.
Un CSR valido ha una condizione con type: Approved
e status: "True"
e un
certificato valido nel campo status.certificate
:
status:
certificate: <base64-encoded data>
conditions:
- lastTransitionTime: "2021-03-04T21:58:46Z"
lastUpdateTime: "2021-03-04T21:58:46Z"
message: Approved CSR because it is a valid SPIFFE SVID for the correct identity.
reason: AutoApproved
status: "True"
type: Approved
Le informazioni per la risoluzione dei problemi relativi ai CSR non validi vengono visualizzate nei campi message
e
reason
.
Nei pod mancano dei certificati
Ottieni le specifiche del pod per il tuo pod:
kubectl get pod -n POD_NAMESPACE POD_NAME -o yaml
Sostituisci quanto segue:
POD_NAMESPACE
: lo spazio dei nomi del pod.POD_NAME
: il nome del pod.
Verifica che la specifica del pod contenga l'annotazione
security.cloud.google.com/use-workload-certificates
descritta in Configurare i pod per ricevere le credenziali mTLS.Verifica che il controller di ammissione dei certificati del mesh GKE abbia inserito correttamente un volume del driver CSI di tipo
workloadcertificates.security.cloud.google.com
nella specifica del pod:volumes: ... -csi: driver: workloadcertificates.security.cloud.google.com name: gke-workload-certificates ...
Verifica la presenza di un montaggio del volume in ciascuno dei container:
containers: - name: ... ... volumeMounts: - mountPath: /var/run/secrets/workload-spiffe-credentials name: gke-workload-certificates readOnly: true ...
Verifica che i seguenti pacchetti di certificati e la chiave privata siano disponibili nelle seguenti posizioni del pod:
- Bundle della catena di certificati:
/var/run/secrets/workload-spiffe-credentials/certificates.pem
- Chiave privata:
/var/run/secrets/workload-spiffe-credentials/private_key.pem
- Bundle di ancoraggio CA attendibile:
/var/run/secrets/workload-spiffe-credentials/ca_certificates.pem
- Bundle della catena di certificati:
Se i file non sono disponibili, segui questi passaggi:
Recupera il servizio CA (anteprima) per il cluster:
kubectl get workloadcertificateconfigs default -o jsonpath '{.spec.certificateAuthorityConfig.certificateAuthorityServiceConfig.endpointURI}'
Recupera 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.
Ottieni il criterio IAM per la CA principale:
gcloud privateca roots get-iam-policy ROOT_CA_NAME
Sostituisci
ROOT_CA_NAME
con il nome della CA principale.Nel criterio IAM, verifica che
privateca.auditor
associazione dei criteri esistente:... - members: - serviceAccount:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com role: roles/privateca.auditor ...
In questo esempio,
PROJECT_NUMBER
è il numero di progetto del cluster.Ottieni il criterio IAM per la CA subordinata:
gcloud privateca subordinates get-iam-policy SUBORDINATE_CA_NAME
Sostituisci
SUBORDINATE_CA_NAME
con il nome della CA subordinata.Nel criterio IAM, verifica che esista l'associazione dei criteri
privateca.certificateManager
:... - members: - serviceAccount: service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com role: roles/privateca.certificateManager ...
In questo esempio,
PROJECT_NUMBER
è il numero di progetto del cluster.
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 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 di chiave che hai definito nelWorkloadCertificateConfig
manifest YAML. L'output è il seguente:config: ... subjectConfig: commonName: td-sub-ca subject: organization: TestOrgLLC subjectAltName: {} createTime: '2021-05-04T05:37:58.329293525Z' issuingOptions: includeCaCertUrl: true keySpec: algorithm: RSA_PKCS1_2048_SHA256 ...
I certificati vengono rifiutati
- 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 di ricaricamento delle credenziali gRPC Go, aggiorni periodicamente le credenziali dal file system.
Verifica che i tuoi 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à.
Limitazioni
La sicurezza del servizio Cloud Service Mesh è supportata solo con con GKE. Non puoi eseguire il deployment della sicurezza del servizio con Compute Engine.
Cloud Service Mesh non supporta scenari in cui sono presenti due o più endpoint di criteri che corrispondano equamente a un endpoint, ad esempio due i criteri con le stesse etichette e porte oppure con due o più criteri che corrispondano equamente alle etichette di un endpoint. Per ulteriori informazioni che i criteri degli endpoint siano abbinati alle etichette di un endpoint, consulta API per EndpointPolicy.EndpointMatcher.MetadataLabelMatcher. In queste situazioni, Cloud Service Mesh non genera la configurazione di sicurezza da nessuno dei criteri in conflitto.