Stai visualizzando la documentazione di Service Mesh 1.21.

Versioni disponibili

Cloud Service Mesh
Archivio 1.22
Archivio 1.21
Archivio 1.20
Archivio 1.19
Archivio 1.18

Questa pagina è stata tradotta dall'API Cloud Translation.

Configurare la sicurezza del servizio con gRPC proxyless

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 gRPC senza proxy, 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 v3.
Hai accesso alla versione di xDS e al provider di certificati richiesti di Google Cloud con una delle seguenti lingue:
- gRPC Java
- gRPC C++
- Python gRPC
- gRPC Go Puoi trovare le versioni in lingua richieste su GitHub
Hai accesso al generatore di bootstrap, versione 0.16.0. Il bootstrap dell'immagine del generatore si trova nel repository di container Google Cloud.
Soddisfi tutti i prerequisiti per il carico del mesh di servizi senza proxy gRPC bilanciato.
Disponi di autorizzazioni sufficienti per creare o aggiornare Cloud Service Mesh e Risorse mesh di servizi Google Cloud per utilizzare la sicurezza PSM. Per completamento informazioni sulle autorizzazioni richieste, consulta Preparati a configurare Cloud Service Mesh con servizi gRPC senza proxy.
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 GKE
roles/compute.instanceAdmin ruolo Compute Engine
Ruolo roles/iam.serviceAccountUser

Per creare le risorse richieste per la configurazione, devi disporre Ruolo compute.NetworkAdmin. Questo ruolo contiene tutte le autorizzazioni necessarie creare, aggiornare, eliminare, elencare e utilizzare (ovvero, ci si riferisce a questo risorse) le risorse richieste. Se sei 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 norma verrà applicata in futuro e utilizzi la compute.NetworkAdmin non riscontrerai problemi nell'applicazione forzata di questo controllo.

Se utilizzi ruoli personalizzati e questo controllo verrà applicato in futuro, devi assicurati di includere la rispettiva autorizzazione di .use. In caso contrario, in futuro potresti scoprire che il tuo ruolo personalizzato non dispone delle autorizzazioni necessarie per fare riferimento a clientTlsPolicy o serverTlsPolicy dal servizio di backend.

Preparati per la 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 ricostruisci le tue applicazioni utilizzando la versione gRPC minima 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. Passaggi non modificati esistenti della procedura di configurazione sono riportati ovunque si applichino.

I principali miglioramenti alla configurazione di Cloud Service Mesh con GKE sono i seguenti:

Configurazione del servizio CA, in cui si creano pool di CA privati e le autorità di certificazione richieste.
Creazione di un cluster GKE con la federazione delle identità per i carichi di lavoro per GKE e le funzionalità dei certificati mesh e l'integrazione del servizio CA.
Configurazione dell'emissione dei certificati mesh sul cluster in corso.
Creazione degli account di servizio client e server.
Configurare il server di esempio che utilizza le API xDS e le credenziali del server xDS per acquisire sicurezza configurazione 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 vedere esempi di codice per l'utilizzo delle credenziali xDS nella pagina seguenti:

Aggiorna Google Cloud CLI

Per aggiornare Google Cloud CLI, esegui questo 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 i valori specifici per le seguenti variabili di ambiente nell'ambiente shell prima di eseguire 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 attivare 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 dall'integrazione di CA Service con GKE. Il cluster GKE deve soddisfare i seguenti requisiti, oltre ai requisiti per la configurazione:

Utilizza una versione minima del cluster 1.21.4-gke.1801. Se hai bisogno di funzionalità sono in una versione successiva, la puoi ottenere dalla release rapida canale.
Il cluster GKE deve essere abilitato e configurato con mesh come descritto in Creazione di autorità di certificazione per emettere certificati.

Crea un nuovo cluster che utilizzi la federazione delle identità per i carichi di lavoro per GKE. Se stai aggiornando una esistente, vai al passaggio successivo. Il valore che assegni a --tags deve corrispondere al nome trasmesso al flag --target-tags per il Comando firewall-rules create nella sezione Configurazione di Cloud Service Mesh con i componenti di Cloud Load Balancing.

# Create a GKE cluster with GKE managed mesh certificates.
gcloud container clusters create CLUSTER_NAME \
  --release-channel=rapid \
  --scopes=cloud-platform \
  --image-type=cos_containerd \
  --machine-type=e2-standard-2 \
  --zone=ZONE \
  --workload-pool=PROJECT_ID.svc.id.goog \
  --enable-mesh-certificates \
  --cluster-version=CLUSTER_VERSION \
  --enable-ip-alias \
  --tags=allow-health-checks \
  --workload-metadata=GKE_METADATA

La creazione del cluster potrebbe richiedere diversi minuti.

Se utilizzi un cluster esistente, attiva la federazione delle identità per i carichi di lavoro per GKE e Certificati mesh GKE. Assicurati che il cluster sia stato creato con il flag --enable-ip-alias, che non può essere utilizzato con il comando update.
```
gcloud container clusters update CLUSTER_NAME \
  --enable-mesh-certificates
```
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 con un parco risorse

Registra il cluster che hai creato o aggiornato in Creazione di un cluster GKE con un parco risorse. La registrazione del cluster semplifica la configurazione dei cluster più progetti.

Tieni presente che il completamento di ciascun passaggio può richiedere fino a dieci minuti.

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 generano il manifest per la registrazione.
Al termine del processo di registrazione, viene visualizzato un messaggio come seguenti:
```
Finished registering the cluster CLUSTER_NAME with the fleet.
```

Applica il file manifest generato al cluster:

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 di appartenenza dal cluster:
```
kubectl get memberships membership -o yaml
```
L'output dovrebbe includere il pool di identità Workoad assegnato dal parco risorse dove PROJECT_ID è il tuo ID progetto:
```
workload_identity_pool: PROJECT_ID.svc.id.goog
```
Ciò significa che il cluster è stato registrato correttamente.

Creare autorità di certificazione per emettere certificati

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

CA radice. Si tratta della radice di attendibilità per tutti i certificati mesh emessi. Puoi utilizzare una CA radice esistente, se ne hai una. Crea la CA radice nel livello enterprise, progettato per l'emissione di certificati di lunga durata e a basso volume.
CA subordinata. Questa CA emette certificati per i carichi di lavoro. Crea il nella regione in cui è stato eseguito il deployment del cluster. Crea 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à.

Queste regioni sono supportate per il servizio CA:

Nome regione	Descrizione regione
`asia-east1`	Taiwan
`asia-east2`	Hong Kong
`asia-northeast1`	Tokyo
`asia-northeast2`	Osaka
`asia-northeast3`	Seul
`asia-south1`	Mumbai
`asia-south2`	Delhi
`asia-southeast1`	Singapore
`asia-southeast2`	Giacarta
`australia-southeast1`	Sydney
`australia-southeast2`	Melbourne
`europe-central2`	Varsavia
`europe-north1`	Finlandia
`europe-southwest1`	Madrid
`europe-west1`	Belgio
`europe-west2`	Londra
`europe-west3`	Francoforte
`europe-west4`	Paesi Bassi
`europe-west6`	Zurigo
`europe-west8`	Milano
`europe-west9`	Parigi
`europe-west10`	Berlino
`europe-west12`	Torino
`me-central1`	Doha
`me-central2`	Dammam
`me-west1`	Tel Aviv
`northamerica-northeast1`	Montréal
`northamerica-northeast2`	Toronto
`southamerica-east1`	San Paolo
`southamerica-west1`	Santiago
`us-central1`	Iowa
`us-east1`	Carolina del Sud
`us-east4`	Virginia del Nord
`us-east5`	Columbus
`us-south1`	Dallas
`us-west1`	Oregon
`us-west2`	Los Angeles
`us-west3`	Salt Lake City
`us-west4`	Las Vegas

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

gcloud privateca locations list

Concedi il ruolo IAM roles/privateca.caManager alle persone che creano un pool di CA e una CA. Tieni presente che per MEMBER, il formato corretto è user:userid@example.com. Se 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, dove MEMBER è persona che ha bisogno di questo accesso, in particolare individui che eseguono i passaggi che seguono per concedere le privateca.auditor Ruoli privateca.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 l'impostazione predefinita modalità di emissione basata sulla configurazione rimangono consentite.

gcloud privateca pools create SUBORDINATE_CA_POOL_NAME \
  --location SUBORDINATE_CA_POOL_LOCATION \
  --tier devops

gcloud privateca subordinates create SUBORDINATE_CA_NAME \
  --pool SUBORDINATE_CA_POOL_NAME \
  --location SUBORDINATE_CA_POOL_LOCATION \
  --issuer-pool ROOT_CA_POOL_NAME \
  --issuer-location ROOT_CA_POOL_LOCATION \
  --subject "CN=SUBORDINATE_CA_NAME, O=SUBORDINATE_CA_ORGANIZATION" \
  --key-algorithm "ec-p256-sha256" \
  --use-preset-profile subordinate_mtls_pathlen_0

Per questa configurazione di dimostrazione, utilizza i seguenti valori per le variabili:

SUBORDINATE_CA_POOL_NAME="td-ca-pool"
SUBORDINATE_CA_POOL_LOCATION=us-east1
SUBORDINATE_CA_NAME="td-ca"
SUBORDINATE_CA_ORGANIZATION="TestCorpLLC"
ROOT_CA_POOL_NAME=td_sec_pool
ROOT_CA_POOL_LOCATION=us-east1

Concedi il ruolo IAM privateca.auditor per il pool di CA principale per consentire l'accesso dall'account di servizio GKE:

gcloud privateca pools add-iam-policy-binding ROOT_CA_POOL_NAME \
 --location ROOT_CA_POOL_LOCATION \
 --role roles/privateca.auditor \
 --member="serviceAccount:service-PROJNUM@container-engine-robot.iam.gserviceaccount.com"

Concedi il ruolo IAM privateca.certificateManager per il pool CA secondario per consentire l'accesso dall'account di servizio GKE:

gcloud privateca pools add-iam-policy-binding SUBORDINATE_CA_POOL_NAME \
  --location SUBORDINATE_CA_POOL_LOCATION \
  --role roles/privateca.certificateManager \
  --member="serviceAccount: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
```

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 radice (ROOT_CA_POOL_URI). Il formato è:

//privateca.googleapis.com/projects/PROJECT_ID/locations/ROOT_CA_POOL_LOCATION/caPools/ROOT_CA_POOL_NAME

Applica le configurazioni al cluster:

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

Creare un servizio gRPC proxyless 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. Questo semplifica i passaggi successivi perché il deployment conosce il nome del NEG senza doverla cercare.

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 utilizzato dal pod del server gRPC.
La specifica utilizza il campo name nell'annotazione cloud.google.com/neg del per specificare il nome NEG example-grpc-server.
La variabile ${PROJNUM} rappresenta il numero del progetto.
La specifica utilizza la sezione initContainers per eseguire un generatore di bootstrap al fine di compilare il file di bootstrap necessario alla libreria gRPC senza proxy. Questo file di bootstrap si trova in /tmp/grpc-xds/td-grpc-bootstrap.json nel contenitore del server gRPC chiamato example-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, ogni pod riceve un volume al livello /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 certificati per il dominio di attendibilità locale per i carichi di lavoro, ovvero il pool di carichi di lavoro del cluster.

Il certificato foglia in certificates.pem contiene il seguente testo normale Asserzione di identità SPIFFE:

spiffe://WORKLOAD_POOL/ns/NAMESPACE/sa/KUBERNETES_SERVICE_ACCOUNT

In questa affermazione:

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 ambiente l'account di servizio.

Le seguenti istruzioni relative alla tua lingua creano la specifica da utilizzare in questo esempio.

Java

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

Python

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

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 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 in questa sezione sono simili a quelli in Configurare Cloud Service Mesh con i componenti di bilanciamento del carico ma ci sono alcune modifiche, come descritto nelle sezioni che seguono.

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 una porta di distribuzione aggiuntiva designata come porta per il controllo di integrità. Questo viene collegato a un servizio di controllo di integrità speciale, come testo normale o TLS a quella porta.

Il helloworld server di esempio xDS utilizza PORT_NUMBER + 1 come porta per il controllo di integrità in testo normale. L'esempio utilizza la porta 50052 come porta di controllo di integrità perché 50051 è la porta del server di applicazioni gRPC.

Nel secondo approccio, configuri il controllo di integrità per verificare solo la connettività TCP alla porta di servizio dell'applicazione. In questo modo viene controllata solo la connettività genera traffico non necessario sul server anche quando non vengono handshake TLS. Per questo motivo, ti consigliamo di utilizzare il primo approccio.

Crea il controllo di integrità. Tieni presente che il controllo di integrità non inizia prima devi creare e avviare 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 crei un controllo di integrità TCP, cosa sconsigliato, 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 al valore 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 gruppo di istanze elastiche 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`

Questo processo è simile a quello della configurazione delle risorse Mesh e GRPCRoute in Configura servizi gRPC senza proxy.

Crea la specifica Mesh e salvala in un file denominato mesh.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 denominato grpc_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 specifica grpc_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 a TLS del server e TLS del client norme:

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 lato server

Per prima cosa, crea un criterio TLS del server. Il criterio chiede al lato server gRPC di usare 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).

Il passo successivo è creare 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. Specifica le etichette dei metadati utilizzando MATCH_ALL o un valore supportato. Puoi trovare le etichette dei metadati supportate nel campo endpointMatcher.metadataLabelMatcher.metadataLabelMatchCriteria del documento NetworkServicesEndpointPolicy. Crei il criterio dell'endpoint con un file temporaneo ep-mtls-psms.yaml che contiene i valori per la risorsa del criterio dell'endpoint utilizzando il criterio che hai 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 criterio TLS del server denominata server-mtls-policy importando il file temporaneo server-mtls-policy.yaml:

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

Crea il criterio dell'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 sul lato client

Il criterio di sicurezza lato client è associato al servizio di backend. Quando un cliente accede a un backend (il server gRPC) tramite il servizio di backend, il criterio di sicurezza lato client 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 temporaneo client-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 messaggio SecuritySettings 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 che example-grpc-server in subjectAltNames è 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à creato. Questi passaggi esportano i contenuti attuali del servizio di backend, aggiungi client securitySetting 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 è ora completa, inclusa la sicurezza lato client e lato server. Successivamente, prepara ed esegui i carichi di lavoro del server e del 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 fa quanto segue.

Viene creato un account di servizio Kubernetes example-grpc-client utilizzato dal pod client gRPC.
${PROJNUM} rappresenta il numero del progetto e deve essere sostituita con il numero effettivo.

Aggiungi la seguente annotazione alla specifica del pod:

  annotations:
    security.cloud.google.com/use-workload-certificates: ""

Al momento della creazione, ogni pod riceve un volume al livello /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 radice per l'amministratore locale attendibile per i carichi di lavoro, ovvero il pool di carichi di lavoro del cluster.

Il certificato foglia in certificates.pem contiene il seguente testo normale Asserzione di identità SPIFFE:

spiffe://WORKLOAD_POOL/ns/NAMESPACE/sa/KUBERNETES_SERVICE_ACCOUNT

In questa affermazione:

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

Ottieni il nome del pod creato per il servizio example-grpc-server:

kubectl get pods | grep example-grpc-server

Visualizzerai dei feedback come i seguenti:

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 la versione 1.42.1 di gRPC Java e crea l'applicazione server 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 server con il flag --xds-creds per indicare la sicurezza abilitata per xDS, utilizzando 50051 come porta di ascolto e xds-server come nome di identificazione del server:
```
./build/install/example-xds/bin/xds-hello-world-server --xds-creds 50051 xds-server
```
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
```

C++

Recupera il nome del pod creato per il servizio example-grpc-server:

kubectl get pods | grep example-grpc-server

Visualizzerai dei feedback come i seguenti:

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 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 e xds_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 Cloud Service Mesh, viene visualizzato il seguente output:
```
Listening on port 50051
plain text health service listening on port 50052
```

Python

Ottieni il nome del pod creato per il servizio example-grpc-server:

kubectl get pods | grep example-grpc-server

Visualizzerai dei feedback come i seguenti:

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 usando 50051 come porta di ascolto.
```
python3 server.py 50051 --xds-creds
```

Dopo che il server ha ottenuto la configurazione necessaria da 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

Visualizzerai dei feedback come i seguenti:

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 /tmp/grpc-xds/td-grpc-bootstrap.json corrisponde allo schema descritto in 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

Crea ed esegui il server con il flag --xds_creds per indicare Sicurezza abilitata per xDS, utilizzando 50051 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 da 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 dimostrare che il tuo servizio è integro dopo l'avvio del server.

Esegui il client e verifica la configurazione

Crea ed esegui il client helloworld abilitato per xDS nel pod del client che hai creato in precedenza.

Java

Ottieni il nome del pod del client:

kubectl get pods | grep example-grpc-client

Ecco dei feedback:

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/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 nome client e stringa di connessione di destinazione:
```
./build/install/example-xds/bin/xds-hello-world-client --xds-creds xds-client \
      xds:///helloworld-gke:8000
```
Dovresti vedere un output simile al seguente:
```
Greeting: Hello xds-client, from xds-server
```

C++

Recupera il nome del pod del cliente:

kubectl get pods | grep example-grpc-client

Ecco dei feedback:

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/bash

Una volta all'interno della shell, scarica gRPC C++ e compila 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

Ecco dei feedback:

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/bash

Una volta all'interno della shell, scarica la versione 1.41.0 di gRPC Python e compila 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 nome client e 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

Ecco dei feedback:

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/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
```

Crea ed esegui il client con il flag --xds_creds per indicare Sicurezza abilitata per xDS, nome client e 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

Il supporto di gRFC A41 è necessario per il supporto dei criteri di autorizzazione. Puoi trovare le versioni in lingua 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 in grpc_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 specifica grpc_route.yaml.

gcloud network-services grpc-routes import helloworld-grpc-route \
  --source=grpc_route.yaml \
  --location=global

Le istruzioni riportate di seguito creano un criterio di autorizzazione che consente le richieste inviate dall'account example-grpc-client in cui 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 dell'endpoint per fare 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 criterio di autorizzazione devono essere applicati alle richieste in entrata ai pod i cui file di bootstrap gRPC 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

Utilizza queste istruzioni per verificare che il criterio di autorizzazione funzioni in modo corretto.

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 questi 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 vedere 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 riprova l'intera procedura di verifica.

Vai

Apri una shell per il pod client che hai utilizzato in precedenza.

kubectl exec -it example-grpc-client-7c969bb997-9fzjv -- /bin/bash

Nella shell dei comandi, esegui questi 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 vedere 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 in . Attendi qualche minuto e riprova l'intera procedura di verifica.

Utilizza TLS anziché mTLS

In questo esempio, l'utilizzo di TLS richiede solo una piccola modifica.

In ServerTlsPolicy, inserisci mtlsPolicy:

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, ma clientCertificate 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 è simile a quello di Java. Le istruzioni utilizzano un'immagine Docker preesistente ottenuta 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. Commenta la riga esistente che imposta il valore di WALLET_DOCKER_IMAGE sull'immagine Docker Go e rimuovi il commento dalla riga che imposta il valore di WALLET_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 seguendo le istruzioni per l'esempio hello world. o la funzione create_cluster nello script 20-cluster.sh.
Crea autorità di certificazione private seguendo le istruzioni per il servizio CA 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 script 40-k8s-resources.sh.
Per ciascuno dei servizi che hai creato, crea un controllo di integrità e un servizio di backend utilizzando create_health_check e create_backend_service nello script 50-td-components.sh.
Crea i componenti di routing di Cloud Service Mesh utilizzando create_routing_components nello script 60-routing-components.sh.
Crea i componenti di sicurezza di Cloud Service Mesh per ogni servizio di backend utilizzando create_security_components nello script 70-security-components.sh.
Crea il deployment del client Wallet utilizzando create_client_deployment nello script 75-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à le credenziali 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 gRPC examples.
Modifica il file 00-common-env.sh. Commenta la riga esistente che imposta il valore di WALLET_DOCKER_IMAGE sull'immagine Docker Go e rimuovi il commento dalla riga che imposta il valore di WALLET_DOCKER_IMAGE su 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 seguendo le istruzioni per l'esempio hello world. o la funzione create_cluster nello script 20-cluster.sh.
Crea autorità di certificazione private seguendo le istruzioni per il servizio CA 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 script 40-k8s-resources.sh.
Per ciascuno dei servizi che hai creato, crea un controllo di integrità e un servizio di backend utilizzando create_health_check e create_backend_service nello script 50-td-components.sh.
Crea i componenti di routing di Cloud Service Mesh utilizzando create_routing_components nello script 60-routing-components.sh.
Crea i componenti di sicurezza di Cloud Service Mesh per ogni servizio di backend utilizzando create_security_components nello script 70-security-components.sh.
Crea il deployment del client Wallet utilizzando create_client_deployment in script 75-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 usa già XdsChannel e XdsServer credenziali durante la configurazione della sicurezza senza proxy.

Le istruzioni utilizzano un'immagine Docker preesistente ottenuta 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 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 script 10.apis.sh.
Crea un cluster utilizzando le istruzioni per l'esempio hello world. o la funzione create_cluster nello script 20-cluster.sh.
Crea autorità di certificazione private seguendo le istruzioni per il servizio CA 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 script 40-k8s-resources.sh.
Per ciascuno dei servizi che hai creato, crea un controllo di integrità e un servizio di backend utilizzando create_health_check e create_backend_service nello script 50-td-components.sh.
Crea i componenti di routing di Cloud Service Mesh utilizzando create_routing_components nello script 60-routing-components.sh.
Crea i componenti di sicurezza di Cloud Service Mesh per ogni servizio di backend utilizzando create_security_components nello script 70-security-components.sh.
Crea il deployment del client Wallet utilizzando create_client_deployment in script 75-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 del file di bootstrap.

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 sicurezza gRPC senza proxy funzionalità. Il server gRPC richiede un altro campo. R il 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 e il nome della rete del progetto Google Cloud utilizzando l'ID nodo in questo formato:

projects/{project number}/networks/{network name}/nodes/[UNIQUE_ID]

Un esempio per il progetto numero 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 la risorsa Listener da 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 usa questo valore per comporre il nome della risorsa per recuperare la 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`	struct JSON	`google_cloud_private_spiffe`	Obbligatorio. Il valore è uno struct JSON che rappresenta una mappa di nomi per le istanze dei provider di certificati. Viene utilizzata un'istanza del provider di certificati per recuperare i certificati radice e dell'identità. Il file di bootstrap di esempio contiene un nome: `google_cloud_private_spiffe` con la struttura JSON dell'istanza del provider di certificati come valore. Ogni struct JSON dell'istanza del provider di certificati ha due campi: `plugin_name`. Valore obbligatorio che identifica il plug-in del provider di certificati da utilizzare come richiesto dall'architettura dei plug-in di gRPC per i provider di certificati. gRPC ha il supporto integrato per il plug-in di monitoraggio file utilizzato in questa configurazione. Il plugin plugin_name `file_watcher`. `config`. Valore obbligatorio che identifica il blog di configurazione JSON per il plug-in `file_watcher`. Lo schema e i contenuti dipendono dal plug-in.

I contenuti della struttura JSON config per il plug-in file_watcher sono:

certificate_file: stringa obbligatoria. Questo valore indica la posizione del certificato di identità.
private_key_file: stringa obbligatoria. Il valore è la posizione del file della chiave privata, 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, specificate mediante la rappresentazione in formato stringa del mapping JSON di Duration. Il valore predefinito è "600s", ovvero 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ù utilizzate sono:

--output: utilizza questa opzione per specificare la posizione del file di bootstrap di output è scritto, ad esempio, nel comando --output /tmp/bootstrap/td-grpc-bootstrap.json genera il file di bootstrap in /tmp/bootstrap/td-grpc-bootstrap.json in al file system del pod.
--config-mesh-experimental: utilizza questa opzione per specificare il nome della maglia corrispondente alla risorsa Mesh.
--node-metadata: utilizza questo flag per completare i metadati del nodo in il file di bootstrap. Questa operazione è obbligatoria se utilizzi i matcher delle etichette dei metadati EndpointPolicy in cui Cloud Service Mesh utilizza i dati delle etichette nella sezione dei metadati dei nodi del file di bootstrap. L'argomento viene fornito 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 tuo 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 tuo server gRPC non utilizza TLS/mTLS anche con la configurazione di Cloud Service Mesh corretta

Assicurati di specificare GRPC_SERVER nella configurazione dei criteri degli 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 `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 verificare 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, il motivo potrebbe essere uno dei seguenti:

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 il tuo mesh di servizi proxyless, segui queste istruzioni per determinare la causa.

Disabilita la sicurezza senza proxy ed elimina i problemi del servizio senza proxy e il bilanciamento del carico del mesh. Per disattivare la sicurezza nella mesh, procedi in uno dei seguenti modi:
1. Utilizza le credenziali in testo normale lato client e lato server OPPURE
2. non configurare la sicurezza per il servizio di backend e il criterio dell'endpoint la 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 per utilizzare le credenziali xDS con testo normale o non sicure come credenziali di riserva. Mantieni Cloud Service Mesh con la sicurezza disabilitata, come spiegato in precedenza. In questo caso, anche se gRPC consente a Cloud Service Mesh di configurare la sicurezza, Cloud Service Mesh non invia informazioni sulla sicurezza, nel qual caso gRPC dovrebbe ricorrere alle 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:
1. 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.
2. Assicurati che Cloud Service Mesh non abbia la sicurezza abilitata in CDS che vengono inviate ai carichi di lavoro.
3. Assicurati che i carichi di lavoro non utilizzino le modalità TLS o mTLS nelle relative i canali di notifica. Se vedi messaggi di log relativi agli handshake TLS, controlla del codice sorgente della tua applicazione e di assicurarti di utilizzare 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 questa funzionalità siano resi disponibili nella directory specificata, /var/run/secrets/workload-spiffe-credentials/.
Attiva TLS (anziché mTLS) nel tuo mesh, come descritto in precedenza, e riavvia i carichi di lavoro client e server.
1. Aumenta il livello di logging sia lato client che lato server per poter vedere i messaggi xDS scambiati tra gRPC e Cloud Service Mesh.
2. 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 carichi di lavoro per il cluster. che è ${PROJECT_ID}.svc.id.goog
K8S_NAMESPACE: lo spazio dei nomi Kubernetes utilizzato per il deployment dell'oggetto servizio
SERVICE_ACCOUNT: l'account di servizio Kubernetes che hai utilizzato nel deployment. del servizio

Per ogni servizio Kubernetes collegato al servizio di backend come gruppo di endpoint di rete, assicurati di aver calcolato correttamente l'ID SPIFFE e di averlo aggiunto al campo subjectAltNames nel 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:
1. Catena di certificati insieme al certificato foglia: "/var/run/secrets/workload-spiffe-credentials/certificates.pem"
2. Chiave privata: "/var/run/secrets/workload-spiffe-credentials/private_key.pem"
3. Bundle CA: "/var/run/secrets/workload-spiffe-credentials/ca_certificates.pem"

Se i certificati indicati nel passaggio precedente non sono disponibili:

  gcloud privateca subordinates describe SUBORDINATE_CA_POOL_NAME 

    --location=LOCATION

Verifica che il piano di controllo di GKE abbia l'associazione del ruolo IAM corretta, grantandogli l'accesso al servizio CA:

# 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 il certificato finale al /var/run/secrets/workload-spiffe-credentials/certificates.pem. Per controllare, esegui questo comando:
```
cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -text -noout | grep "Not After"
```

Esegui per verificare che il tipo di chiave sia supportato dalla tua applicazione questo comando:

cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -text -noout | grep "Public Key Algorithm" -A 3

Verifica che la tua applicazione Java gRPC abbia i seguenti keyAlgorithm nel file YAML WorkloadCertificateConfig:

  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 eseguire l'ultima versione di gcloud CLI:

gcloud components update

Tieni presente che il flag --enable-mesh-certificates funziona solo con gcloud beta.

I pod non si avviano

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 o TrustConfig non sono configurati correttamente o mancante.
Le RP non vengono approvate.

Puoi verificare se il provisioning dei certificati non va a buon fine controllando gli eventi del pod.

Controlla lo stato del tuo pod:
```
kubectl get pod -n POD_NAMESPACE POD_NAME
```
Sostituisci quanto segue:
- POD_NAMESPACE: lo spazio dei nomi del pod.
- POD_NAME: il nome del pod.

Controlla gli eventi recenti del tuo pod:

kubectl describe pod -n POD_NAMESPACE POD_NAME

Se il provisioning dei certificati non va a buon fine, viene visualizzato un evento con Type=Warning, Reason=FailedMount, From=kubelet e un campo Message che inizia con MountVolume.SetUp failed for volume "gke-workload-certificates". Il campo Message contiene informazioni per la risoluzione dei problemi.

Events:
  Type     Reason       Age                From       Message
  ----     ------       ----               ----       -------
  Warning  FailedMount  13s (x7 over 46s)  kubelet    MountVolume.SetUp failed for volume "gke-workload-certificates" : rpc error: code = Internal desc = unable to mount volume: store.CreateVolume, err: unable to create volume "csi-4d540ed59ef937fbb41a9bf5380a5a534edb3eedf037fe64be36bab0abf45c9c": caPEM is nil (check active WorkloadCertificateConfig)

Consulta i seguenti passaggi per la risoluzione dei problemi se i pod non si avviano a causa di oggetti configurati in modo errato o di CSR rifiutate.

La configurazione di `WorkloadCertificateConfig` o `TrustConfig` non è corretta

Assicurati di aver creato i campi WorkloadCertificateConfig e TrustConfig correttamente gli oggetti. 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 e status: "True".
```
status:
  conditions:
  - lastTransitionTime: "2021-03-04T22:24:11Z"
    message: WorkloadCertificateConfig is ready
    observedGeneration: 1
    reason: ConfigReady
    status: "True"
    type: Ready
```
Per gli oggetti non validi, viene invece visualizzato status: "False". I campireasone message contengono ulteriori dettagli sulla risoluzione dei problemi.

I CSR non sono approvati

Se si verifica un problema durante la procedura di approvazione del CSR, puoi controllare i dettagli dell'errore nelle condizioni type: Approved e type: Issued del CSR.

Elenca i CSR pertinenti utilizzando kubectl:

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

Scegli un CSR che sia Approved e non Issued oppure non sia Approved.
Ottieni i dettagli della CSR selezionata con kubectl:
```
kubectl get csr CSR_NAME -o yaml
```
Sostituisci CSR_NAME con il nome del CSR che hai scelto.

Un CSR valido ha una condizione con type: Approved e status: "True" e un certificato valido nel campo status.certificate:

status:
  certificate: <base64-encoded data>
  conditions:
  - lastTransitionTime: "2021-03-04T21:58:46Z"
    lastUpdateTime: "2021-03-04T21:58:46Z"
    message: Approved CSR because it is a valid SPIFFE SVID for the correct identity.
    reason: AutoApproved
    status: "True"
    type: Approved

Le informazioni per la risoluzione dei problemi relativi a CSR non valide vengono visualizzate in message e reason campi.

Nei pod mancano i certificati

Recupera la specifica 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'elemento security.cloud.google.com/use-workload-certificates descritta in Configurare i pod per ricevere 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 nel pod:
- Pacchetto 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
Se i file non sono disponibili, segui questi passaggi:
1. Recupera l'istanza del servizio CA (anteprima) per il cluster:
```
kubectl get workloadcertificateconfigs default -o jsonpath '{.spec.certificateAuthorityConfig.certificateAuthorityServiceConfig.endpointURI}'
```
2. 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 essere subordinates o roots.
  - ISSUING_CA_NAME: il nome della CA emittente.
  - ISSUING_CA_LOCATION: la regione della CA emittente.
3. 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.
4. 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 del progetto del cluster.
5. 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.
6. Nel criterio IAM, verifica che l'associazione dei criteri privateca.certificateManager esista:
```
...
- members:
  - serviceAccount: service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com
  role: roles/privateca.certificateManager
...
```
  In questo esempio, PROJECT_NUMBER è il numero del 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 l'autorità di certificazione emittente utilizzi la stessa famiglia di chiavi della chiave del certificato.
1. Visualizza lo stato del servizio CA (anteprima) istanza:
```
gcloud privateca ISSUING_CA_TYPE describe ISSUING_CA_NAME \
  --location ISSUING_CA_LOCATION
```
  Sostituisci quanto segue:
  - ISSUING_CA_TYPE: il tipo di CA emittente, che deve essere subordinates o roots.
  - ISSUING_CA_NAME: il nome della CA emittente.
  - ISSUING_CA_LOCATION: la regione della CA emittente.
2. Verifica che keySpec.algorithm nell'output sia lo stesso algoritmo di chiave che hai definito nel WorkloadCertificateConfig manifest YAML. L'output è simile al seguente:
```
config:
  ...
  subjectConfig:
    commonName: td-sub-ca
    subject:
      organization: TestOrgLLC
    subjectAltName: {}
createTime: '2021-05-04T05:37:58.329293525Z'
issuingOptions:
  includeCaCertUrl: true
keySpec:
  algorithm: RSA_PKCS1_2048_SHA256
 ...
```

I certificati vengono rifiutati

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 carichi di lavoro si trovino nello stesso dominio attendibile della CA. I certificati del mesh GKE supportano la comunicazione tra i carichi di lavoro in un singolo dominio attendibile.

Limitazioni

La sicurezza del servizio Cloud Service Mesh è supportata solo 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.

Configurare la sicurezza del servizio con gRPC proxyless

Requisiti

Configurare Identity and Access Management

Preparati per la configurazione

Aggiorna i client e i server gRPC alla versione corretta

Aggiorna il file di bootstrap

Panoramica della configurazione

Aggiorna Google Cloud CLI

Imposta le variabili di ambiente

Attivare l'accesso alle API richieste

Crea o aggiorna un cluster GKE

Registra i cluster con un parco risorse

Creare autorità di certificazione per emettere certificati

Creare un servizio gRPC proxyless con NEG

Java

C++

Python

Vai

Configura Cloud Service Mesh con i componenti di bilanciamento del carico di Google Cloud

Crea il controllo di integrità, la regola firewall e il servizio di backend

Crea le risorse Mesh e GRPCRoute

Configura Cloud Service Mesh con sicurezza gRPC senza proxy

Formato per i riferimenti alle norme

Configurare mTLS lato server

Configurare mTLS sul lato client

Verificare la configurazione

Crea un client gRPC senza proxy

Java

C++

Python

Vai

Esegui il server

Java

C++

Python

Vai

Esegui il client e verifica la configurazione

Java

C++

Python

Vai

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

gcloud

Convalida il criterio di autorizzazione

Java

Vai

Utilizza TLS anziché mTLS

Utilizzare la sicurezza del servizio con l'esempio di Wallet

Java

C++

Vai

File di bootstrap

Aggiornamenti al file di bootstrap per il servizio di sicurezza

Campi di configurazione della sicurezza nel file di bootstrap

Generatore di bootstrap

Elimina il deployment

Risoluzione dei problemi

I carichi di lavoro non riescono a recuperare la configurazione da Cloud Service Mesh

Il tuo server gRPC non utilizza TLS/mTLS anche con la configurazione di Cloud Service Mesh corretta

Non puoi creare il cluster GKE con la versione cluster richiesta

Viene visualizzato un errore No usable endpoint

I carichi di lavoro non sono in grado di comunicare nella configurazione di sicurezza

Il client ha errore e appare un CertificateException e un messaggio Peer certificate SAN check failed

Le applicazioni non possono utilizzare i certificati mTLS con la libreria gRPC

Il certificato di un'applicazione viene rifiutato dal client, dal server o dal peer

I pod rimangono in uno stato di attesa

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

I pod non si avviano

La configurazione di WorkloadCertificateConfig o TrustConfig non è corretta

I CSR non sono approvati

Nei pod mancano i certificati

Le applicazioni non possono utilizzare le credenziali mTLS emesse

I certificati vengono rifiutati

Limitazioni

Crea le risorse `Mesh` e `GRPCRoute`

Viene visualizzato un errore `No usable endpoint`

Il client ha errore e appare un `CertificateException` e un messaggio `Peer certificate SAN check failed`

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

La configurazione di `WorkloadCertificateConfig` o `TrustConfig` non è corretta