Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Configura la sicurezza del servizio con gRPC proxyless

Questa guida mostra come configurare un servizio di sicurezza per il mesh di servizi gRPC proxyless.

Requisiti

Prima di configurare la sicurezza del servizio per il mesh di servizi senza proxy gRPC, assicurati di soddisfare i seguenti requisiti.

Configura Identity and Access Management

Devi disporre delle autorizzazioni richieste per utilizzare Google Kubernetes Engine. Come minimo, devi disporre dei seguenti ruoli:

  • roles/container.clusterAdmin ruolo GKE
  • Ruolo roles/compute.instanceAdmin Compute Engine
  • Ruolo roles/iam.serviceAccountUser

Per creare le risorse necessarie per la configurazione, devi avere il ruolo compute.NetworkAdmin. Questo ruolo contiene tutte le autorizzazioni necessarie per creare, aggiornare, eliminare, elencare e utilizzare le risorse richieste. Se sei l'editor proprietario del tuo progetto, questo ruolo viene assegnato automaticamente a te.

Tieni presente che networksecurity.googleapis.com.clientTlsPolicies.use e networksecurity.googleapis.com.serverTlsPolicies.use non vengono applicati quando fai riferimento a queste risorse nel servizio di backend e scegli come target le risorse proxy HTTPS.

Se in futuro verrà applicata la conformità e utilizzi il ruolo compute.NetworkAdmin, non noterai alcun problema durante l'applicazione di questo controllo.

Se utilizzi ruoli personalizzati e questo controllo verrà applicato in futuro, assicurati di includere la rispettiva autorizzazione .use. In caso contrario, in futuro, il tuo ruolo personalizzato potrebbe non disporre delle autorizzazioni necessarie per fare riferimento, rispettivamente, a clientTlsPolicy o serverTlsPolicy del servizio di backend o del proxy HTTPS di destinazione.

Preparati per la configurazione

La sicurezza del mesh di servizi senza proxy (PSM) aggiunge sicurezza a un mesh di servizi configurato per il bilanciamento del carico in base alla documentazione relativa ai servizi gRPC senza proxy. In un mesh di servizi senza proxy, un client gRPC utilizza lo schema xds: nell'URI per accedere al servizio, il che consente il bilanciamento del carico PSM e le funzionalità di individuazione degli endpoint.

Aggiorna i client e i server gRPC alla versione corretta

Crea o ricrea le tue applicazioni utilizzando la versione gRPC minima supportata per la lingua.

Aggiorna il file bootstrap

Le applicazioni gRPC utilizzano un singolo file di bootstrap, che deve contenere tutti i campi obbligatori dal codice lato client e server gRPC. Un generatore di bootstrap genera automaticamente il file bootstrap per includere flag e valori necessari per la sicurezza di PSM. Per ulteriori informazioni, consulta la sezione File di avvio, che include un file di bootstrap di esempio.

Panoramica della configurazione

Questo processo di configurazione è un'estensione della configurazione di Traffic Director con i servizi GKE e gRPC proxy. I passaggi non modificati esistenti della procedura di configurazione fanno riferimento ovunque vengano applicati.

Ecco i principali miglioramenti alla configurazione di Traffic Director con GKE:

  1. Configurazione del servizio CA in cui si creano pool di CA privati e le autorità di certificazione richieste.
  2. Creazione di un cluster GKE con funzionalità di GKE Workload Identity e certificati mesh e integrazione di CA Service.
  3. Configurazione dell'emissione di certificati mesh nel cluster.
  4. Creazione degli account di servizio client e server in corso...
  5. Impostazione del server di esempio che utilizza le API xDS e le credenziali server xDS per acquisire la configurazione di sicurezza da Traffic Director.
  6. Configurare il client di esempio che utilizza le credenziali xDS.
  7. Aggiornamento della configurazione di Traffic Director in modo da includere la configurazione di sicurezza.

Puoi vedere alcuni esempi di codice per l'utilizzo delle credenziali xDS nelle seguenti posizioni:

Aggiorna Google Cloud CLI

Per aggiornare Google Cloud CLI, esegui questo comando:

gcloud components update

Imposta le variabili di ambiente

In questa guida vengono utilizzati i comandi di Cloud Shell e la ripetizione delle informazioni nei comandi è rappresentata da varie variabili di ambiente. Imposta i valori specifici sulle 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=YOUR_PROJECT_ID

# GKE cluster name and zone for this example.
CLUSTER_NAME="secure-psm-cluster"
ZONE="us-east1-d"

# 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

Abilita l'accesso alle API richieste

In questa sezione viene spiegato come abilitare l'accesso alle API necessarie.

  1. Esegui il comando seguente per abilitare Traffic Director e altre API necessarie per la sicurezza del mesh di servizi gRPC 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

  2. Esegui il comando seguente per consentire all'account di servizio predefinito di accedere all'API Security Director di Traffic Director.

    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 dei servizi di Traffic Director dipende dall'integrazione del servizio CA con GKE. Il cluster GKE deve soddisfare i seguenti requisiti in aggiunta ai requisiti per la configurazione:

  • Usa una versione minima del cluster pari a 1.21.4-gke.1801. Se hai bisogno di funzionalità che sono in una versione successiva, puoi ottenerla dal canale di rilascio rapido.
  • Il cluster GKE deve essere abilitato e configurato con certificati mesh, come descritto nella sezione Creare autorità di certificazione per emettere i certificati.

  1. Creare un nuovo cluster che utilizza Workload Identity. Se stai aggiornando un cluster esistente, vai al passaggio successivo. Il valore fornito per --tags deve corrispondere al nome passato al flag --target-tags per il comando firewall-rules create nella sezione Configurazione di Traffic Director 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

    Il completamento della creazione del cluster potrebbe richiedere diversi minuti.

  2. Se utilizzi un cluster esistente, attiva Workload Identity e i certificati mesh GKE. Assicurati che il cluster sia stato creato con il flag --enable-ip-alias, che non può essere utilizzato con il comando update.

    gcloud container clusters update CLUSTER_NAME \
  --enable-mesh-certificates

  3. Esegui questo comando per passare al nuovo cluster come cluster predefinito per i tuoi comandi kubectl:

    gcloud container clusters get-credentials CLUSTER_NAME \
  --zone ZONE

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 su più progetti.

Tieni presente che il completamento di questi passaggi può richiedere fino a dieci minuti.

  1. Registra il cluster con il parco risorse:

    gcloud container fleet memberships register CLUSTER_NAME \
  --gke-cluster=ZONE/CLUSTER_NAME \
  --enable-workload-identity \
  --manifest-output-file=MANIFEST-FILE_NAME

    Sostituisci le variabili come indicato di seguito:

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

    Una volta completata la registrazione, visualizzerai un messaggio simile al seguente:

    Finished registering the cluster CLUSTER_NAME with the fleet.

  2. Applica il file manifest generato al cluster:

    kubectl apply -f MANIFEST-FILE_NAME

    Una volta completata la procedura, verranno visualizzati messaggi come i seguenti:

    namespace/gke-connect created
serviceaccount/connect-agent-sa created
podsecuritypolicy.policy/gkeconnect-psp created
role.rbac.authorization.k8s.io/gkeconnect-psp:role created
rolebinding.rbac.authorization.k8s.io/gkeconnect-psp:rolebinding created
role.rbac.authorization.k8s.io/agent-updater created
rolebinding.rbac.authorization.k8s.io/agent-updater created
role.rbac.authorization.k8s.io/gke-connect-agent-20210416-01-00 created
clusterrole.rbac.authorization.k8s.io/gke-connect-impersonation-20210416-01-00 created
clusterrolebinding.rbac.authorization.k8s.io/gke-connect-impersonation-20210416-01-00 created
clusterrolebinding.rbac.authorization.k8s.io/gke-connect-feature-authorizer-20210416-01-00 created
rolebinding.rbac.authorization.k8s.io/gke-connect-agent-20210416-01-00 created
role.rbac.authorization.k8s.io/gke-connect-namespace-getter created
rolebinding.rbac.authorization.k8s.io/gke-connect-namespace-getter created
secret/http-proxy created
deployment.apps/gke-connect-agent-20210416-01-00 created
service/gke-connect-monitoring created
secret/creds-gcp create

  3. Recupera la risorsa di appartenenza dal cluster:

    kubectl get memberships membership -o yaml

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

Crea autorità di certificazione per emettere i certificati

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

  • CA radice. Questa è la radice di attendibilità per tutti i certificati mesh emessi. Puoi utilizzare una CA radice esistente, se disponibile. Crea la CA radice nel livello enterprise, che è destinata all'emissione di certificati di lunga durata e a basso volume.
  • CA subordinata. Questa CA emette certificati per i carichi di lavoro. Crea la CA subordinata nell'area geografica in cui viene eseguito il deployment del cluster. Crea la CA subordinata nel livello devops, che è destinata all'emissione di certificati di breve durata e con volumi elevati.

La creazione di una CA subordinata è facoltativa, ma consigliamo vivamente di crearne una anziché utilizzare la 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 subordinata può trovarsi in una regione diversa dal tuo cluster, ma consigliamo vivamente di crearla nella stessa regione del cluster per ottimizzare le prestazioni. Tuttavia, puoi creare CA radice e subordinate in aree geografiche diverse senza influire sulle prestazioni o sulla 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
me-west1 Tel Aviv
northamerica-northeast1 Montréal
northamerica-northeast2 Toronto
southamerica-east1 San Paolo
southamerica-west1 Santiago
us-central1 Iowa
us-east1 Carolina del Sud
us-east4 Virginia del Nord
us-east5 Columbus
us-south1 Dallas
us-west1 Oregon
us-west2 Los Angeles
us-west3 Salt Lake City
us-west4 Las Vegas

L'elenco delle località supportate può essere verificato anche eseguendo questo comando:

gcloud privateca locations list

  1. Concedi l'ID 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 quella persona è l'utente corrente, puoi ottenere l'ID utente corrente con il comando shell $(gcloud auth list --filter=status:ACTIVE --format="value(account)").

    gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=MEMBER \
  --role=roles/privateca.caManager

  2. Concedi il ruolo role/privateca.admin per il servizio CA alle persone che devono modificare i criteri IAM, dove MEMBER è una persona che ha bisogno di questo accesso, in particolare, chiunque esegua i passaggi seguenti che concedono i ruoli privateca.auditor e privateca.certificateManager:

    gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=MEMBER \
  --role=roles/privateca.admin

  3. Crea il pool di servizi CA radice.

    gcloud privateca pools create ROOT_CA_POOL_NAME \
  --location ROOT_CA_POOL_LOCATION \
  --tier enterprise

  4. Crea una CA radice.

    gcloud privateca roots create ROOT_CA_NAME --pool ROOT_CA_POOL_NAME \
  --subject "CN=ROOT_CA_NAME, O=ROOT_CA_ORGANIZATION" \
  --key-algorithm="ec-p256-sha256" \
  --max-chain-length=1 \
  --location ROOT_CA_POOL_LOCATION

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

    • ROOT_CA_POOL_NAME=td_sec_pool
    • ROOT_CA_NAME=pkcs2-ca
    • ROOT_CA_POOL_LOCATION=us-east1
    • ROOT_CA_ORGANIZATION="TestCorpLLC"

  5. Crea il pool subordinato e la CA subordinata. Assicurati che la modalità di emissione basata sulla configurazione predefinita rimanga consentita.

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

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

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

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

  6. Concedi il ruolo IAM privateca.auditor per il pool di CA radice 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"

  7. Concedi il ruolo IAM privateca.certificateManager per il pool di CA subordinato 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"

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

    apiVersion: security.cloud.google.com/v1
kind: WorkloadCertificateConfig
metadata:
  name: default
spec:
  # Required. The CA service that issues your certificates.
  certificateAuthorityConfig:
    certificateAuthorityServiceConfig:
      endpointURI: ISSUING_CA_POOL_URI

  # Required. The key algorithm to use. Choice of RSA or ECDSA.
  #
  # To maximize compatibility with various TLS stacks, your workloads
  # should use keys of the same family as your root and subordinate CAs.
  #
  # To use RSA, specify configuration such as:
  #   keyAlgorithm:
  #     rsa:
  #       modulusSize: 4096
  #
  # Currently, the only supported ECDSA curves are "P256" and "P384", and the only
  # supported RSA modulus sizes are 2048, 3072 and 4096.
  keyAlgorithm:
    rsa:
      modulusSize: 4096

  # Optional. Validity duration of issued certificates, in seconds.
  #
  # Defaults to 86400 (1 day) if not specified.
  validityDurationSeconds: 86400

  # Optional. Try to start rotating the certificate once this
  # percentage of validityDurationSeconds is remaining.
  #
  # Defaults to 50 if not specified.
  rotationWindowPercentage: 50

    Sostituisci quanto segue:

    • L'ID 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 (consigliata) o la tua CA radice. Il formato è: 
      //privateca.googleapis.com/projects/PROJECT_ID/locations/SUBORDINATE_CA_POOL_LOCATION/caPools/SUBORDINATE_CA_POOL_NAME

  9. Salva la seguente configurazione YAML TrustConfig per comunicare al tuo 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

  10. Applica le configurazioni al tuo cluster:

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

Crea un servizio gRPC proxyless con NEG

Per la sicurezza di PSM, è necessario un server gRPC proxyless in grado di utilizzare xDS per acquisire la configurazione di sicurezza da Traffic Director. Questo passaggio è simile alla configurazione dei servizi GKE con NEG nella guida alla configurazione del bilanciamento del carico PSM, ma utilizzi il server helloworld abilitato per xDS nell'esempio DSx nel repository grpc-java anziché nell'immagine java-example-hostname.

In questo caso, creerai ed eseguirai questo server in un container creato da un'immagine openjdk:8-jdk. Puoi anche utilizzare la funzionalità denominata NEG, che ti consente di specificare un nome per il NEG. Questo semplifica i passaggi successivi, perché il tuo deployment conosce il nome del NEG senza doverlo cercare.

Di seguito è riportato un esempio completo della specifica Kubernetes del server gRPC. Nota:

  • 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 servizio 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 per completare il file bootstrap di cui ha bisogno la libreria gRPC proxyless. Questo file di avvio si trova all'indirizzo /tmp/grpc-xds/td-grpc-bootstrap.json nel container del server gRPC denominato example-grpc-server.

Aggiungi la seguente annotazione alle specifiche del pod:

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

Puoi vedere il posizionamento corretto nella specifica completa che segue.

Al momento della creazione, ogni pod riceve un volume di /var/run/secrets/workload-spiffe-credentials. Questo volume contiene quanto segue:

  • private_key.pem è una chiave privata generata automaticamente.
  • certificates.pem è un pacchetto di certificati in formato PEM che possono essere presentati a un altro pod come catena di certificati client o utilizzati come catena di certificati server.
  • ca_certificates.pem è un pacchetto di certificati in formato PEM da utilizzare come trust anchor quando viene convalidata la catena di certificati client presentata da un altro pod oppure la catena di certificati server ricevuta durante la connessione a un altro pod.

Tieni presente che ca_certificates.pem contiene certificati per il dominio trust locale per i carichi di lavoro, ovvero il pool di carichi di lavoro del cluster.

Il certificato foglia in certificates.pem contiene la seguente asserzione dell'identità SPIFFE in testo normale:

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

In questa affermazione:

  • WORKLOAD_POOL è il nome del pool dei carichi di lavoro del cluster.
  • NAMESPACE è lo spazio dei nomi del tuo account di servizio Kubernetes.
  • KUBERNETES_SERVICE_ACCOUNT è il nome del tuo account di servizio Kubernetes.

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

Java

  1. 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

  2. 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.13.0
       imagePullPolicy: Always
       args:
       - --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++

  1. 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

  2. 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.13.0
       imagePullPolicy: Always
       args:
       - --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

  1. 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

  2. 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.13.0
       imagePullPolicy: Always
       args:
       - --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

Go

  1. 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

  2. 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.13.0
       imagePullPolicy: Always
       args:
       - --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 indicato di seguito.

  1. Applica la specifica:

    kubectl apply -f example-grpc-server.yaml

  2. 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

  3. Esegui questi comandi per verificare che il servizio e il pod siano creati correttamente:

    kubectl get deploy/example-grpc-server
kubectl get svc/example-grpc-server

  4. Verifica che il nome NEG sia corretto:

    gcloud compute network-endpoint-groups list \
    --filter "name=example-grpc-server" --format "value(name)"

    Il comando riportato sopra dovrebbe restituire il nome NEG example-grpc-server.

Configura Traffic Director con i componenti di bilanciamento del carico di Google Cloud

I passaggi di questa sezione sono simili a quelli descritti in Configurazione di Traffic Director con i componenti di bilanciamento del carico, ma esistono alcune modifiche, descritte di seguito.

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

Se il server gRPC è configurato per l'utilizzo di mTLS, i controlli di integrità gRPC non funzionano perché il client di controllo di integrità non può presentare un certificato client valido ai server. Puoi risolvere questo problema in due modi.

Nel primo approccio, hai creato sul server una porta di gestione aggiuntiva designata come porta di controllo di integrità. Questa azione è collegata a uno speciale servizio di controllo di integrità, come testo normale o TLS sulla porta.

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

Nel secondo approccio, devi configurare il controllo di integrità in modo da controllare solo la connettività TCP alla porta di gestione delle applicazioni. Questo controlla solo la connettività e genera anche traffico non necessario sul server in caso di handshake TLS non riusciti. Per questo motivo, ti consigliamo di utilizzare il primo approccio.

  1. Crea il controllo di integrità. Tieni presente che il controllo di integrità non inizia finché non crei e avvii il server.

    • Se stai creando una porta di servizio designata per il controllo di integrità, che è l'approccio consigliato, utilizza questo comando:

      gcloud compute health-checks create grpc grpc-gke-helloworld-hc \
 --enable-logging --port 50052

    • Se stai creando un controllo di integrità TCP, che non è consigliabile, utilizza questo comando:

      gcloud compute health-checks create tcp grpc-gke-helloworld-hc \
--use-serving-port

  2. Crea il firewall. Assicurati che il valore di --target-tags corrisponda al valore fornito per --tags nella sezione Crea o aggiorna 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

  3. 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

  4. Collega il NEG al servizio di backend:

    gcloud compute backend-services add-backend grpc-gke-helloworld-service \
   --global \
   --network-endpoint-group example-grpc-server \
   --network-endpoint-group-zone ${ZONE} \
   --balancing-mode RATE \
   --max-rate-per-endpoint 5

Crea la mappa di regole di routing

La procedura è simile a quella utilizzata per creare una mappa di regole di routing nella configurazione di Traffic Director con Google Kubernetes Engine e nei servizi gRPC senza proxy.

  1. Crea la mappa URL:

    gcloud compute url-maps create grpc-gke-url-map \
   --default-service grpc-gke-helloworld-service

  2. Aggiungi il matcher percorso alla mappa URL:

    gcloud compute url-maps add-path-matcher grpc-gke-url-map \
   --default-service grpc-gke-helloworld-service \
   --path-matcher-name grpc-gke-path-matcher \
   --new-hosts helloworld-gke:8000

  3. Crea il proxy gRPC di destinazione:

    gcloud compute target-grpc-proxies create grpc-gke-proxy \
   --url-map grpc-gke-url-map --validate-for-proxyless

  4. Crea la regola di forwarding:

    gcloud compute forwarding-rules create grpc-gke-forwarding-rule \
  --global \
  --load-balancing-scheme=INTERNAL_SELF_MANAGED \
  --address=0.0.0.0 \
  --target-grpc-proxy=grpc-gke-proxy \
  --ports 8000 \
  --network default

Configura Traffic Director con la sicurezza gRPC proxyless

Questo esempio illustra come configurare mTLS sul lato client e sul server.

Formato per i riferimenti ai criteri

Nota il seguente formato obbligatorio per fare riferimento ai criteri TLS del server e del client:

projects/PROJECT_ID/locations/global/[serverTlsPolicies|clientTlsPolicies]/[server-tls-policy|client-mtls-policy]

Ad esempio:

projects/PROJECT_ID/locations/global/serverTlsPolicies/server-tls-policy

projects/PROJECT_ID/locations/global/clientTlsPolicies/client-mtls-policy

Configura mTLS sul lato server

Innanzitutto, devi creare un criterio TLS del server. Il criterio chiede al lato server gRPC di utilizzare la configurazione del plug-in certificateProvicerInstance identificata dal nome google_cloud_private_spiffe per il certificato di identità, che fa parte di serverCertificate. La sezione mtlsPolicy indica la sicurezza mTLS e utilizza lo stesso google_cloud_private_spiffe della configurazione del plug-in per clientValidationCa, che è la specifica del certificato radice (convalida).

A questo punto, crei un criterio dell'endpoint. Questo valore specifica che un backend, ad esempio un server gRPC, che utilizza la porta 50051 con etichette dei metadati prive o nessuna delle etichette, riceve il criterio TLS del server collegato denominato server-mtls-policy. Le etichette dei metadati vengono specificate utilizzando MATCH_ALL. Puoi creare il criterio dell'endpoint con un file temporaneo ep-mtls-psms.yaml contenente i valori per la risorsa del criterio dell'endpoint utilizzando il criterio già definito.

  1. 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

  2. Crea una risorsa del 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

  3. Crea il criterio endpoint creando il file temporaneo ep-mtls-psms.yaml:

    name: "ep-mtls-psms"
type: "GRPC_SERVER"
serverTlsPolicy: "projects/${PROJECT_ID}/locations/global/serverTlsPolicies/server-mtls-policy"
trafficPortSelector:
  ports:
  - "50051"
endpointMatcher:
  metadataLabelMatcher:
    metadataLabelMatchCriteria: "MATCH_ALL"
    metadataLabels:
    - labelName: app
      labelValue: helloworld

  4. 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

Configura mTLS sul lato client

Il criterio di sicurezza lato client è collegato al servizio di backend. Quando un client accede a un backend (il server gRPC) attraverso il servizio di backend, il criterio di sicurezza lato client associato viene inviato al client.

  1. Crea i contenuti della risorsa del criterio TLS del client in un file temporaneo denominato client-mtls-policy.yaml nella directory corrente:

    name: "client-mtls-policy"
clientCertificate:
  certificateProviderInstance:
    pluginInstance: google_cloud_private_spiffe
serverValidationCa:
- certificateProviderInstance:
    pluginInstance: google_cloud_private_spiffe

  2. Crea la risorsa del criterio TLS 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

  3. Crea uno snippet in un file temporaneo per fare riferimento a questo criterio e aggiungere i dettagli per subjectAltNames nel messaggio SecuritySettings, come nell'esempio seguente. Sostituisci ${PROJECT_ID} con il valore dell'ID progetto, che è il valore della variabile di ambiente ${PROJECT_ID} descritta sopra. Tieni presente che example-grpc-server in subjectAltNames è il nome dell'account di servizio Kubernetes utilizzato per il pod server gRPC nella specifica del 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

  4. Aggiungi il messaggio securitySettings al servizio di backend che hai già creato. Questi passaggi esportano i contenuti del servizio di backend corrente, aggiungono il messaggio securitySetting del client e reimportano i nuovi contenuti per 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 Traffic Director è ora completa, inclusa la sicurezza lato server e lato client. Successivamente, devi preparare ed eseguire i carichi di lavoro del server e del client. L'esempio viene completato.

Crea un client gRPC proxyless

Questo passaggio è simile a quello descritto in Creare un servizio gRPC senza proxy in alto. Utilizzi il client helloworld abilitato per xDS dalla directory di esempio xDS nel repository grpc-java. Puoi creare ed eseguire il client in un container creato da un'immagine openjdk:8-jdk. La specifica Kubernetes client gRPC esegue le operazioni seguenti.

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

Aggiungi la seguente annotazione alle specifiche del pod:

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

Al momento della creazione, ogni pod riceve un volume di /var/run/secrets/workload-spiffe-credentials. Questo volume contiene quanto segue:

  • private_key.pem è una chiave privata generata automaticamente.
  • certificates.pem è un pacchetto di certificati in formato PEM che possono essere presentati a un altro pod come catena di certificati client o utilizzati come catena di certificati server.
  • ca_certificates.pem è un pacchetto di certificati in formato PEM da utilizzare come trust anchor quando viene convalidata la catena di certificati client presentata da un altro pod oppure la catena di certificati server ricevuta durante la connessione a un altro pod.

Tieni presente che ca_certificates.pem contiene i certificati radice per il dominio trust locale per i carichi di lavoro, ovvero il pool di carichi di lavoro del cluster.

Il certificato foglia in certificates.pem contiene la seguente asserzione dell'identità SPIFFE in testo normale:

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

In questa affermazione:

  • WORKLOAD_POOL è il nome del pool dei 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 per la tua lingua creano la specifica da utilizzare in questo esempio.

Java

  1. 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

  2. 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.13.0
        imagePullPolicy: Always
        args:
        - --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

C++

  1. 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

  2. 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.13.0
        imagePullPolicy: Always
        args:
        - --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

  1. 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

  2. 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.13.0
        imagePullPolicy: Always
        args:
        - --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

Go

  1. 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

  2. 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.13.0
        imagePullPolicy: Always
        args:
        - --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 indicato di seguito.

  1. Applica la specifica:

    kubectl apply -f example-grpc-client.yaml

  2. 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

  3. Verifica che il pod 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 server che hai creato in precedenza.

Java

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

    kubectl get pods | grep example-grpc-server

    Riceverai un feedback come il seguente:

    default    example-grpc-server-77548868d-l9hmf     1/1    Running   0     105s

  2. Apri una shell per il pod del server:

    kubectl exec -it example-grpc-server-77548868d-l9hmf -- /bin/bash

  3. Nella shell, verifica che il file bootstrap all'indirizzo /tmp/grpc-xds/td-grpc-bootstrap.json corrisponda allo schema descritto nella sezione File di avvio.

  4. Scarica gRPC Java versione 1.42.1 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

  5. 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

  6. Dopo che il server ha ottenuto la configurazione necessaria da Traffic Director, viene visualizzato il seguente output:

    Listening on port 50051
Plaintext health service listening on port 50052

C++

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

    kubectl get pods | grep example-grpc-server

    Riceverai un feedback come il seguente:

    default    example-grpc-server-77548868d-l9hmf     1/1    Running   0     105s

  2. Apri una shell per il pod del server:

    kubectl exec -it example-grpc-server-77548868d-l9hmf -- /bin/bash

  3. Nella shell, verifica che il file bootstrap all'indirizzo /tmp/grpc-xds/td-grpc-bootstrap.json corrisponda allo schema descritto nella sezione File di avvio.

  4. 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

  5. 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

  6. Dopo che il server ha ottenuto la configurazione necessaria da Traffic Director, viene visualizzato il seguente output:

    Listening on port 50051
Plaintext health service listening on port 50052

Python

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

    kubectl get pods | grep example-grpc-server

    Riceverai un feedback come il seguente:

    default    example-grpc-server-77548868d-l9hmf     1/1    Running   0     105s

  2. Apri una shell per il pod del server:

    kubectl exec -it example-grpc-server-77548868d-l9hmf -- /bin/bash

  3. Nella shell, verifica che il file bootstrap all'indirizzo /tmp/grpc-xds/td-grpc-bootstrap.json corrisponda allo schema descritto nella sezione File di avvio.

  4. 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

  5. Esegui il server con il flag --xds-creds per indicare la sicurezza abilitata per xDS, utilizzando 50051 come porta di ascolto.

    python3 server.py 50051 --xds-creds

  6. Dopo che il server ha ottenuto la configurazione necessaria da Traffic Director, 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

Go

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

    kubectl get pods | grep example-grpc-server

    Riceverai un feedback come il seguente:

    default    example-grpc-server-77548868d-l9hmf     1/1    Running   0     105s

  2. Apri una shell per il pod del server:

    kubectl exec -it example-grpc-server-77548868d-l9hmf -- /bin/sh

  3. Nella shell, verifica che il file bootstrap all'indirizzo /tmp/grpc-xds/td-grpc-bootstrap.json corrisponda allo schema descritto nella sezione File di avvio.

  4. Scarica gRPC Go versione 1.41.0 e vai alla directory contenente l'applicazione del 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

  5. Crea ed esegui il server con il flag --xds_creds per indicare la sicurezza abilitata per xDS, utilizzando 50051 come porta di ascolto:

    GRPC_GO_LOG_VERBOSITY_LEVEL=2 GRPC_GO_LOG_SEVERITY="info" \
  go run main.go \
  -xds_creds \
  -port 50051

  6. Dopo che il server ha ottenuto la configurazione necessaria da Traffic Director, 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 mostrare che il 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 client che hai creato in precedenza.

Java

  1. Recupera il nome del pod client:

    kubectl get pods | grep example-grpc-client

    Visualizzi un feedback come questo:

    default    example-grpc-client-7c969bb997-9fzjv     1/1    Running   0     105s

  2. Apri una shell per il pod client:

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

  3. Nella shell di comando, scarica gRPC Java versione 1.42.1 e crea 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

  4. Esegui il client con il flag --xds-creds per indicare la sicurezza abilitata per xDS, il nome client e la stringa di connessione di destinazione:

    ./build/install/example-xds/bin/xds-hello-world-client --xds-creds xds-client \
      xds:///helloworld-gke:8000

    Dovresti vedere un output simile al seguente:

    Greeting: Hello xds-client, from xds-server

C++

  1. Recupera il nome del pod client:

    kubectl get pods | grep example-grpc-client

    Visualizzi un feedback come questo:

    default    example-grpc-client-7c969bb997-9fzjv     1/1    Running   0     105s

  2. Apri una shell per il pod client:

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

  3. Dopo aver aperto la shell, scarica gRPC C++ e crea l'applicazione client xds-hello-world.

    apt-get update -y && \
        apt-get install -y \
            build-essential \
            clang \
            python3 \
            python3-dev

    curl -L https://github.com/grpc/grpc/archive/master.tar.gz | tar -xz

    cd grpc-master

    tools/bazel build examples/cpp/helloworld:xds_greeter_client

  4. Esegui il client con il flag --xds-creds per indicare la sicurezza abilitata per xDS, il nome 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 vedere un output simile al seguente:

    Greeter received: Hello world

Python

  1. Recupera il nome del pod client:

    kubectl get pods | grep example-grpc-client

    Visualizzi un feedback come questo:

    default    example-grpc-client-7c969bb997-9fzjv     1/1    Running   0     105s

  2. Apri una shell per il pod client:

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

  3. Dopo aver aperto la shell, scarica gRPC Python versione 1.41.0 e crea 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

  4. Esegui il client con il flag --xds-creds per indicare la sicurezza abilitata per xDS, il nome client e la stringa di connessione di destinazione:

    python3 client.py xds:///helloworld-gke:8000 --xds-creds

    Dovresti vedere un output simile al seguente:

    Greeter client received: Hello you from example-host!

Go

  1. Recupera il nome del pod client:

    kubectl get pods | grep example-grpc-client

    Visualizzi un feedback come questo:

    default    example-grpc-client-7c969bb997-9fzjv     1/1    Running   0     105s

  2. Apri una shell per il pod client:

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

  3. Dopo aver aperto la shell, scarica gRPC Go versione 1.42.0 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

  4. Crea ed esegui il client con il flag --xds_creds per indicare la sicurezza abilitata per xDS, il nome client e la stringa di connessione di destinazione:

    GRPC_GO_LOG_VERBOSITY_LEVEL=2 GRPC_GO_LOG_SEVERITY="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 al livello di servizio con un criterio di autorizzazione

L'assistenza gRFC A41 è obbligatoria per il supporto dei criteri di autorizzazione. Puoi trovare le versioni delle lingue richieste su github

Segui queste istruzioni per configurare l'accesso al livello di servizio con i criteri di autorizzazione. Prima di creare criteri di autorizzazione, leggi l'avvertenza nell'articolo 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.

gcloud compute url-maps add-host-rule grpc-gke-url-map \
   --path-matcher-name grpc-gke-path-matcher \
   --hosts helloworld-gke-noaccess:8000

Le seguenti istruzioni 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

  1. 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

  2. Importa il criterio.

    gcloud network-security authorization-policies import \
  helloworld-gke-authz-policy \
  --source=helloworld-gke-authz-policy.yaml \
  --location=global

  3. Aggiorna il criterio dell'endpoint per fare riferimento al nuovo criterio di autorizzazione aggiungendo quanto segue al file ep-mtls-psms.yaml.

    authorizationPolicy: projects/${PROJECT_ID}/locations/global/authorizationPolicies/helloworld-gke-authz-policy

    Il criterio endpoint ora specifica che sia mTLS sia il criterio di autorizzazione devono essere applicati alle richieste in entrata per i pod i cui file di bootstrap gRPC contengono l'etichetta app:helloworld.

  4. Importa il criterio:

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

Convalida il criterio di autorizzazione

Segui queste istruzioni per verificare che il criterio di autorizzazione funzioni correttamente.

Java

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

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

  2. Nella shell di comando, 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 vedere un output simile al seguente:

    Greeting: Hello xds-client, from xds-server

  3. Esegui di nuovo il client con il nome del server alternativo. Tenete 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, il criterio di autorizzazione potrebbe non essere ancora in uso. Attendi qualche minuto e riprova a eseguire l'intera procedura di verifica.

Go

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

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

  2. Nella shell di comando, 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="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

  3. Esegui di nuovo il client con il nome del server alternativo. Tenete 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="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, il criterio di autorizzazione potrebbe non essere ancora in uso. Attendi qualche minuto e riprova a eseguire l'intera procedura di verifica.

Utilizza TLS invece di mTLS

L'utilizzo di TLS in questo esempio richiede solo una piccola modifica.

  1. In ServerTlsPolicy, rilascia mtlsPolicy:

    cat << EOF > server-tls-policy.yaml
name: "server-tls-policy"
serverCertificate:
  certificateProviderInstance:
    pluginInstance: google_cloud_private_spiffe
EOF

  2. 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

  3. ClientTlsPolicy per mTLS funziona anche nel caso TLS, ma la sezione clientCertificate del criterio può essere eliminata poiché non è obbligatoria per TLS:

    cat << EOF > client-tls-policy.yaml
name: "client-tls-policy"
serverValidationCa:
- certificateProviderInstance:
    pluginInstance: google_cloud_private_spiffe
EOF

Utilizza la sicurezza del servizio con l'esempio di Wallet

Questa sezione fornisce una panoramica generale di 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 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 procedura è simile per Java. Le istruzioni utilizzano un'immagine Docker preesistente che puoi ottenere dal repository di container Google Cloud.

Per creare un esempio, segui queste istruzioni:

  1. Clona il repository e recupera i file negli esempi di gRPC della directory.
  2. Modifica il file 00-common-env.sh. Commenta la riga esistente che imposta il valore WALLET_DOCKER_IMAGE sull'immagine Go Docker e rimuovi il commento dalla riga che imposta il valore WALLET_DOCKER_IMAGE sull'immagine Java Docker.
  3. Crea e configura le istanze del router Cloud, seguendo le istruzioni in Creare e configurare le istanze del router Cloud oppure utilizzando la funzione create_cloud_router_instances nello script 10.apis.sh.
  4. Crea un cluster utilizzando le istruzioni per l'esempio hello world o la funzione create_cluster nello script 20-cluster.sh.
  5. Crea autorità di certificazione private utilizzando le istruzioni per il servizio CA o lo script 30-private-ca-setup.sh.
  6. Creare risorse Kubernetes, inclusi account di servizio, spazi dei nomi, servizi Kubernetes, NEG e deployment lato server per tutti i servizi: account, stats, stats_premium, wallet_v1, wallet_v2, utilizzando lo script 40-k8s-resources.sh.
  7. Per ciascuno dei servizi che hai creato, crea un servizio di controllo di integrità e di backend utilizzando create_health_check e create_backend_service nello script 50-td-components.sh.
  8. Crea i componenti di routing di Traffic Director utilizzando create_routing_components nello script 60-routing-components.sh.
  9. Crea i componenti di sicurezza di Traffic Director per ogni servizio di backend utilizzando create_security_components nello script 70-security-components.sh.
  10. Crea il deployment del client Wallet utilizzando create_client_deployment nello script 75-client-deployment.sh.
  11. Verifica la configurazione avviando il client come descritto in Verificare con i client 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 procedura è simile per C++. Le istruzioni utilizzano un'immagine Docker pre-esistente ottenuta dal repository container di Google Cloud.

Per creare un esempio, segui queste istruzioni:

  1. Clona il repository e recupera i file negli esempi di gRPC della directory.
  2. Modifica il file 00-common-env.sh. Commenta la riga esistente che imposta il valore WALLET_DOCKER_IMAGE sull'immagine Go Docker e rimuovi il commento della riga che imposta il valore WALLET_DOCKER_IMAGE sull'immagine Docker C++.
  3. Crea e configura le istanze del router Cloud, seguendo le istruzioni in Creare e configurare le istanze del router Cloud oppure utilizzando la funzione create_cloud_router_instances nello script 10.apis.sh.
  4. Crea un cluster utilizzando le istruzioni per l'esempio hello world o la funzione create_cluster nello script 20-cluster.sh.
  5. Crea autorità di certificazione private utilizzando le istruzioni per il servizio CA o lo script 30-private-ca-setup.sh.
  6. Creare risorse Kubernetes, inclusi account di servizio, spazi dei nomi, servizi Kubernetes, NEG e deployment lato server per tutti i servizi: account, stats, stats_premium, wallet_v1, wallet_v2, utilizzando lo script 40-k8s-resources.sh.
  7. Per ciascuno dei servizi che hai creato, crea un servizio di controllo di integrità e di backend utilizzando create_health_check e create_backend_service nello script 50-td-components.sh.
  8. Crea i componenti di routing di Traffic Director utilizzando create_routing_components nello script 60-routing-components.sh.
  9. Crea i componenti di sicurezza di Traffic Director per ogni servizio di backend utilizzando create_security_components nello script 70-security-components.sh.
  10. Crea il deployment del client Wallet utilizzando create_client_deployment nello script 75-client-deployment.sh.
  11. Verifica la configurazione avviando il client come descritto in Verificare con i client grpc-wallet.

Go

Puoi trovare il codice sorgente di esempio per Go all'indirizzo github. Il codice utilizza già le credenziali XdsChannel e XdsServer quando configuri la sicurezza senza proxy.

Le istruzioni utilizzano un'immagine Docker preesistente ottenuta dal repository del container Google Cloud.

Per creare un esempio, segui queste istruzioni:

  1. Clona il repository e recupera i file negli esempi di gRPC della directory.
  2. Modifica il file 00-common-env.sh per impostare i valori corretti per le variabili di ambiente.
  3. Crea e configura le istanze del router Cloud, seguendo le istruzioni in Creare e configurare le istanze del router Cloud oppure utilizzando la funzione create_cloud_router_instances nello script 10.apis.sh.
  4. Crea un cluster utilizzando le istruzioni per l'esempio hello world o la funzione create_cluster nello script 20-cluster.sh.
  5. Crea autorità di certificazione private utilizzando le istruzioni per il servizio CA o lo script 30-private-ca-setup.sh.
  6. Creare risorse Kubernetes, inclusi account di servizio, spazi dei nomi, servizi Kubernetes, NEG e deployment lato server per tutti i servizi: account, stats, stats_premium, wallet_v1, wallet_v2, utilizzando lo script 40-k8s-resources.sh.
  7. Per ciascuno dei servizi che hai creato, crea un servizio di controllo di integrità e di backend utilizzando create_health_check e create_backend_service nello script 50-td-components.sh.
  8. Crea i componenti di routing di Traffic Director utilizzando create_routing_components nello script 60-routing-components.sh.
  9. Crea i componenti di sicurezza di Traffic Director per ogni servizio di backend utilizzando create_security_components nello script 70-security-components.sh.
  10. Crea il deployment del client Wallet utilizzando create_client_deployment nello script 75-client-deployment.sh.
  11. Verifica la configurazione avviando il client come descritto in Verificare con i client grpc-wallet.

File bootstrap

Il processo di configurazione in questa guida utilizza un generatore di bootstrap per creare il file di bootstrap richiesto. Questa sezione fornisce informazioni di riferimento sul file bootstrap stesso.

Il file bootstrap contiene le informazioni di configurazione richieste dal codice gRPC proxyless, incluse le informazioni di connessione per il server xDS. Il file bootstrap contiene la configurazione di sicurezza richiesta dalla funzionalità di sicurezza gRPC proxyless. Il server gRPC richiede un campo aggiuntivo, come descritto di seguito. Un file di esempio di bootstrap ha il seguente aspetto:

{
  "xds_servers": [
    {
      "server_uri": "trafficdirector.googleapis.com:443",
      "channel_creds": [
        {
          "type": "google_default"
        }
      ],
      "server_features": [
        "xds_v3"
      ]
    }
  ],
  "node": {
    "cluster": "cluster",
    "id": "projects/9876012345/networks/default/nodes/client1",
    "metadata": {
      "TRAFFICDIRECTOR_GCP_PROJECT_NUMBER": "9876012345",
      "TRAFFICDIRECTOR_NETWORK_NAME": "default",
      "INSTANCE_IP": "10.0.0.3"
    },
    "locality": {
      "zone": "us-central1-a"
    }
  },
  "server_listener_resource_name_template": "grpc/server?xds.resource.listening_address=%s",
  "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"
      }
    }
  }
}

Aggiornamenti al file 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à univoca per il client gRPC per Traffic Director. Devi fornire il numero del progetto Google Cloud e il nome della rete utilizzando l'ID nodo nel seguente formato:

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

Ecco 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 oppure 0.0.0.0 per indicare INADDR_ANY. Questo campo viene utilizzato dal server gRPC per recuperare la risorsa listener da Traffic Director 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 Richiesto per i server gRPC. gRPC utilizza questo valore per scrivere il nome della risorsa per il recupero della risorsa " listener" da Traffic Director 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 dei nomi alle istanze del provider dei certificati. Un'istanza del provider di certificati viene utilizzata per recuperare i certificati di identità e radice. Il file bootstap di esempio contiene un nome: google_cloud_private_spiffe, con lo struct JSON dell'istanza del provider del certificato come valore. Lo struct JSON dell'istanza del provider di certificati ha due campi:
  • plugin_name. Valore obbligatorio che identifica il plug-in del fornitore del certificato affinché sia utilizzato come richiesto dall'architettura del plug-in gRPC per i provider di certificati. gRPC ha il supporto integrato per il plug-in File-watcher utilizzato in questa configurazione. Il 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 i seguenti:

  • certificate_file: stringa obbligatoria. Questo valore corrisponde alla posizione del certificato di identità.
  • private_key_file: stringa obbligatoria. Il valore corrisponde alla posizione del file della chiave privata, che deve corrispondere al certificato di identità.
  • ca_certificate_file: stringa obbligatoria. Il valore corrisponde alla posizione del certificato radice, noto anche come pacchetto di attendibilità.
  • refresh_interval: stringa facoltativa. Il valore indica l'intervallo di aggiornamento, specificato utilizzando la rappresentazione stringa della mappatura JSON di una durata. Il valore predefinito è "600s", una durata di 10 minuti.

Generatore di bootstrap

L'immagine container del generatore di bootstrap è disponibile all'indirizzo gcr.io/trafficdirector-prod/td-grpc-bootstrap:0.13.0. Il codice sorgente è disponibile all'indirizzo https://github.com/GoogleCloudPlatform/traffic-director-grpc-bootstrap. Le opzioni della riga di comando più utilizzate sono le seguenti:

  • --output: utilizza questa opzione per specificare dove è scritto il file bootstrap di output, ad esempio il comando --output /tmp/bootstrap/td-grpc-bootstrap.jsongenera il file bootstrap in /tmp/bootstrap/td-grpc-bootstrap.json nel file system del pod.
  • --node-metadata: utilizza questo flag per compilare i metadati del nodo nel file di bootstrap. Questo campo è obbligatorio quando utilizzi i matcher etichette dei metadati in EndpointPolicy in cui {td_name_short}} utilizza i dati delle etichette forniti nella sezione dei metadati del nodo del file di bootstrap. L'argomento viene fornito nel formato chiave=valore, ad esempio: --node-metadata version=prod --node-metadata type=grpc

L'esempio riportato sopra aggiunge quanto segue nella sezione dei metadati del nodo del file di bootstrap:

{
  "node": {
...
    "metadata": {
      "version": "prod",
      "type": "grpc",
...
    },
...
  },
...
}

Risolvere i problemi

Segui queste istruzioni per risolvere i problemi di deployment di sicurezza.

I carichi di lavoro non sono in grado di ottenere la configurazione da Traffic Director

Se viene visualizzato un errore simile a questo:

PERMISSION_DENIED: Request had insufficient authentication scopes.

Verifica quanto segue:

  • Hai creato il cluster GKE con l'argomento --scopes=cloud-platform argomento.
  • Hai assegnato roles/trafficdirector.client ai tuoi account di servizio Kuberneters.
  • Hai assegnato roles/trafficdirector.client al tuo account di servizio Google Cloud predefinito (${GSA_EMAIL} sopra).
  • Hai abilitato il servizio trafficdirector.googleapis.com (API).

Il tuo server gRPC non utilizza TLS/mTLS anche con la configurazione Traffic Director 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 del cluster richiesta

Il comando di creazione del cluster GKE potrebbe non riuscire con un errore simile al seguente:

Node version "1.20.5-gke.2000" is unsupported.

Assicurati di utilizzare l'argomento --release-channel rapid nel comando di creazione del cluster. Devi utilizzare il canale di rilascio rapido per ottenere la versione corretta per questa release.

Ricevi un errore No usable endpoint

Se un client non riesce a comunicare con il server a causa di un errore No usable endpoint, il controllo di integrità potrebbe aver contrassegnato i backend del server come non integri. Per controllare l'integrità dei backend, esegui questo comando gcloud:

gcloud compute backend-services get-health grpc-gke-helloworld-service --global

Se il comando restituisce uno stato di integrità non integro, potrebbe essere a causa di uno dei seguenti motivi:

  • Il firewall non è stato creato o non contiene l'intervallo IP di origine corretto.
  • I tag di destinazione sul firewall non corrispondono a quelli nel cluster creato.

I carichi di lavoro non riescono a comunicare nella configurazione di sicurezza

Se i tuoi carichi di lavoro non riescono a comunicare dopo aver configurato la sicurezza per il mesh di servizi senza proxy, segui queste istruzioni per determinare la causa.

  1. Disabilita la sicurezza senza proxy ed elimina i problemi nei casi d'uso di bilanciamento del carico della rete senza proxy. Per disabilitare la sicurezza nel mesh, esegui una delle seguenti operazioni:
    1. Utilizza credenziali in testo non crittografato sul lato client e server OPPURE
    2. Non configurare la sicurezza per il servizio di backend e il criterio dell'endpoint nella configurazione di Traffic Director.

Segui la procedura descritta in Risolvere i problemi di deployment di Traffic Director senza proxy, perché nel tuo deployment non è configurata alcuna sicurezza.

  1. Modifica i carichi di lavoro in modo da utilizzare le credenziali xDS con credenziali in testo non crittografato o non sicure come credenziali di riserva. Mantieni la configurazione di Traffic Director con la sicurezza disattivata come descritto in precedenza. In questo caso, anche se gRPC consente a Traffic Director di configurare la sicurezza, Traffic Director non invia informazioni di sicurezza; in questo caso gRPC deve utilizzare credenziali in testo non crittografato (o non sicuro) che dovrebbero funzionare in modo simile al primo caso sopra. Se questo caso non funziona, procedi nel seguente modo:

    1. Aumenta il livello di logging sia sul lato client sia su quello del server in modo da poter visualizzare i messaggi xDS scambiati tra gRPC e Traffic Director.
    2. Assicurati che Traffic Director non abbia abilitato la sicurezza nelle risposte CDS e LDS inviate ai carichi di lavoro.
    3. Assicurati che i carichi di lavoro non utilizzino le modalità TLS o mTLS nei propri canali. Se vengono visualizzati messaggi di log relativi agli handshake TLS, controlla il codice sorgente dell'applicazione e assicurati di utilizzare risorse non sicure o di testo non crittografato come credenziali di riserva. Se il codice sorgente dell'applicazione è corretto, potrebbe trattarsi di un bug nella libreria gRPC

  2. Verifica che l'integrazione del servizio CA con GKE funzioni correttamente per il tuo cluster GKE seguendo la procedura di risoluzione dei problemi di questa Guida dell'utente. Assicurati che i certificati e le chiavi forniti da tale funzionalità siano resi disponibili nella directory specificata /var/run/secrets/workload-spiffe-credentials/.

  3. Attiva TLS (anziché mTLS) nel tuo mesh, come descritto sopra, e riavvia i carichi di lavoro client e server.

    1. Aumenta il livello di logging sia sul lato client sia su quello del server per poter visualizzare i messaggi xDS scambiati tra gRPC e Traffic Director.
    2. Assicurati che Traffic Director abbia abilitato la sicurezza nelle risposte CDS e LDS inviate ai carichi di lavoro.

Il client non riesce con un CertificateException e un messaggio Peer certificate SAN check failed

Indica un problema con i valori subjectAltNames nel messaggio SecuritySettings. Tieni presente che questi valori si basano sui servizi Kubernetes che hai creato per il servizio di backend. A ogni servizio Kubernetes che hai creato, è presente un ID SPIFFE associato nel seguente formato:

spiffe://${WORKLOAD_POOL}/ns/${K8S_NAMESPACE}/sa/${SERVICE_ACCOUNT}

Questi valori sono:

  • WORKLOAD_POOL: il pool di carichi di lavoro del cluster, ovvero ${PROJECT_ID}.svc.id.goog
  • K8S_NAMESPACE: lo spazio dei nomi Kubernetes utilizzato nel deployment del servizio
  • SERVICE_ACCOUNT: l'account di servizio Kubernetes che hai utilizzato nel deployment del servizio

Per ogni servizio Kubernetes collegato al tuo 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 tua libreria gRPC

Se le tue applicazioni non possono utilizzare i certificati mTLS con la tua libreria gRPC, segui questi passaggi:

  1. Verifica che la specifica del pod contenga l'annotazione security.cloud.google.com/use-workload-certificates descritta in Creare un servizio gRPC proxyless con NEG.

  2. Verifica che i file contenenti la catena di certificati, il certificato foglia, la chiave privata e i certificati CA attendibili siano accessibili ai seguenti percorsi all'interno del pod:

    1. Catena di certificati insieme a certificato foglia: "/var/run/secrets/workload-spiffe-credentials/certificates.pem"
    2. Chiave privata: "/var/run/secrets/workload-spiffe-credentials/private_key.pem"
    3. Pacchetto CA: "/var/run/secrets/workload-spiffe-credentials/ca_certificates.pem"

  3. Se i certificati del passaggio precedente non sono disponibili, procedi nel seguente modo:

      gcloud privateca subordinates describe SUBORDINATE_CA_POOL_NAME 
    
    --location=LOCATION

    1. Verifica che il piano di controllo di GKE abbia l'associazione dei ruoli IAM corretta, concedendo 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.

    2. Verifica che il certificato non sia scaduto. Questa è la catena di certificati e il certificato foglia di /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"

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

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

    4. Verifica che la tua applicazione Java gRPC abbia il seguente keyAlgorithm nel file YAML WorkloadCertificateConfig:

      keyAlgorithm:
    rsa:
      modulusSize: 4096

  4. Verifica che la CA utilizzi la stessa famiglia di chiavi della chiave del certificato.

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

  1. Verifica che l'applicazione peer utilizzi lo stesso bundle di attendibilità per verificare il certificato.
  2. Verifica che il certificato in uso non sia scaduto (catena di certificati insieme al certificato foglia: "/var/run/secrets/workload-spiffe-credentials/certificates.pem").

###

Se i pod rimangono in attesa durante la procedura di configurazione, aumenta le risorse CPU e di memoria dei pod nella specifica del deployment.

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

Assicurati di eseguire l'ultima versione di gcloud CLI:

gcloud components update

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

I pod non si avviano

L'avvio dei pod che utilizzano i certificati mesh GKE potrebbe non riuscire se il provisioning del certificato non va a buon fine. Questo può accadere in situazioni come le seguenti:

  • WorkloadCertificateConfig o TrustConfig sono configurati in modo errato o mancanti.
  • I CSR non vengono approvati.

Puoi controllare se il provisioning del certificato ha esito negativo controllando gli eventi del pod.

  1. Controlla lo stato del pod:

    kubectl get pod -n POD_NAMESPACE POD_NAME

    Sostituisci quanto segue:

    • POD_NAMESPACE: lo spazio dei nomi del tuo pod.
    • POD_NAME: il nome del pod.

  2. Controlla gli eventi recenti per il tuo pod:

    kubectl describe pod -n POD_NAMESPACE POD_NAME

  3. Se il provisioning del certificato non va a buon fine, vedrai 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 del problema.

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

  4. Se il motivo per cui i pod non si avviano è dovuto a oggetti configurati in modo errato o a causa di CSR rifiutati, consulta la procedura di risoluzione dei problemi riportata di seguito.

WorkloadCertificateConfig o TrustConfig sono configurati in modo errato

Assicurati di aver creato correttamente gli oggetti WorkloadCertificateConfig e TrustConfig. Puoi diagnosticare gli errori di configurazione su entrambi gli oggetti utilizzando kubectl.

  1. Recupera lo stato attuale.

    Per WorkloadCertificateConfig:

    kubectl get WorkloadCertificateConfig default -o yaml

    Per TrustConfig:

    kubectl get TrustConfig default -o yaml

  2. Controlla l'output dello stato. Un oggetto valido avrà una condizione 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 campi reason e message contengono ulteriori dettagli per la risoluzione dei problemi.

CSR non 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.

  1. Elenca i CSR pertinenti utilizzando kubectl:

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

  2. Scegli un CSR che sia Approved e non Issued o non sia Approved.

  3. Ottieni i dettagli per il CSR selezionato utilizzando kubectl:

    kubectl get csr CSR_NAME -o yaml

    Sostituisci CSR_NAME con il nome del CSR che hai scelto.

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

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

Le informazioni per la risoluzione dei problemi relativi ai CSR non validi vengono visualizzate nei campi message e reason.

I pod non hanno un certificato

  1. Recupera le specifiche del pod per il pod:

    kubectl get pod -n POD_NAMESPACE POD_NAME -o yaml

    Sostituisci quanto segue:

    • POD_NAMESPACE: lo spazio dei nomi del tuo pod.
    • POD_NAME: il nome del pod.

  2. Verifica che la specifica del pod contenga l'annotazione security.cloud.google.com/use-workload-certificates descritta in Configurare i pod per ricevere le credenziali mTLS.

  3. Verifica che il controller di ammissione dei certificati 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
...

  4. 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
  ...

  5. Verifica che i seguenti pacchetti di certificati e la chiave privata siano disponibili nelle seguenti posizioni nel pod:

    • Cofanetto 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 trust CA attendibile: /var/run/secrets/workload-spiffe-credentials/ca_certificates.pem

  6. Se i file non sono disponibili, procedi nel seguente modo:

    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 dell'istanza del servizio CA (Anteprima):

      gcloud privateca ISSUING_CA_TYPE describe ISSUING_CA_NAME \
  --location ISSUING_CA_LOCATION

      Sostituisci quanto segue:

      • ISSUING_CA_TYPE: il tipo CA emittente, che deve essere subordinates o roots.
      • ISSUING_CA_NAME: il nome della CA emittente.
      • ISSUING_CA_LOCATION: l'area geografica della CA emittente.

    3. Ottieni il criterio IAM per la CA radice:

      gcloud privateca roots get-iam-policy ROOT_CA_NAME

      Sostituisci ROOT_CA_NAME con il nome della tua CA radice.

    4. Nel criterio IAM, verifica che l'associazione del criterio privateca.auditor esista:

      ...
- members:
  - serviceAccount:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com
  role: roles/privateca.auditor
...

      In questo esempio, PROJECT_NUMBER è il numero di progetto del cluster.

    5. Recupera il criterio IAM per la CA subordinata:

      gcloud privateca subordinates get-iam-policy SUBORDINATE_CA_NAME

      Sostituisci SUBORDINATE_CA_NAME con il nome del subordinato CA.

    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 di progetto del cluster.

Le applicazioni non possono utilizzare le credenziali mTLS emesse

  1. Verifica che il certificato non sia scaduto:

    cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -text -noout | grep "Not After"

  2. Verifica che il tipo di chiave utilizzato sia supportato dalla tua applicazione.

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

  3. Verifica che la CA emittente utilizzi la stessa famiglia di chiavi della chiave del certificato.

    1. Verifica lo stato dell'istanza del servizio CA (Anteprima):

      gcloud privateca ISSUING_CA_TYPE describe ISSUING_CA_NAME \
  --location ISSUING_CA_LOCATION

      Sostituisci quanto segue:

      • ISSUING_CA_TYPE: il tipo CA emittente, che deve essere subordinates o roots.
      • ISSUING_CA_NAME: il nome della CA emittente.
      • ISSUING_CA_LOCATION: l'area geografica della CA emittente.

    2. Verifica che keySpec.algorithm nell'output corrisponda allo stesso algoritmo della chiave definito nel manifest YAML WorkloadCertificateConfig. L'output ha il seguente aspetto:

      config:
  ...
  subjectConfig:
    commonName: td-sub-ca
    subject:
      organization: TestOrgLLC
    subjectAltName: {}
createTime: '2021-05-04T05:37:58.329293525Z'
issuingOptions:
  includeCaCertUrl: true
keySpec:
  algorithm: RSA_PKCS1_2048_SHA256
 ...

I certificati vengono rifiutati

  1. Verifica che l'applicazione peer utilizzi lo stesso bundle di attendibilità per verificare il certificato.

  2. Verifica che il certificato non sia scaduto:

    cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -text -noout | grep "Not After"

  3. Verifica che il codice client, se non utilizzi l'API Credentials Reload di gRPC, aggiorna periodicamente le credenziali dal file system.

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

Limitazioni

Traffic Director non supporta gli scenari in cui sono presenti due o più risorse dei criteri degli endpoint che corrispondono equamente a un endpoint, ad esempio due criteri con le stesse etichette e porte o due o più criteri con etichette diverse che corrispondono ugualmente alle etichette dell'endpoint. Per ulteriori informazioni su come i criteri degli endpoint vengono abbinati alle etichette di un endpoint, consulta le API per EndpointPolicy.EndpointMatcher.MetadataLabelMatcher. In questi casi, Traffic Director non genera una configurazione di sicurezza da nessuno dei criteri in conflitto.