Configura la sicurezza dei servizi con gRPC senza proxy

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

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 necessarie per utilizzare Google Kubernetes Engine. Devi disporre almeno dei seguenti ruoli:

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

Per creare le risorse richieste per la configurazione, devi disporre del ruolo compute.NetworkAdmin. Questo ruolo contiene tutte le autorizzazioni necessarie per creare, aggiornare, eliminare, elencare e utilizzare (ovvero, viene fatto riferimento in altre risorse) alle risorse richieste. Se sei l'editor proprietario del progetto, questo ruolo viene assegnato automaticamente.

Tieni presente che networksecurity.googleapis.com.clientTlsPolicies.use e networksecurity.googleapis.com.serverTlsPolicies.use non vengono applicati in modo forzato quando fai riferimento a queste risorse nella risorsa del servizio di backend.

Se verrà applicato in futuro e utilizzi il ruolo compute.NetworkAdmin, non rileverai alcun problema al momento dell'applicazione di questo controllo.

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

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 sui 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 abilita le funzionalità di bilanciamento del carico e di rilevamento degli endpoint del PSM.

Aggiorna i client e i server gRPC alla versione corretta

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

Aggiorna il file di bootstrap

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

Panoramica della configurazione

Questo processo di configurazione è un'estensione della configurazione di Cloud Service Mesh con GKE e i servizi gRPC senza proxy. I passaggi non modificati esistenti di questa procedura di configurazione vengono indicati ovunque si applichino.

Di seguito sono riportati i miglioramenti principali alla configurazione di Cloud Service Mesh con GKE:

  1. È in corso la configurazione del servizio CA, in cui vengono creati pool di CA privati e le autorità di certificazione richieste.
  2. Creazione di un cluster GKE con identità GKE Workload, funzionalità dei certificati mesh e integrazione del servizio CA.
  3. Configurazione dell'emissione dei certificati mesh sul cluster in corso.
  4. Creazione degli account di servizio client e server.
  5. È in corso la configurazione del server di esempio che utilizza le API xDS e le credenziali del server xDS per acquisire la configurazione di sicurezza da Cloud Service Mesh.
  6. È in corso la configurazione del client di esempio che utilizza le credenziali xDS.
  7. È in corso l'aggiornamento della configurazione di Cloud Service Mesh per includere la configurazione della sicurezza.

Puoi vedere 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, utilizzerai i comandi di Cloud Shell e la ripetizione delle informazioni nei comandi è rappresentata da varie variabili di ambiente. Imposta i tuoi 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=PROJECT_ID

# GKE cluster name and zone for this example.
CLUSTER_NAME=CLUSTER_NAME
ZONE=ZONE
gcloud config set compute/zone $ZONE

# GKE cluster URL derived from the above
GKE_CLUSTER_URL="https://container.googleapis.com/v1/projects/${PROJECT_ID}/locations/${ZONE}/clusters/${CLUSTER_NAME}"

# Workload pool to be used with the GKE cluster
WORKLOAD_POOL="${PROJECT_ID}.svc.id.goog"

# Kubernetes namespace to run client and server demo.
K8S_NAMESPACE='default'
DEMO_BACKEND_SERVICE_NAME='grpc-gke-helloworld-service'

# Compute other values
# Project number for your project
PROJNUM=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)")

# VERSION is the GKE cluster version. Install and use the most recent version
# from the rapid release channel and substitute its version for
# CLUSTER_VERSION, for example:
# VERSION=latest available version
# Note that the minimum required cluster version is 1.21.4-gke.1801.
VERSION="CLUSTER_VERSION"
SA_GKE=service-${PROJNUM}@container-engine-robot.iam.gserviceaccount.com

Abilita l'accesso alle API richieste

Questa sezione spiega come abilitare l'accesso alle API necessarie.

  1. Esegui questo comando per abilitare Cloud Service Mesh e altre API necessarie per la sicurezza del mesh di servizi gRPC senza proxy.

    gcloud services enable \
        container.googleapis.com \
        cloudresourcemanager.googleapis.com \
        compute.googleapis.com \
        trafficdirector.googleapis.com \
        networkservices.googleapis.com \
        networksecurity.googleapis.com \
        privateca.googleapis.com \
        gkehub.googleapis.com
    
  2. Esegui questo comando per consentire all'account di servizio predefinito di accedere all'API di sicurezza di Cloud Service Mesh.

    GSA_EMAIL=$(gcloud iam service-accounts list --format='value(email)' \
        --filter='displayName:Compute Engine default service account')
    
    gcloud projects add-iam-policy-binding ${PROJECT_ID} \
      --member serviceAccount:${GSA_EMAIL} \
       --role roles/trafficdirector.client
    

Crea o aggiorna un cluster GKE

La sicurezza del servizio Cloud Service Mesh dipende dall'integrazione del servizio CA con GKE. Il cluster GKE deve soddisfare i seguenti requisiti oltre a quelli per la configurazione:

  1. Crea un nuovo cluster che utilizza Workload Identity. Se stai aggiornando un cluster esistente, vai al passaggio successivo. Il valore specificato per --tags deve corrispondere al nome passato al flag --target-tags per il comando firewall-rules create nella sezione Configurazione di Cloud Service Mesh con i componenti di Cloud Load Balancing.

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

    La creazione del cluster potrebbe richiedere diversi minuti.

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

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

  1. Registra il tuo cluster nel parco risorse:

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

    Sostituisci le variabili in questo modo:

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

    Al termine del processo di registrazione, viene visualizzato un messaggio simile al seguente:

    Finished registering the cluster CLUSTER_NAME with the fleet.
  2. Applica al cluster il file manifest generato:

    kubectl apply -f MANIFEST-FILE_NAME
    

    Una volta completata la procedura di richiesta, vedrai dei messaggi come il seguente:

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

    kubectl get memberships membership -o yaml
    

    L'output dovrebbe includere il pool di identità Workoad assegnato dal parco risorse, dove PROJECT_ID è l'ID progetto:

    workload_identity_pool: PROJECT_ID.svc.id.goog
    

    Ciò significa che il cluster è stato registrato correttamente.

Crea autorità di certificazione per emettere certificati

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

  • CA radice. Si tratta della radice di attendibilità per tutti i certificati mesh emessi. Puoi utilizzare una CA radice esistente, se disponibile. Crea la CA radice nel livello enterprise, destinato all'emissione di certificati di lunga durata e con volumi ridotti.
  • CA subordinata. Questa CA emette certificati per i carichi di lavoro. Crea la CA subordinata nella regione in cui viene eseguito il deployment del cluster. Crea la CA subordinata nel livello devops, destinato all'emissione di certificati a volumi elevati di breve durata.

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 certificati mesh, assicurati che sia sempre consentita la modalità di emissione basata sulla configurazione predefinita.

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 le CA radice e subordinate in diverse regioni senza alcun impatto sulle prestazioni o sulla disponibilità.

Il servizio CA è supportato per le seguenti regioni:

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

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

gcloud privateca locations list
  1. Concedi roles/privateca.caManager IAM agli utenti che creano un pool di CA e una CA. Tieni presente che per MEMBER, il formato corretto è user:userid@example.com. Se questa persona è l'utente 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 CA Service agli utenti che devono modificare i criteri IAM, dove MEMBER è un utente che ha bisogno di questo accesso, in particolare a chiunque esegua i passaggi successivi 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 la configurazione di questa dimostrazione, utilizza i seguenti valori per le variabili:

    • ROOT_CA_POOL_NAME=td_sec_pool
    • ROOT_CA_NAME=pkcs2-ca
    • ROOT_CA_POOL_LOCATION=us-east1
    • ROOT_CA_ORGANIZATION="TestCorpLLC"
  5. Crea il pool subordinato e la CA subordinata. Assicurati che rimanga consentita la modalità di emissione basata sulla configurazione predefinita.

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

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

    • SUBORDINATE_CA_POOL_NAME="td-ca-pool"
    • SUBORDINATE_CA_POOL_LOCATION=us-east1
    • SUBORDINATE_CA_NAME="td-ca"
    • SUBORDINATE_CA_ORGANIZATION="TestCorpLLC"
    • ROOT_CA_POOL_NAME=td_sec_pool
    • ROOT_CA_POOL_LOCATION=us-east1
  6. Concedi il ruolo IAM privateca.auditor al 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 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 indicare al cluster come considerare attendibili i certificati emessi:

    apiVersion: security.cloud.google.com/v1
    kind: TrustConfig
    metadata:
      name: default
    spec:
      # You must include a trustStores entry for the trust domain that
      # your cluster is enrolled in.
      trustStores:
      - trustDomain: PROJECT_ID.svc.id.goog
        # Trust identities in this trustDomain if they appear in a certificate
        # that chains up to this root CA.
        trustAnchors:
        - certificateAuthorityServiceURI: ROOT_CA_POOL_URI
    

    Sostituisci quanto segue:

    • L'ID del progetto in cui viene eseguito il cluster:
      PROJECT_ID
    • L'URI completo del pool di CA principale (ROOT_CA_POOL_URI). Il formato è:
      //privateca.googleapis.com/projects/PROJECT_ID/locations/ROOT_CA_POOL_LOCATION/caPools/ROOT_CA_POOL_NAME
  10. Applica le configurazioni al cluster:

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

Crea un servizio gRPC senza proxy con NEG

Per la sicurezza PSM, è necessario un server gRPC senza proxy in grado di utilizzare xDS per acquisire la configurazione di sicurezza da Cloud Service Mesh. Questo passaggio è simile a Configurazione di servizi GKE con NEG nella guida alla configurazione del bilanciamento del carico PSM, ma utilizzerai il server helloworld abilitato per xDS nell'esempio di xDS nel repository grpc-java anziché nell'immagine java-example-hostname.

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

Di seguito è riportato un esempio completo della specifica Kubernetes del server gRPC. Tieni presente quanto segue:

  • La specifica crea un account di servizio Kubernetes example-grpc-server che viene utilizzato dal pod del server gRPC.
  • La specifica utilizza il campo name nell'annotazione cloud.google.com/neg del servizio per specificare il nome del NEG example-grpc-server.
  • La variabile ${PROJNUM} rappresenta il numero del progetto.
  • La specifica utilizza la sezione initContainers per eseguire un generatore di bootstrap al fine di compilare il file di bootstrap necessario alla libreria gRPC senza proxy. Questo file di bootstrap si trova in /tmp/grpc-xds/td-grpc-bootstrap.json nel container del server gRPC example-grpc-server.

Aggiungi la seguente annotazione alla specifica del pod:

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

Puoi vedere il posizionamento corretto nella specifica completa riportata di seguito.

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

  • private_key.pem è una chiave privata generata automaticamente.
  • certificates.pem è un bundle di certificati in formato PEM che possono essere presentati a un altro pod come catena di certificati client o utilizzati come catena di certificati server.
  • ca_certificates.pem è un bundle di certificati in formato PEM da utilizzare come ancoraggio di attendibilità durante la convalida della catena di certificati client presentata da un altro pod o della catena di certificati del server ricevuta durante la connessione a un altro pod.

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

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

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

In questa affermazione:

  • WORKLOAD_POOL è il nome del pool di carichi di lavoro del cluster.
  • NAMESPACE è lo spazio dei nomi del tuo account di servizio Kubernetes.
  • KUBERNETES_SERVICE_ACCOUNT è il nome del tuo 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.15.0
           imagePullPolicy: Always
           args:
           - --config-mesh-experimental
           - "grpc-mesh"
           - --output
           - "/tmp/bootstrap/td-grpc-bootstrap.json"
           - --node-metadata=app=helloworld
           resources:
             limits:
               cpu: 100m
               memory: 100Mi
             requests:
               cpu: 10m
               memory: 100Mi
           volumeMounts:
           - name: grpc-td-conf
             mountPath: /tmp/bootstrap/
         serviceAccountName: example-grpc-server
         volumes:
         - name: grpc-td-conf
           emptyDir:
             medium: Memory
    EOF
    

C++

  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.15.0
           imagePullPolicy: Always
           args:
           - --config-mesh-experimental
           - "grpc-mesh"
           - --output
           - "/tmp/bootstrap/td-grpc-bootstrap.json"
           - --node-metadata=app=helloworld
           resources:
             limits:
               cpu: 100m
               memory: 100Mi
             requests:
               cpu: 10m
               memory: 100Mi
           volumeMounts:
           - name: grpc-td-conf
             mountPath: /tmp/bootstrap/
         serviceAccountName: example-grpc-server
         volumes:
         - name: grpc-td-conf
           emptyDir:
             medium: Memory
    EOF
    

Python

  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.15.0
           imagePullPolicy: Always
           args:
           - --config-mesh-experimental
           - "grpc-mesh"
           - --output
           - "/tmp/bootstrap/td-grpc-bootstrap.json"
           - --node-metadata=app=helloworld
           resources:
             limits:
               cpu: 100m
               memory: 100Mi
             requests:
               cpu: 10m
               memory: 100Mi
           volumeMounts:
           - name: grpc-td-conf
             mountPath: /tmp/bootstrap/
         serviceAccountName: example-grpc-server
         volumes:
         - name: grpc-td-conf
           emptyDir:
             medium: Memory
    EOF
    

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.15.0
           imagePullPolicy: Always
           args:
           - --config-mesh-experimental
           - "grpc-mesh"
           - --output
           - "/tmp/bootstrap/td-grpc-bootstrap.json"
           - --node-metadata=app=helloworld
           resources:
             limits:
               cpu: 100m
               memory: 100Mi
             requests:
               cpu: 10m
               memory: 100Mi
           volumeMounts:
           - name: grpc-td-conf
             mountPath: /tmp/bootstrap/
         serviceAccountName: example-grpc-server
         volumes:
         - name: grpc-td-conf
           emptyDir:
             medium: Memory
    EOF
    

    Completa la procedura come descritto 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 del NEG sia corretto:

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

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

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

I passaggi in questa sezione sono simili a quelli descritti in Configurare Cloud Service Mesh con componenti di bilanciamento del carico, ma sono state apportate alcune modifiche, come descritto nelle sezioni seguenti.

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

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

Nel primo approccio, il server crea una porta di gestione aggiuntiva indicata come porta per il controllo di integrità. È collegato a uno speciale servizio di controllo di integrità, sotto forma di testo normale o TLS, sulla porta.

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

Nel secondo approccio, devi configurare il controllo di integrità per controllare solo la connettività TCP alla porta di gestione dell'applicazione. In questo modo viene controllata solo la connettività e viene generato traffico non necessario al server in caso di handshake TLS non riusciti. Per questo motivo, consigliamo di utilizzare il primo approccio.

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

    • Se stai creando una porta di servizio designata per il controllo di integrità, ovvero l'approccio che consigliamo, 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, cosa sconsigliato, 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 Creare o aggiornare un cluster GKE.

    gcloud compute firewall-rules create grpc-gke-allow-health-checks \
      --network default --action allow --direction INGRESS \
      --source-ranges 35.191.0.0/16,130.211.0.0/22 \
      --target-tags allow-health-checks \
      --rules tcp:50051-50052
    
  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 le risorse Mesh e GRPCRoute

Questo è simile a come configuri le risorse Mesh e GRPCRoute in Configurare i servizi gRPC senza proxy.

  1. Crea la specifica Mesh e salvala in un file denominato mesh.yaml.

    name: grpc-mesh
    
  2. Importa la risorsa Mesh dalla specifica.

    gcloud network-services meshes import grpc-mesh \
      --source=mesh.yaml \
      --location=global
    
  3. Crea la specifica GRPCRoute e salvala in un file denominato grpc_route.yaml.

    name: helloworld-grpc-route
    hostnames:
    - helloworld-gke:8000
    meshes:
    - projects/PROJECT_NUMBER/locations/global/meshes/grpc-mesh
    rules:
    - action:
        destinations:
        - serviceName: projects/PROJECT_NUMBER/locations/global/backendServices/grpc-gke-helloworld-service
    
  4. Importa la risorsa GRPCRoute dalla specifica grpc_route.yaml.

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

Configura Cloud Service Mesh con sicurezza gRPC senza proxy

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

Formato per i riferimenti alle norme

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

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

Ad esempio:

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

Configurare mTLS sul lato server

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

Il passo successivo è creare un criterio endpoint. Questo specifica che un backend, ad esempio un server gRPC, che utilizza la porta 50051 con qualsiasi etichetta di metadati o nessuna etichetta di metadati, riceve il criterio TLS del server collegato denominato server-mtls-policy. Puoi specificare le etichette dei metadati utilizzando MATCH_ALL o un valore supportato. Puoi trovare le etichette dei metadati supportate nel campo endpointMatcher.metadataLabelMatcher.metadataLabelMatchCriteria del documento NetworkServicesEndpointPolicy. Puoi creare il criterio dell'endpoint con un file temporaneo ep-mtls-psms.yaml che contiene i valori per la risorsa del criterio di endpoint utilizzando il criterio che hai 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 dell'endpoint creando il file temporaneo ep-mtls-psms.yaml:

    name: "ep-mtls-psms"
    type: "GRPC_SERVER"
    serverTlsPolicy: "projects/PROJECT_ID/locations/global/serverTlsPolicies/server-mtls-policy"
    trafficPortSelector:
      ports:
      - "50051"
    endpointMatcher:
      metadataLabelMatcher:
        metadataLabelMatchCriteria: "MATCH_ALL"
        metadataLabels:
        - labelName: app
          labelValue: helloworld
    
  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
    

Configurare 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) tramite il servizio di backend, il criterio di sicurezza lato client collegato 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 attuale:

    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 del client denominata client-mtls-policy importando il file temporaneo client-mtls-policy.yaml:

    gcloud network-security client-tls-policies import client-mtls-policy \
      --source=client-mtls-policy.yaml --location=global
    
  3. Crea uno snippet in un file temporaneo per fare riferimento a questo criterio e aggiungi 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 in precedenza. Tieni presente che example-grpc-server in subjectAltNames è il nome dell'account di servizio Kubernetes utilizzato per il pod del server gRPC nella specifica di deployment.

    if [ -z "$PROJECT_ID" ] ; then echo Please make sure PROJECT_ID is set. ; fi
    cat << EOF > client-security-settings.yaml
    securitySettings:
      clientTlsPolicy: projects/${PROJECT_ID}/locations/global/clientTlsPolicies/client-mtls-policy
      subjectAltNames:
        - "spiffe://${PROJECT_ID}.svc.id.goog/ns/default/sa/example-grpc-server"
    EOF
    
  4. Aggiungi il messaggio securitySettings al servizio di backend che hai già creato. Questi passaggi esportano i contenuti attuali del servizio di backend, aggiungi il messaggio del client securitySetting e reimporta 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 Cloud Service Mesh è stata completata, inclusa la sicurezza lato server e lato client. Successivamente, preparerai ed eseguirai i carichi di lavoro server e client. L'esempio termina qui.

Crea un client gRPC senza proxy

Questo passaggio è simile a quello precedente Creazione di un servizio gRPC senza proxy. Puoi utilizzare il client helloworld abilitato per xDS dalla directory di esempio di xDS nel repository grpc-java. Crea ed esegui il client in un container creato da un'immagine openjdk:8-jdk. La specifica Kubernetes del client gRPC fa quanto segue.

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

Aggiungi la seguente annotazione alla specifica del pod:

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

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

  • private_key.pem è una chiave privata generata automaticamente.
  • certificates.pem è un bundle di certificati in formato PEM che possono essere presentati a un altro pod come catena di certificati client o utilizzati come catena di certificati server.
  • ca_certificates.pem è un bundle di certificati in formato PEM da utilizzare come ancoraggio di attendibilità durante la convalida della catena di certificati client presentata da un altro pod o della catena di certificati del server ricevuta durante la connessione a un altro pod.

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

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

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

In questa affermazione:

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

Le seguenti istruzioni 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.15.0
            imagePullPolicy: Always
            args:
            - --config-mesh-experimental
            - "grpc-mesh"
            - --output
            - --config-mesh-experimental
            - "grpc-mesh"
            - "/tmp/bootstrap/td-grpc-bootstrap.json"
            resources:
              limits:
                cpu: 100m
                memory: 100Mi
              requests:
                cpu: 10m
                memory: 100Mi
            volumeMounts:
            - name: grpc-td-conf
              mountPath: /tmp/bootstrap/
          serviceAccountName: example-grpc-client
          volumes:
          - name: grpc-td-conf
            emptyDir:
              medium: Memory
    EOF
    

C++

  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.15.0
            imagePullPolicy: Always
            args:
            - --config-mesh-experimental
            - "grpc-mesh"
            - --output
            - "/tmp/bootstrap/td-grpc-bootstrap.json"
            resources:
              limits:
                cpu: 100m
                memory: 100Mi
              requests:
                cpu: 10m
                memory: 100Mi
            volumeMounts:
            - name: grpc-td-conf
              mountPath: /tmp/bootstrap/
          serviceAccountName: example-grpc-client
          volumes:
          - name: grpc-td-conf
            emptyDir:
              medium: Memory
    EOF
    

Python

  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.15.0
            imagePullPolicy: Always
            args:
            - --config-mesh-experimental
            - "grpc-mesh"
            - --output
            - "/tmp/bootstrap/td-grpc-bootstrap.json"
            resources:
              limits:
                cpu: 100m
                memory: 100Mi
              requests:
                cpu: 10m
                memory: 100Mi
            volumeMounts:
            - name: grpc-td-conf
              mountPath: /tmp/bootstrap/
          serviceAccountName: example-grpc-client
          volumes:
          - name: grpc-td-conf
            emptyDir:
              medium: Memory
    EOF
    

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.15.0
            imagePullPolicy: Always
            args:
            - --config-mesh-experimental
            - "grpc-mesh"
            - --output
            - "/tmp/bootstrap/td-grpc-bootstrap.json"
            resources:
              limits:
                cpu: 100m
                memory: 100Mi
              requests:
                cpu: 10m
                memory: 100Mi
            volumeMounts:
            - name: grpc-td-conf
              mountPath: /tmp/bootstrap/
          serviceAccountName: example-grpc-client
          volumes:
          - name: grpc-td-conf
            emptyDir:
              medium: Memory
    EOF
    

Completa la procedura come descritto di seguito.

  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 del client sia in esecuzione:

    kubectl get pods
    

    Il comando restituisce un testo simile al seguente:

    NAMESPACE   NAME                                    READY   STATUS    RESTARTS   AGE
    default     example-grpc-client-7c969bb997-9fzjv    1/1     Running   0          104s
    [..skip..]
    

Esegui il server

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

Java

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

    kubectl get pods | grep example-grpc-server
    

    Visualizzerai dei feedback come i seguenti:

    default    example-grpc-server-77548868d-l9hmf     1/1    Running   0     105s
    
  2. Apri una shell nel pod del server:

    kubectl exec -it example-grpc-server-77548868d-l9hmf -- /bin/bash
    
  3. Nella shell, verifica che il file di bootstrap all'indirizzo /tmp/grpc-xds/td-grpc-bootstrap.json corrisponda allo schema descritto nella sezione File di bootstrap.

  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 Cloud Service Mesh, viene visualizzato il seguente output:

    Listening on port 50051
    plain text health service listening on port 50052
    

C++

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

    kubectl get pods | grep example-grpc-server
    

    Visualizzerai dei feedback come i seguenti:

    default    example-grpc-server-77548868d-l9hmf     1/1    Running   0     105s
    
  2. Apri una shell nel pod del server:

    kubectl exec -it example-grpc-server-77548868d-l9hmf -- /bin/bash
    
  3. Nella shell, verifica che il file di bootstrap all'indirizzo /tmp/grpc-xds/td-grpc-bootstrap.json corrisponda allo schema descritto nella sezione File di bootstrap.

  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 Cloud Service Mesh, viene visualizzato il seguente output:

    Listening on port 50051
    plain text health service listening on port 50052
    

Python

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

    kubectl get pods | grep example-grpc-server
    

    Visualizzerai dei feedback come i seguenti:

    default    example-grpc-server-77548868d-l9hmf     1/1    Running   0     105s
    
  2. Apri una shell nel pod del server:

    kubectl exec -it example-grpc-server-77548868d-l9hmf -- /bin/bash
    
  3. Nella shell, verifica che il file di bootstrap all'indirizzo /tmp/grpc-xds/td-grpc-bootstrap.json corrisponda allo schema descritto nella sezione File di bootstrap.

  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 Cloud Service Mesh, viene visualizzato il seguente output:

    2021-05-06 16:10:34,042: INFO     Running with xDS Server credentials
    2021-05-06 16:10:34,043: INFO     Greeter server listening on port 50051
    2021-05-06 16:10:34,046: INFO     Maintenance server listening on port 50052
    

Go

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

    kubectl get pods | grep example-grpc-server
    

    Visualizzerai dei feedback come i seguenti:

    default    example-grpc-server-77548868d-l9hmf     1/1    Running   0     105s
    
  2. Apri una shell nel pod del server:

    kubectl exec -it example-grpc-server-77548868d-l9hmf -- /bin/sh
    
  3. Nella shell, verifica che il file di bootstrap all'indirizzo /tmp/grpc-xds/td-grpc-bootstrap.json corrisponda allo schema descritto nella sezione File di bootstrap.

  4. Scarica gRPC Go versione 1.41.0 e vai alla directory contenente l'applicazione server xds-hello-world.

    apk add curl
    
    curl -L https://github.com/grpc/grpc-go/archive/v1.42.0.tar.gz | tar -xz
    
    cd grpc-go-1.42.0/examples/features/xds/server
    
    
  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_LEVEL="info" \
      go run main.go \
      -xds_creds \
      -port 50051
    
  6. Dopo che il server ha ottenuto la configurazione necessaria da Cloud Service Mesh, viene visualizzato il seguente output:

    Using xDS credentials...
    Serving GreeterService on 0.0.0.0:50051 and HealthService on 0.0.0.0:50052
    

Il processo di controllo di integrità richiede da 3 a 5 minuti per 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. Ottieni il nome del pod del client:

    kubectl get pods | grep example-grpc-client
    

    I feedback ricevuti sono simili a questo:

    default    example-grpc-client-7c969bb997-9fzjv     1/1    Running   0     105s
    
  2. Apri una shell sul pod del client:

    kubectl exec -it example-grpc-client-7c969bb997-9fzjv -- /bin/bash
    
  3. Nella shell dei comandi, 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 del client e la stringa di connessione di destinazione:

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

    Dovresti vedere un output simile al seguente:

    Greeting: Hello xds-client, from xds-server
    

C++

  1. Ottieni il nome del pod del client:

    kubectl get pods | grep example-grpc-client
    

    I feedback ricevuti sono simili a questo:

    default    example-grpc-client-7c969bb997-9fzjv     1/1    Running   0     105s
    
  2. Apri una shell sul pod del client:

    kubectl exec -it example-grpc-client-7c969bb997-9fzjv -- /bin/bash
    
  3. Una volta all'interno della shell, scarica gRPC C++ e crea l'applicazione client xds-hello-world.

    apt-get update -y && \
            apt-get install -y \
                build-essential \
                clang \
                python3 \
                python3-dev
    
    curl -L https://github.com/grpc/grpc/archive/master.tar.gz | tar -xz
    
    cd grpc-master
    
    tools/bazel build examples/cpp/helloworld:xds_greeter_client
    
  4. Esegui il client con il flag --xds-creds per indicare la sicurezza abilitata per xDS, il nome del client e la stringa di connessione di destinazione:

    bazel-bin/examples/cpp/helloworld/xds_greeter_client --target=xds:///helloworld-gke:8000
    

    Per eseguire il client senza credenziali, utilizza quanto segue:

    bazel-bin/examples/cpp/helloworld/xds_greeter_client --target=xds:///helloworld-gke:8000 --nosecure
    

    Dovresti vedere un output simile al seguente:

    Greeter received: Hello world
    

Python

  1. Ottieni il nome del pod del client:

    kubectl get pods | grep example-grpc-client
    

    I feedback ricevuti sono simili a questo:

    default    example-grpc-client-7c969bb997-9fzjv     1/1    Running   0     105s
    
  2. Apri una shell sul pod del client:

    kubectl exec -it example-grpc-client-7c969bb997-9fzjv -- /bin/bash
    
  3. Una volta all'interno della 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 del 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. Ottieni il nome del pod del client:

    kubectl get pods | grep example-grpc-client
    

    I feedback ricevuti sono simili a questo:

    default    example-grpc-client-7c969bb997-9fzjv     1/1    Running   0     105s
    
  2. Apri una shell sul pod del client:

    kubectl exec -it example-grpc-client-7c969bb997-9fzjv -- /bin/sh
    
  3. Una volta all'interno della shell, scarica gRPC Go versione 1.42.0 e accedi 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 del client e la stringa di connessione di destinazione:

    GRPC_GO_LOG_VERBOSITY_LEVEL=2 GRPC_GO_LOG_SEVERITY_LEVEL="info" \
      go run main.go \
      -xds_creds \
      -name xds-client \
      -target xds:///helloworld-gke:8000
    

    Dovresti vedere un output simile al seguente:

    Greeting: Hello xds-client, from example-grpc-server-77548868d-l9hmf
    

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

Per il supporto dei criteri di autorizzazione è richiesto il supporto gRFC A41. Puoi trovare le versioni linguistiche richieste su github

Utilizza queste istruzioni per configurare l'accesso a livello di servizio con i criteri di autorizzazione. Prima di creare criteri di autorizzazione, leggi l'avviso in Limitare l'accesso utilizzando l'autorizzazione.

Per semplificare la verifica della configurazione, crea un nome host aggiuntivo che il client possa utilizzare per fare riferimento al servizio helloworld-gke.

  1. Aggiorna la specifica GRPCRoute precedentemente memorizzata in grpc_route.yaml

    name: helloworld-grpc-route
    hostnames:
    - helloworld-gke:8000
    - helloworld-gke-noaccess:8000
    meshes:
    - projects/PROJECT_NUMBER/locations/global/meshes/grpc-mesh
    rules:
    - action:
        destinations:
        - serviceName: projects/PROJECT_NUMBER/locations/global/backendServices/grpc-gke-helloworld-service
    
  2. Importa di nuovo la risorsa GRPCRoute dalla specifica grpc_route.yaml.

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

Le 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 dell'endpoint ora specifica che sia mTLS sia il criterio di autorizzazione devono essere applicati in modo forzato alle richieste in entrata ai 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

Utilizza queste istruzioni per confermare che il criterio di autorizzazione funzioni correttamente.

Java

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

    kubectl exec -it example-grpc-client-7c969bb997-9fzjv -- /bin/bash
    
  2. Nella shell dei comandi, esegui questi comandi per convalidare la configurazione.

    cd grpc-java-1.42.1/examples/example-xds
    ./build/install/example-xds/bin/xds-hello-world-client --xds-creds xds-client \
          xds:///helloworld-gke:8000
    

    Dovresti 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. Tieni presente che si tratta di un caso di errore. La richiesta non è valida perché il criterio di autorizzazione consente l'accesso solo al nome host helloworld-gke:8000.

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

    Dovresti vedere un output simile al seguente:

    WARNING: RPC failed: Status{code=PERMISSION_DENIED}
    

    Se non vedi questo output, è possibile che il criterio di autorizzazione non sia ancora in uso. Attendi qualche minuto e riprova a eseguire l'intera procedura di verifica.

Go

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

    kubectl exec -it example-grpc-client-7c969bb997-9fzjv -- /bin/bash
    
  2. Nella shell dei comandi, esegui questi comandi per convalidare la configurazione.

    cd grpc-go-1.42.0/examples/features/xds/client
    GRPC_GO_LOG_VERBOSITY_LEVEL=2 GRPC_GO_LOG_SEVERITY_LEVEL="info" \
      go run main.go \
      -xds_creds \
      -name xds-client \
      -target xds:///helloworld-gke:8000
    

    Dovresti 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. Tieni presente che si tratta di un caso di errore. La richiesta non è valida perché il criterio di autorizzazione consente l'accesso solo al nome host helloworld-gke:8000.

    GRPC_GO_LOG_VERBOSITY_LEVEL=2 GRPC_GO_LOG_SEVERITY_LEVEL="info" \
      go run main.go \
      -xds_creds \
      -name xds-client \
      -target xds:///helloworld-gke-noaccess:8000
    

    Dovresti vedere un output simile al seguente:

    could not greet: rpc error: code = PermissionDenied desc = Incoming RPC is not allowed: rpc error: code = PermissionDenied desc = incoming RPC did not match an allow policy
    exit status 1
    

    Se non vedi questo output, è possibile che il criterio di autorizzazione non sia ancora in uso. Attendi qualche minuto e riprova a eseguire l'intera procedura di verifica.

Utilizza TLS anziché mTLS

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

  1. In ServerTlsPolicy, inserisci mtlsPolicy:

    cat << EOF > server-tls-policy.yaml
    name: "server-tls-policy"
    serverCertificate:
      certificateProviderInstance:
        pluginInstance: google_cloud_private_spiffe
    EOF
    
  2. Utilizza 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 è richiesta per TLS:

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

Utilizzare la sicurezza del servizio con l'esempio di Wallet

Questa sezione fornisce una panoramica generale di come abilitare l'esempio di Wallet con la sicurezza dei servizi, per Java, C++ e Go.

Java

Puoi trovare il codice sorgente di esempio per Java su github. Il codice utilizza già le credenziali XdsChannel e XdsServer quando 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 recuperata dal repository di container di Google Cloud.

Per creare l'esempio, segui queste istruzioni:

  1. Clona il repository e recupera i file nella directory esempi di gRPC.
  2. Modifica il file 00-common-env.sh. Commenta la riga esistente che imposta il valore di WALLET_DOCKER_IMAGE sull'immagine Docker Go e rimuovi il commento dalla riga che imposta il valore di WALLET_DOCKER_IMAGE sull'immagine Docker di Java.
  3. Crea e configura le istanze del router Cloud utilizzando le istruzioni in Creare e configurare le istanze del router Cloud o 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 CA Service o utilizzando 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 controllo di integrità e un servizio di backend utilizzando create_health_check e create_backend_service nello script 50-td-components.sh.
  8. Crea i componenti di routing di Cloud Service Mesh utilizzando create_routing_components nello script 60-routing-components.sh.
  9. Crea i componenti di sicurezza di Cloud Service Mesh per ciascun 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 Verifica con i client grpc-wallet.

C++

Puoi trovare il codice sorgente di esempio per C++ in github. Il codice utilizza già le credenziali di XdsChannel e XdsServer quando configuri la sicurezza senza proxy.

Queste istruzioni descrivono la configurazione dell'esempio di Wallet con Go. Il processo è simile per C++. Le istruzioni utilizzano un'immagine Docker preesistente ottenuta dal repository di container Google Cloud.

Per creare l'esempio, segui queste istruzioni:

  1. Clona il repository e recupera i file nella directory esempi di gRPC.
  2. Modifica il file 00-common-env.sh. Commenta la riga esistente che imposta il valore di WALLET_DOCKER_IMAGE sull'immagine Docker Go e rimuovi il commento dalla riga che imposta il valore di WALLET_DOCKER_IMAGE sull'immagine Docker C++.
  3. Crea e configura le istanze del router Cloud utilizzando le istruzioni in Creare e configurare le istanze del router Cloud o 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 CA Service o utilizzando 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 controllo di integrità e un servizio di backend utilizzando create_health_check e create_backend_service nello script 50-td-components.sh.
  8. Crea i componenti di routing di Cloud Service Mesh utilizzando create_routing_components nello script 60-routing-components.sh.
  9. Crea i componenti di sicurezza di Cloud Service Mesh per ciascun 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 Verifica con i client grpc-wallet.

Go

Puoi trovare un codice sorgente di esempio per Go su github. Il codice utilizza già le credenziali XdsChannel eXdsServer quando configuri la sicurezza senza proxy.

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

Per creare l'esempio, segui queste istruzioni:

  1. Clona il repository e recupera i file nella directory esempi di gRPC.
  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 utilizzando le istruzioni in Creare e configurare le istanze del router Cloud o 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 CA Service o utilizzando 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 controllo di integrità e un servizio di backend utilizzando create_health_check e create_backend_service nello script 50-td-components.sh.
  8. Crea i componenti di routing di Cloud Service Mesh utilizzando create_routing_components nello script 60-routing-components.sh.
  9. Crea i componenti di sicurezza di Cloud Service Mesh per ciascun 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 Verifica con i client grpc-wallet.

File di 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 di bootstrap stesso.

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

{
  "xds_servers": [
    {
      "server_uri": "trafficdirector.googleapis.com:443",
      "channel_creds": [
        {
          "type": "google_default"
        }
      ],
      "server_features": [
        "xds_v3"
      ]
    }
  ],
  "authorities": {
    "traffic-director-c2p.xds.googleapis.com": {
      "xds_servers": [
        {
          "server_uri": "dns:///directpath-pa.googleapis.com",
          "channel_creds": [
            {
              "type": "google_default"
            }
          ],
          "server_features": [
            "xds_v3",
            "ignore_resource_deletion"
          ]
        }
      ],
      "client_listener_resource_name_template": "xdstp://traffic-director-c2p.xds.googleapis.com/envoy.config.listener.v3.Listener/%s"
    }
  },
  "node": {
    "id": "projects/9876012345/networks/mesh:grpc-mesh/nodes/b59f49cc-d95a-4462-9126-112f794d5dd3",
    "cluster": "cluster",
    "metadata": {
      "INSTANCE_IP": "10.28.2.8",
      "TRAFFICDIRECTOR_DIRECTPATH_C2P_IPV6_CAPABLE": true,
      "TRAFFICDIRECTOR_GCP_PROJECT_NUMBER": "223606568246",
      "TRAFFICDIRECTOR_NETWORK_NAME": "default",
      "app": "helloworld"
    },
    "locality": {
      "zone": "us-central1-c"
    }
  },
  "certificate_providers": {
    "google_cloud_private_spiffe": {
      "plugin_name": "file_watcher",
      "config": {
        "certificate_file": "/var/run/secrets/workload-spiffe-credentials/certificates.pem",
        "private_key_file": "/var/run/secrets/workload-spiffe-credentials/private_key.pem",
        "ca_certificate_file": "/var/run/secrets/workload-spiffe-credentials/ca_certificates.pem",
        "refresh_interval": "600s"
      }
    }
  },
  "server_listener_resource_name_template": "grpc/server?xds.resource.listening_address=%s"
}

Aggiornamenti al file di bootstrap per il servizio di sicurezza

I seguenti campi riflettono le modifiche relative alla sicurezza e all'utilizzo di xDS v3:

Il campo id all'interno di node fornisce un'identità univoca per il client gRPC a Cloud Service Mesh. Devi fornire il numero di progetto Google Cloud e il nome della rete utilizzando l'ID nodo nel seguente formato:

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

Un esempio per il progetto numero 1234 e la rete predefinita è:

projects/1234/networks/default/nodes/client1

Il campo INSTANCE_IP è l'indirizzo IP del pod o 0.0.0.0 per indicare INADDR_ANY. Questo campo viene utilizzato dal server gRPC per recuperare la risorsa Listener da Cloud Service Mesh per la sicurezza lato server.

Campi di configurazione della sicurezza nel file di bootstrap

Chiave JSON Tipo Valore Note
server_listener_resource_name_template String grpc/server?xds.resource.listening_address=%s Obbligatorio per i server gRPC. gRPC utilizza questo valore per comporre il nome della risorsa al fine di recuperare la risorsa "Listener" da Cloud Service Mesh per la sicurezza lato server e altre configurazioni. gRPC lo utilizza per formare la stringa del nome della risorsa
certificate_providers struct JSON google_cloud_private_spiffe Obbligatorio. Il valore è uno struct JSON che rappresenta una mappa di nomi per le istanze dei provider di certificati. Viene utilizzata un'istanza del provider di certificati per recuperare i certificati radice e dell'identità. L'esempio di file di bootstap contiene un nome: google_cloud_private_spiffe, con lo struct JSON dell'istanza del provider di certificati come valore. Ogni struct JSON dell'istanza del provider di certificati ha due campi:
  • plugin_name. Valore obbligatorio che identifica il plug-in del provider di certificati da utilizzare come richiesto dall'architettura dei plug-in di gRPC per i fornitori di certificati. gRPC ha il supporto integrato per il plug-in File-Watcher usato in questa configurazione. Il plugin plugin_name file_watcher.
  • config. Valore obbligatorio che identifica il blog di configurazione JSON per il plug-in file_watcher. Lo schema e i contenuti dipendono dal plug-in.

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

  • certificate_file: stringa obbligatoria. Questo valore è la località del certificato di identità.
  • private_key_file: stringa obbligatoria. Il valore è la posizione del file della chiave privata, che deve corrispondere al certificato di identità.
  • ca_certificate_file: stringa obbligatoria. Il valore è la posizione del certificato radice, chiamato anche bundle di attendibilità.
  • refresh_interval: stringa facoltativa. Il valore indica l'intervallo di aggiornamento, specificato con la rappresentazione stringa del mapping JSON di Duration. Il valore predefinito è "600s", con una durata di 10 minuti.

Generatore di bootstrap

L'immagine del container del generatore di bootstrap è disponibile all'indirizzo gcr.io/trafficdirector-prod/td-grpc-bootstrap:0.15.0. Il suo 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 viene scritto il file di bootstrap di output. Ad esempio, il comando --output /tmp/bootstrap/td-grpc-bootstrap.json genera il file di bootstrap in /tmp/bootstrap/td-grpc-bootstrap.json nel file system del pod.
  • --config-mesh-experimental: utilizza questa opzione per specificare il nome del mesh, corrispondente alla risorsa Mesh.
  • --node-metadata: utilizza questo flag per completare i metadati del nodo nel file di bootstrap. Questa operazione è necessaria quando utilizzi i matcher delle etichette dei metadati in EndpointPolicy in cui Cloud Service Mesh utilizza i dati delle etichette forniti nella sezione dei metadati dei nodi del file di bootstrap. L'argomento viene fornito nel formato chiave=valore, ad esempio: --node-metadata version=prod --node-metadata type=grpc

Le informazioni precedenti aggiungono quanto segue nella sezione dei metadati dei nodi del file di bootstrap:

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

Elimina il deployment

Facoltativamente, puoi eseguire questi comandi per eliminare il deployment che hai creato utilizzando questa guida.

Per eliminare il cluster, esegui questo comando:

gcloud container clusters delete CLUSTER_NAME --zone ZONE --quiet

Per eliminare le risorse che hai creato, esegui questi comandi:

gcloud compute backend-services delete grpc-gke-helloworld-service --global --quiet
gcloud compute network-endpoint-groups delete example-grpc-server --zone ZONE --quiet
gcloud compute firewall-rules delete grpc-gke-allow-health-checks --quiet
gcloud compute health-checks delete grpc-gke-helloworld-hc --quiet
gcloud network-services endpoint-policies delete ep-mtls-psms \
    --location=global --quiet
gcloud network-security authorization-policies delete helloworld-gke-authz-policy \
   --location=global --quiet
gcloud network-security client-tls-policies delete client-mtls-policy \
    --location=global --quiet
gcloud network-security server-tls-policies delete server-tls-policy \
    --location=global --quiet
gcloud network-security server-tls-policies delete server-mtls-policy \
    --location=global --quiet

Risoluzione dei problemi

Utilizza queste istruzioni per risolvere i problemi del deployment di sicurezza.

I carichi di lavoro non sono in grado di ottenere la configurazione da Cloud Service Mesh

Se viene visualizzato un errore simile a questo:

PERMISSION_DENIED: Request had insufficient authentication scopes.

Verifica quanto segue:

  • Hai creato il tuo cluster GKE con l'argomento --scopes=cloud-platform.
  • 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 (API) trafficdirector.googleapis.com.

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

Assicurati di specificare GRPC_SERVER nella configurazione dei criteri degli endpoint. Se hai specificato SIDECAR_PROXY, gRPC ignora la configurazione.

Non puoi creare il cluster GKE con la versione cluster richiesta

Il comando di creazione del cluster GKE potrebbe non riuscire e restituire un errore 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.

Viene visualizzato un errore di tipo 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 integro. Per verificare l'integrità dei backend, esegui questo comando gcloud:

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

Se il comando restituisce lo stato del backend non integro, la causa potrebbe essere uno dei seguenti:

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

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

Se i carichi di lavoro non sono in grado di 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 del bilanciamento del carico della rete mesh di servizi senza proxy. Per disabilitare la sicurezza nel mesh, esegui una delle seguenti operazioni:
    1. Utilizza credenziali in testo normale sul lato client e server OPPURE
    2. non devi configurare la sicurezza per il servizio di backend e il criterio degli endpoint nella configurazione di Cloud Service Mesh.

Segui i passaggi descritti in Risoluzione dei problemi di deployment di Cloud Service Mesh senza proxy, poiché non è prevista alcuna configurazione di sicurezza nel deployment.

  1. Modifica i tuoi carichi di lavoro in modo da utilizzare le credenziali xDS con testo normale o credenziali non sicure come credenziali di riserva. Mantieni disabilitata la configurazione di Cloud Service Mesh con la sicurezza come discusso in precedenza. In questo caso, anche se gRPC consente a Cloud Service Mesh di configurare la sicurezza, Cloud Service Mesh non invia informazioni di sicurezza. In questo caso, gRPC deve ricorrere a credenziali di testo normale (o non sicure), che dovrebbero funzionare in modo simile al primo caso precedente. Se questo caso non funziona, procedi nel seguente modo:

    1. Aumenta il livello di logging sia sul lato client sia sul lato server in modo da poter vedere i messaggi xDS scambiati tra gRPC e Cloud Service Mesh.
    2. Assicurati che Cloud Service Mesh non abbia la sicurezza abilitata 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 loro canali. Se visualizzi messaggi di log relativi agli handshake TLS, controlla il codice sorgente dell'applicazione e assicurati di utilizzare testo non sicuro o normale come credenziali di fallback. Se il codice sorgente dell'applicazione è corretto, potrebbe esserci 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 nella guida dell'utente. Assicurati che i certificati e le chiavi forniti da questa funzionalità siano resi disponibili nella directory specificata, /var/run/secrets/workload-spiffe-credentials/.

  3. Abilita TLS (invece di mTLS) nel tuo mesh, come descritto in precedenza, e riavvia i carichi di lavoro client e server.

    1. Aumentare il livello di logging sia sul lato client che sul lato server per poter vedere i messaggi xDS scambiati tra gRPC e Cloud Service Mesh.
    2. Assicurati che Cloud Service Mesh abbia abilitato la sicurezza nelle risposte CDS e LDS inviate ai carichi di lavoro.

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

Questo 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 tuo servizio di backend. A ogni servizio Kubernetes creato c'è un ID SPIFFE associato, in questo formato:

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

Questi valori sono:

  • WORKLOAD_POOL: il pool di carichi di lavoro per il cluster, che è ${PROJECT_ID}.svc.id.goog
  • K8S_NAMESPACE: lo spazio dei nomi Kubernetes utilizzato per il deployment del servizio
  • SERVICE_ACCOUNT: l'account di servizio Kubernetes che hai utilizzato per il 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 del messaggio SecuritySettings.

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

Se le tue applicazioni non sono in grado di utilizzare i certificati mTLS con la libreria gRPC, procedi nel seguente modo:

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

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

    1. Catena di certificati insieme al certificato foglia: "/var/run/secrets/workload-spiffe-credentials/certificates.pem"
    2. Chiave privata: "/var/run/secrets/workload-spiffe-credentials/private_key.pem"
    3. Bundle CA: "/var/run/secrets/workload-spiffe-credentials/ca_certificates.pem"
  3. Se i certificati indicati nel passaggio precedente non sono disponibili:

      gcloud privateca subordinates describe SUBORDINATE_CA_POOL_NAME 
    --location=LOCATION

    1. Verifica che il piano di controllo di GKE disponga dell'associazione del ruolo IAM corretta, concedendogli 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 all'indirizzo /var/run/secrets/workload-spiffe-credentials/certificates.pem. Per verificarlo, esegui questo comando:

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

    3. Verifica che il tipo di chiave sia supportato dalla tua applicazione eseguendo questo comando:

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

    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 viene 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").

I pod rimangono in stato di attesa

Se i pod rimangono in stato di attesa durante il processo di configurazione, aumenta le risorse di CPU e memoria per i pod nella specifica del deployment.

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

Assicurati di eseguire l'ultima versione di gcloud CLI:

gcloud components update

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

I pod non si avviano

I pod che utilizzano i certificati mesh GKE potrebbero non avviarsi se il provisioning dei certificati non va a buon fine. Ciò può verificarsi in situazioni come le seguenti:

  • WorkloadCertificateConfig o TrustConfig non sono configurati correttamente o mancano.
  • I CSR non vengono approvati.

Puoi verificare se il provisioning dei certificati non è andato a buon fine 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 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 riesce, visualizzerai un evento con Type=Warning, Reason=FailedMount, From=kubelet e un campo Message che inizia con MountVolume.SetUp failed for volume "gke-workload-certificates". Il campo Message contiene informazioni per la risoluzione dei problemi.

    Events:
      Type     Reason       Age                From       Message
      ----     ------       ----               ----       -------
      Warning  FailedMount  13s (x7 over 46s)  kubelet    MountVolume.SetUp failed for volume "gke-workload-certificates" : rpc error: code = Internal desc = unable to mount volume: store.CreateVolume, err: unable to create volume "csi-4d540ed59ef937fbb41a9bf5380a5a534edb3eedf037fe64be36bab0abf45c9c": caPEM is nil (check active WorkloadCertificateConfig)
    
  4. Consulta i seguenti passaggi per la risoluzione dei problemi se il motivo per cui i pod non vengono avviati è a causa di oggetti configurati in modo errato o di CSR rifiutati.

La configurazione di WorkloadCertificateConfig o TrustConfig non è corretta

Assicurati di aver creato correttamente gli oggetti WorkloadCertificateConfig e TrustConfig. Puoi diagnosticare gli errori di configurazione in uno di questi 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 sulla risoluzione dei problemi.

I CSR non sono approvati

Se si verificano problemi durante il processo di approvazione del CSR, puoi controllare i dettagli dell'errore nelle condizioni type: Approved e type: Issued della 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 oppure non sia Approved.

  3. Ottieni i dettagli della CSR selezionata con kubectl:

    kubectl get csr CSR_NAME -o yaml
    

    Sostituisci CSR_NAME con il nome del CSR che hai scelto.

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

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

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

Nei pod mancano dei certificati

  1. Ottieni le specifiche del pod per il tuo pod:

    kubectl get pod -n POD_NAMESPACE POD_NAME -o yaml
    

    Sostituisci quanto segue:

    • POD_NAMESPACE: lo spazio dei nomi del pod.
    • POD_NAME: il nome del pod.
  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 località nel pod:

    • Bundle della catena di certificati: /var/run/secrets/workload-spiffe-credentials/certificates.pem
    • Chiave privata: /var/run/secrets/workload-spiffe-credentials/private_key.pem
    • Bundle di ancoraggio CA attendibile: /var/run/secrets/workload-spiffe-credentials/ca_certificates.pem
  6. Se i file non sono disponibili, segui questi passaggi:

    1. Recupera l'istanza del servizio CA (anteprima) per il cluster:

      kubectl get workloadcertificateconfigs default -o jsonpath '{.spec.certificateAuthorityConfig.certificateAuthorityServiceConfig.endpointURI}'
      
    2. Recupera lo stato dell'istanza di CA Service (anteprima):

      gcloud privateca ISSUING_CA_TYPE describe ISSUING_CA_NAME \
        --location ISSUING_CA_LOCATION
      

      Sostituisci quanto segue:

      • ISSUING_CA_TYPE: il tipo di CA emittente, che deve essere subordinates o roots.
      • ISSUING_CA_NAME: il nome della CA emittente.
      • ISSUING_CA_LOCATION: la regione della CA emittente.
    3. Ottieni il criterio IAM per la CA principale:

      gcloud privateca roots get-iam-policy ROOT_CA_NAME
      

      Sostituisci ROOT_CA_NAME con il nome della CA principale.

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

      ...
      - 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. Ottieni il criterio IAM per la CA subordinata:

      gcloud privateca subordinates get-iam-policy SUBORDINATE_CA_NAME
      

      Sostituisci SUBORDINATE_CA_NAME con il nome della CA subordinata.

    6. Nel criterio IAM, verifica che esista l'associazione dei criteri privateca.certificateManager:

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

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

Le applicazioni non possono utilizzare le credenziali mTLS emesse

  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. Visualizza lo stato dell'istanza del servizio CA (anteprima):

      gcloud privateca ISSUING_CA_TYPE describe ISSUING_CA_NAME \
        --location ISSUING_CA_LOCATION
      

      Sostituisci quanto segue:

      • ISSUING_CA_TYPE: il tipo di CA emittente, che deve essere subordinates o roots.
      • ISSUING_CA_NAME: il nome della CA emittente.
      • ISSUING_CA_LOCATION: la regione della CA emittente.
    2. Verifica che keySpec.algorithm nell'output sia lo stesso algoritmo chiave che hai definito nel manifest YAML di WorkloadCertificateConfig. L'output avrà il seguente aspetto:

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

I certificati vengono rifiutati

  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 di ricaricamento credenziali gRPC Go, aggiorni periodicamente le credenziali dal file system.

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

Limitazioni

La sicurezza del servizio Cloud Service Mesh è supportata solo con GKE. Non puoi eseguire il deployment della sicurezza dei servizi con Compute Engine.

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