Automatizza la gestione dei certificati TLS per il gateway in entrata di Anthos Service Mesh utilizzando Certificate Authority Service

Questo tutorial mostra agli operatori di piattaforma come utilizzare l'emittente di Certificate Authority Service per lo strumento cert-manager al fine di automatizzare la gestione dei certificati TLS per il gateway in entrata di Anthos Service Mesh. I certificati consentono al gateway in entrata di terminare il traffico HTTPS e altro traffico TLS e mTLS proveniente dai client nel tuo VPC (Virtual Private Cloud), ma al di fuori del mesh di servizi. Il tutorial presuppone una conoscenza di base di Kubernetes e dei certificati TLS.

Introduzione

Anthos Service Mesh esegue il provisioning dei certificati TLS per ogni carico di lavoro nel mesh di servizi. Questi certificati consentono la comunicazione criptata e mTLS (mTLS) con autenticazione reciproca tra i carichi di lavoro nel mesh di servizi. Una delle CA supportate emette e firma i certificati.

Tuttavia, Anthos Service Mesh non esegue automaticamente il provisioning dei certificati nel gateway in entrata per il traffico in entrata nel mesh di servizi. Una soluzione comune consiste nell'utilizzare lo strumento open source cert-manager per automatizzare la gestione dei certificati dei gateway in entrata.

Lo strumento cert-manager richiede certificati da un emittente, che rappresenta un'autorità di certificazione (CA). Certificate Authority Service (CA Service) è un servizio Google Cloud che consente di creare la tua CA privata. Lo strumento di gestione dei certificati può richiedere certificati dal servizio CA utilizzando l'emittente esterno per il servizio CA open source.

Una CA privata può emettere certificati TLS che autenticano e criptano il traffico all'interno di una rete interna. I gateway in entrata di Anthos Service Mesh sono spesso configurati in modo da consentire il traffico in entrata dai client che si trovano all'interno del VPC, ma al di fuori del mesh di servizi. Per il traffico di rete interno, puoi utilizzare una CA privata nel servizio CA per emettere certificati per il gateway in entrata.

Questo tutorial mostra come configurare lo strumento cert-manager e l'emittente del servizio CA per automatizzare il provisioning e il rinnovo dei certificati TLS per il gateway in entrata. Lo strumento cert-manager esegue il provisioning dei certificati come risorse secret Kubernetes di tipo TLS. Quando lo strumento cert-manager rinnova un certificato, la risorsa secret viene aggiornata con un nuovo certificato. Il gateway in entrata esegue il proxy Envoy e supporta il servizio di individuazione secret (SDS) di Envoy. SDS consente al gateway in entrata di iniziare a utilizzare un nuovo certificato senza richiedere a un amministratore di riavviare o ricaricare il processo.

I proxy Sidecar che fanno parte del mesh possono ottenere certificati TLS dall'autorità di certificazione CA Service o dall'autorità di certificazione Anthos Service Mesh (Mesh CA). In questo tutorial utilizzerai CA Service sia per i certificati proxy sidecar che per i certificati gateway in entrata. Ciò consente di utilizzare una CA radice per tutti i certificati TLS.

Il seguente diagramma mostra le risorse di cui esegui il provisioning in questo tutorial. Esegui il provisioning di un bilanciatore del carico di rete passthrough interno per il gateway in entrata. Il bilanciatore del carico di rete passthrough interno non è un proxy, quindi non termina le connessioni TCP né esegue handshake TLS. Instrada invece le connessioni ai pod del deployment istio-ingressgateway.

Il secret hello-example-com-credential contiene un certificato e una chiave privata. Il gateway hello configura i pod del deployment di istio-ingressgateway in modo che utilizzino questo certificato e la chiave privata per eseguire handshake TLS per le richieste con il nome host hello.example.com.

gestione mtls con servizio ca

I pod del deployment google-cas-issuer nello spazio dei nomi cert-manager richiedono certificati dalla CA creata in CA Service. Puoi creare un'associazione di criteri di Identity and Access Management che consente ai pod ca-service-isser di impersonare un account di servizio Google utilizzando Workload Identity. Concedi a questo account di servizio Google l'autorizzazione a richiedere certificati dalla tua CA nel servizio CA creando un'associazione di criteri IAM sul pool di CA.

Obiettivi

Costi

Questo tutorial utilizza i seguenti componenti fatturabili di Google Cloud:

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud potrebbero essere idonei per una prova gratuita.

Al termine di questo tutorial, puoi evitare la fatturazione continua eliminando le risorse che hai creato. Per ulteriori informazioni, consulta Pulizia.

Prima di iniziare

  1. Nella console Google Cloud, vai alla pagina del selettore progetti, quindi seleziona o crea un progetto.

  2. Assicurati che la fatturazione sia abilitata per il tuo progetto Google Cloud.

  3. Nella console Google Cloud, vai a Cloud Shell.

    Nella parte inferiore della console Google Cloud, si apre una sessione di Cloud Shell che mostra un prompt della riga di comando. Puoi usare Cloud Shell per eseguire tutti i comandi di questo tutorial.

  4. Imposta il progetto della console Google Cloud che vuoi utilizzare per questo tutorial:

    gcloud config set core/project PROJECT_ID

    Sostituisci PROJECT_ID con l'ID del progetto cloud.

    Nella finestra di dialogo Autorizza Cloud Shell, fai clic su Autorizza. Se fai clic su Autorizza, consenti ai comandi gcloud che esegui in Cloud Shell di utilizzare le tue credenziali utente per l'autenticazione nelle API di Google.

  5. Abilita le API Resource Manager, GKE, GKE Hub, l'autorità di certificazione Anthos Service Mesh e le API CA Service:

    gcloud services enable \
    cloudresourcemanager.googleapis.com \
    container.googleapis.com \
    gkehub.googleapis.com \
    meshca.googleapis.com \
    privateca.googleapis.com

Configura CA Service

In questa sezione creerai una CA radice e due CA subordinate nel servizio CA. Una CA subordinata rilascia certificati nel gateway in entrata, mentre l'altra emette certificati per i proxy sidecar nel mesh.

Per semplicità, utilizzerai lo stesso progetto per il cluster GKE e per le CA radice e subordinate in questo tutorial. Puoi usare un progetto diverso per il cluster GKE e le CA nel tuo ambiente.

  1. In Cloud Shell, crea un pool di CA da utilizzare per la CA principale:

    gcloud privateca pools create ROOT_CA_POOL \
    --location CA_LOCATION \
    --tier enterprise
    • ROOT_CA_POOL è il nome del pool di CA. Ad esempio, root-ca-pool-tutorial.
    • CA_LOCATION è la località del pool di CA. Ad esempio, us-central1.

    Puoi elencare le località del servizio CA disponibili utilizzando questo comando: gcloud privateca locations list

  2. Crea e abilita una CA radice:

    gcloud privateca roots create ROOT_CA \
    --auto-enable \
    --key-algorithm ec-p384-sha384 \
    --location CA_LOCATION \
    --pool ROOT_CA_POOL \
    --subject "CN=Example Root CA, O=Example Organization" \
    --use-preset-profile root_unconstrained
    • ROOT_CA è il nome da utilizzare per la CA radice. Ad esempio, root-ca-tutorial.

  3. Crea un pool di CA da utilizzare per la CA subordinata che emette i certificati nel gateway in entrata:

    gcloud privateca pools create SUBORDINATE_CA_POOL_GATEWAYS \
    --location CA_LOCATION \
    --tier devops
    • SUBORDINATE_CA_POOL_GATEWAYS è il nome del pool di CA. Ad esempio, subordinate-ca-mtls-pool-gateways-tutorial.

  4. Crea e abilita la CA subordinata che emette i certificati nel gateway in entrata:

    gcloud privateca subordinates create SUBORDINATE_CA_GATEWAYS \
    --auto-enable \
    --issuer-location CA_LOCATION \
    --issuer-pool ROOT_CA_POOL \
    --key-algorithm ec-p256-sha256 \
    --location CA_LOCATION \
    --pool SUBORDINATE_CA_POOL_GATEWAYS \
    --subject "CN=Example Gateway mTLS CA, O=Example Organization" \
    --use-preset-profile subordinate_mtls_pathlen_0
    • SUBORDINATE_CA_GATEWAYS è il nome da utilizzare per la CA subordinata. Ad esempio, subordinate-ca-mtls-gateways-tutorial.
    • Il flag --use-preset-profile configura la CA subordinata in modo che utilizzi il profilo del certificato Subordinate mTLS. Questo profilo consente alla CA subordinata di emettere certificati TLS per client e server per mTLS.

    Se vuoi che il gateway in entrata utilizzi TLS semplice anziché mTLS, la CA subordinata deve emettere solo certificati TLS del server. In questo caso, puoi utilizzare invece il profilo certificato TLS del server subordinato (subordinate_server_tls_pathlen_0).

  5. Crea un criterio di emissione dei certificati:

    cat << EOF > policy.yaml
baselineValues:
  keyUsage:
    baseKeyUsage:
      digitalSignature: true
      keyEncipherment: true
    extendedKeyUsage:
      serverAuth: true
      clientAuth: true
  caOptions:
    isCa: false
identityConstraints:
  allowSubjectPassthrough: false
  allowSubjectAltNamesPassthrough: true
  celExpression:
    expression: subject_alt_names.all(san, san.type == URI && san.value.startsWith("spiffe://PROJECT_ID.svc.id.goog/ns/") )
EOF

    Questo criterio di emissione obbliga le CA a rilasciare certificati solo per i carichi di lavoro nel mesh.

  6. Crea un pool di CA da utilizzare per la CA subordinata che emette certificati per i proxy sidecar nel mesh. Applica il criterio di emissione al pool di CA:

    gcloud privateca pools create SUBORDINATE_CA_POOL_SIDECARS \
 --issuance-policy policy.yaml \
 --location CA_LOCATION \
 --tier devops
    • SUBORDINATE_CA_POOL_SIDECARS è il nome del pool di CA. Ad esempio, subordinate-ca-mtls-pool-sidecars-tutorial.

  7. Crea e abilita la CA subordinata che emette certificati per i proxy collaterali nel mesh:

    gcloud privateca subordinates create SUBORDINATE_CA_SIDECARS \
    --auto-enable \
    --issuer-location CA_LOCATION \
    --issuer-pool ROOT_CA_POOL \
    --key-algorithm ec-p256-sha256 \
    --location CA_LOCATION \
    --pool SUBORDINATE_CA_POOL_SIDECARS \
    --subject "CN=Example Sidecar mTLS CA, O=Example Organization" \
    --use-preset-profile subordinate_mtls_pathlen_0
    • SUBORDINATE_CA_GATEWAYS è il nome da utilizzare per la CA subordinata. Ad esempio, subordinate-ca-mtls-sidecars-tutorial.

Crea un cluster Google Kubernetes Engine

  1. In Cloud Shell, crea un cluster GKE:

    gcloud container clusters create CLUSTER_NAME \
    --enable-ip-alias \
    --num-nodes 4 \
    --release-channel regular \
    --scopes cloud-platform \
    --workload-pool PROJECT_ID.svc.id.goog \
    --zone ZONE

    Sostituisci CLUSTER_NAME con il nome che vuoi utilizzare per il cluster. Ad esempio, asm-ingress-cert-manager-ca-service.

    Sostituisci ZONE con la zona che vuoi utilizzare per il cluster. Ad esempio, us-central1-f.

    Tieni presente quanto segue in merito al comando:

    • Il flag --release-channel seleziona il canale di rilascio di GKE per il cluster.
    • Sia Anthos Service Mesh che l'emittente del servizio CA per lo strumento di gestione dei certificati richiedono la configurazione dell'ambito cloud-platform sui nodi del cluster.
    • L'argomento --workload-pool abilita Workload Identity, che consente all'account di servizio Kubernetes dell'emittente del servizio CA di impersonare un account di servizio Google. Questa rappresentazione significa che i pod emittente del servizio CA possono accedere all'API CA Service senza scaricare un file delle chiavi per l'account di servizio Google.

  2. Concedi le autorizzazioni di amministratore del cluster al tuo account utente:

    kubectl create clusterrolebinding cluster-admin-binding \
    --clusterrole cluster-admin \
    --user $(gcloud config get-value core/account)

    Devi disporre delle autorizzazioni fornite da ClusterRole cluster-admin di Kubernetes per creare le regole di controllo controllo dell'accesso basato sui ruoli (RBAC) per Anthos Service Mesh e per installare lo strumento cert-manager.

Installa il piano di controllo di Anthos Service Mesh

In questo tutorial installerai Anthos Service Mesh gestito per un cluster GKE su Google Cloud, con tutte le risorse in un unico progetto. Nel tuo ambiente, puoi applicare la soluzione descritta in questo documento utilizzando Anthos Service Mesh gestito o un piano di controllo nel cluster.

Anthos Service Mesh offre una gamma di opzioni di installazione per scenari diversi. Dopo aver completato questo tutorial, ti consigliamo di consultare la guida all'installazione per selezionare l'opzione più adatta al tuo ambiente.

  1. In Cloud Shell, scarica lo strumento di installazione di asmcli:

    curl --location --output asmcli https://storage.googleapis.com/csm-artifacts/asm/asmcli_1.14

chmod +x asmcli

    Utilizza asmcli per installare il piano di controllo di Anthos Service Mesh.

  2. Installa il piano di controllo di Anthos Service Mesh:

    ./asmcli install \
    --ca gcp_cas \
    --ca_pool projects/PROJECT_ID/locations/CA_LOCATION/caPools/SUBORDINATE_CA_POOL_SIDECARS \
    --channel regular \
    --cluster_location ZONE \
    --cluster_name CLUSTER_NAME \
    --enable_all \
    --enable_registration \
    --fleet_id PROJECT_ID \
    --managed \
    --output_dir asm-files \
    --project_id PROJECT_ID \
    --verbose

    L'installazione richiede diversi minuti. Al termine dell'installazione, vedrai il seguente output:

    asmcli: Successfully installed ASM.`

Installa il gateway in entrata

  1. In Cloud Shell, crea uno spazio dei nomi Kubernetes per il gateway in entrata:

    kubectl create namespace GATEWAY_NAMESPACE
    • GATEWAY_NAMESPACE è il nome dello spazio dei nomi da utilizzare per il gateway in entrata. Ad esempio, istio-ingress.

  2. Prenota un indirizzo IP interno statico da utilizzare per il bilanciatore del carico di rete passthrough interno del gateway in entrata:

    LOAD_BALANCER_IP=$(gcloud compute addresses create \
    asm-ingress-gateway-ilb \
    --region REGION \
    --subnet default \
    --format 'value(address)')
    • Sostituisci REGION con la regione che contiene la zona o le zone utilizzate dai nodi dei cluster GKE. Ad esempio, se il tuo cluster utilizza la zona us-central1-f, sostituisci REGION con us-central1.

    Questo comando prenota un indirizzo IP dalla subnet predefinita nella regione specificata.

  3. Crea un manifest dell'operatore per il gateway in entrata:

    cat << EOF > ingressgateway-operator.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: ingressgateway-operator
  annotations:
    config.kubernetes.io/local-config: "true"
spec:
  profile: empty
  revision: asm-managed
  components:
    ingressGateways:
    - name: istio-ingressgateway
      namespace: GATEWAY_NAMESPACE
      enabled: true
      k8s:
        overlays:
        - apiVersion: apps/v1
          kind: Deployment
          name: istio-ingressgateway
          patches:
          - path: spec.template.metadata.annotations
            value:
              inject.istio.io/templates: gateway
          - path: spec.template.metadata.labels.sidecar\.istio\.io/inject
            value: "true"
          - path: spec.template.spec.containers[name:istio-proxy]
            value:
              name: istio-proxy
              image: auto
        service:
          loadBalancerIP: $LOAD_BALANCER_IP
        serviceAnnotations:
          networking.gke.io/load-balancer-type: Internal
          networking.gke.io/internal-load-balancer-allow-global-access: "true"
EOF

    Tieni presente quanto segue in merito al manifest dell'operatore:

  4. Crea il manifest di installazione del gateway in entrata utilizzando il manifest dell'operatore e lo strumento istioctl scaricato dallo script asmcli al momento dell'installazione del piano di controllo:

    ./asm-files/istioctl manifest generate \
    --filename ingressgateway-operator.yaml \
    --output ingressgateway

  5. Installa il gateway in entrata:

    kubectl apply --recursive --filename ingressgateway/

Installa lo strumento cert-manager

  1. In Cloud Shell, scarica e applica il manifest di installazione dello strumento cert-manager:

    CERT_MANAGER_VERSION=v1.5.4

curl --location --output cert-manager.yaml "https://github.com/jetstack/cert-manager/releases/download/${CERT_MANAGER_VERSION}/cert-manager.yaml"

kubectl apply --filename cert-manager.yaml

    L'installazione dello strumento cert-manager richiede circa un minuto.

Installa il controller emittente del servizio CA

Il controller emittente del servizio CA consente allo strumento cert-manager di richiedere certificati utilizzando il servizio CA. Il controller utilizza il meccanismo di estensione dell'emittente esterno dello strumento di gestione dei certificati.

  1. In Cloud Shell, crea un account di servizio Google:

    gcloud iam service-accounts create CAS_ISSUER_GSA \
    --display-name "CA Service issuer for cert-manager"
    • CAS_ISSUER_GSA è il nome dell'account di servizio Google. Ad esempio, cert-manager-ca-service-issuer.

    Il controller emittente di Certificate Authority Service utilizza questo account di servizio Google per eseguire l'autenticazione nelle API Certificate Authority Service.

  2. Crea un'associazione dei criteri di Identity and Access Management che consenta all'account di servizio Google del controller dell'emittente di Certificate Authority Service di richiedere certificati dal pool di CA che contiene la CA subordinata:

    gcloud privateca pools add-iam-policy-binding SUBORDINATE_CA_POOL_GATEWAYS \
    --location CA_LOCATION \
    --member "serviceAccount:CAS_ISSUER_GSA@PROJECT_ID.iam.gserviceaccount.com" \
    --role roles/privateca.certificateRequester

  3. Scarica il manifest di installazione del controller dell'emittente di Certificate Authority Service:

    CAS_ISSUER_VERSION=v0.5.3

curl --location --output ca-service-issuer.yaml "https://github.com/jetstack/google-cas-issuer/releases/download/${CAS_ISSUER_VERSION}/google-cas-issuer-${CAS_ISSUER_VERSION}.yaml"

  4. Crea un'associazione di criteri IAM per consentire all'account di servizio Kubernetes ksa-google-cas-issuer nello spazio dei nomi cert-manager di impersonare l'account di servizio Google (GSA) utilizzando Workload Identity:

    gcloud iam service-accounts add-iam-policy-binding \
 CAS_ISSUER_GSA@PROJECT_ID.iam.gserviceaccount.com \
    --member "serviceAccount:PROJECT_ID.svc.id.goog[cert-manager/ksa-google-cas-issuer]" \
    --role roles/iam.workloadIdentityUser

    I pod del controller dell'emittente del servizio CA utilizzano l'account di servizio Kubernetes ksa-google-cas-issuer.

  5. Installa il controller emittente del servizio CA nel tuo cluster GKE:

    kubectl apply --filename ca-service-issuer.yaml

  6. Aggiungi l'annotazione Workload Identity iam.gke.io/gcp-service-account all'account di servizio Kubernetes utilizzato dai pod controller dell'emittente del servizio CA:

    kubectl annotate serviceaccount ksa-google-cas-issuer --namespace cert-manager \
   "iam.gke.io/gcp-service-account=CAS_ISSUER_GSA@PROJECT_ID.iam.gserviceaccount.com"

    Questa annotazione informa GKE che l'account di servizio Kubernetes può rappresentare l'account di servizio Google per accedere alle API di Google.

Crea un emittente del certificato

  1. In Cloud Shell, crea e applica un manifest GoogleCASIssuer:

    cat << EOF > gateway-cas-issuer.yaml
apiVersion: cas-issuer.jetstack.io/v1beta1
kind: GoogleCASIssuer
metadata:
  name: gateway-cas-issuer
  namespace: GATEWAY_NAMESPACE
spec:
  caPoolId: SUBORDINATE_CA_POOL_GATEWAYS
  location: CA_LOCATION
  project: PROJECT_ID
EOF

kubectl apply --filename gateway-cas-issuer.yaml

    L'emittente consente allo strumento cert-manager di eseguire il provisioning dei certificati dal pool di CA subordinato nello spazio dei nomi del gateway in entrata

Deployment di un'applicazione di esempio

In questa sezione verificherai che lo strumento di gestione dei certificati possa utilizzare l'emittente del servizio CA per ottenere certificati dal servizio CA. Per verificare, esegui il deployment di un'applicazione di esempio con la configurazione del routing delle richieste e un certificato per il gateway in entrata.

  1. In Cloud Shell, crea uno spazio dei nomi per le risorse dell'applicazione di esempio:

    cat << EOF > sample-app-namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: APP_NAMESPACE
  annotations:
    mesh.cloud.google.com/proxy: '{"managed":"true"}'
  labels:
    istio.io/rev: asm-managed
EOF

kubectl apply --filename sample-app-namespace.yaml
    • APP_NAMESPACE è il nome dello spazio dei nomi per l'applicazione di esempio. Ad esempio, sample-app.

    L'annotazione mesh.cloud.google.com/proxy abilita il piano dati gestito per lo spazio dei nomi.

    L'etichetta istio.io/rev: asm-managed seleziona il canale di rilascio regolare per il piano dati gestito nello spazio dei nomi dell'applicazione di esempio. Modifica il valore di questa etichetta se utilizzi i canali di rilascio rapido o stabile.

  2. Crea una risorsa Deployment per l'applicazione di esempio:

    cat << EOF > deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello
  namespace: APP_NAMESPACE
  labels:
    app: hello
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
      - image: gcr.io/google-samples/hello-app:1.0
        name: hello-app
        ports:
        - containerPort: 8080
EOF

kubectl apply --filename deployment.yaml

  3. Crea una risorsa di servizio per l'applicazione di esempio:

    cat << EOF > service.yaml
apiVersion: v1
kind: Service
metadata:
  name: SERVICE_NAME
  namespace: APP_NAMESPACE
spec:
  ports:
  - name: http-hello
    port: 8080
  selector:
    app: hello
  type: ClusterIP
EOF

kubectl apply --filename service.yaml
    • SERVICE_NAME è il nome del servizio. Ad esempio, hello.

  4. Crea una risorsa di certificato per il nome di dominio hello.example.com utilizzando l'emittente del certificato:

    cat << EOF > certificate.yaml
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: hello-example-com-certificate
  namespace: GATEWAY_NAMESPACE
spec:
  secretName: hello-example-com-credential
  commonName: hello.example.com
  dnsNames:
  - hello.example.com
  duration: 24h
  renewBefore: 8h
  issuerRef:
    group: cas-issuer.jetstack.io
    kind: GoogleCASIssuer
    name: gateway-cas-issuer
EOF

kubectl apply --filename certificate.yaml

    Lo spazio dei nomi del certificato deve corrispondere a quello del gateway in entrata. In genere, solo gli amministratori di piattaforma possono modificare le risorse in questo spazio dei nomi, poiché le modifiche possono interessare l'intero mesh di servizi. Lo strumento cert-manager crea la risorsa secret per il certificato TLS nello stesso spazio dei nomi. Ciò significa che gli amministratori delle applicazioni non devono avere accesso allo spazio dei nomi del gateway in entrata.

    Puoi aggiungere altri nomi host nell'elenco dnsNames nel certificato. Questi nomi host sono inclusi nel certificato come Nomi alternativi dei soggetti (SAN).

  5. Crea una risorsa Gateway per l'applicazione di esempio:

    cat << EOF > gateway.yaml
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: GATEWAY_NAME
  namespace: GATEWAY_NAMESPACE
spec:
  selector:
    istio: ingressgateway
  servers:
  - hosts:
    - APP_NAMESPACE/hello.example.com
    port:
      name: https-hello
      number: 443
      protocol: HTTPS
    tls:
      credentialName: hello-example-com-credential
      mode: MUTUAL
EOF

kubectl apply --filename gateway.yaml
    • GATEWAY_NAME è il nome del gateway. Ad esempio, hello.
    • Il campo credentialName nel gateway corrisponde al campo secretName nel certificato. Lo strumento cert-manager crea un secret Kubernetes con il certificato TLS di CA Service. Questo certificato consente al gateway in entrata di terminare il traffico TLS destinato a hello.example.com.

    Il manifest del gateway specifica MUTUAL TLS (mTLS). Se vuoi configurare il gateway per il protocollo TLS standard, imposta la modalità TLS del gateway su SIMPLE.

  6. Crea una risorsa VirtualService per l'applicazione di esempio:

    cat << EOF > virtual-service.yaml
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: hello
  namespace: APP_NAMESPACE
spec:
  hosts:
  - hello.example.com
  gateways:
  - GATEWAY_NAMESPACE/GATEWAY_NAME
  http:
  - route:
    - destination:
        host: SERVICE_NAME
        port:
          number: 8080
EOF

kubectl apply --filename virtual-service.yaml

    Il gateway e VirtualService utilizzano spazi dei nomi diversi. Questo pattern comune limita le modifiche al routing basato su host nel gateway per gli amministratori di piattaforma che dispongono delle autorizzazioni per modificare le risorse nello spazio dei nomi del gateway in entrata.

    Gli amministratori delle applicazioni con autorizzazioni per modificare VirtualService nello spazio dei nomi dell'applicazione di esempio possono modificare il routing in base ad altri campi di richiesta, ad esempio il percorso dell'URL, senza coordinarsi con gli amministratori della piattaforma.

Se vuoi esplorare altre opzioni di configurazione, leggi la documentazione API per le risorse Certificato, Gateway e VirtualService.

Puoi applicare criteri di autenticazione e autorizzazione al traffico che entra nel mesh di servizi attraverso il gateway in entrata. A questo scopo, leggi la documentazione delle API Istio PeerAuthentication e AuthorizationPolicy.

Verifica la soluzione

In questa sezione verificherai di poter inviare richieste HTTPS utilizzando mTLS all'applicazione di esempio dall'esterno del mesh di servizi. Per verificare, crea un'istanza VM di Compute Engine, richiedi un certificato TLS client al servizio CA e utilizza questo certificato per autenticare la richiesta all'applicazione di esempio.

Devi disporre dell'accesso SSH all'istanza VM. La rete predefinita include una regola firewall che consente l'accesso SSH. Se non hai accesso SSH, segui la documentazione sulle regole firewall per creare una regola firewall che consenta le connessioni TCP in entrata sulla porta 22.

  1. In Cloud Shell, crea un account di servizio Google:

    gcloud iam service-accounts create CLIENT_VM_GSA \
    --display-name "CA Service tutorial VM instance service account"
    • CLIENT_VM_GSA è il nome dell'account di servizio Google. Ad esempio, cas-tutorial-client.

    Devi assegnare questo account di servizio Google all'istanza VM di Compute Engine.

  2. Concedi il ruolo Richiedente certificato di servizio CA sul pool di CA subordinato dei gateway all'account di servizio Google:

    gcloud privateca pools add-iam-policy-binding SUBORDINATE_CA_POOL_GATEWAYS \
    --location CA_LOCATION \
    --member "serviceAccount:CLIENT_VM_GSA@PROJECT_ID.iam.gserviceaccount.com" \
    --role roles/privateca.certificateRequester

    Questo ruolo fornisce le autorizzazioni per richiedere certificati dal pool di CA.

  3. Crea un'istanza VM di Compute Engine nello stesso VPC del cluster GKE:

    gcloud compute instances create cas-tutorial-client \
    --scopes cloud-platform \
    --service-account CLIENT_VM_GSA@PROJECT_ID.iam.gserviceaccount.com \
    --zone ZONE

    L'istanza VM richiede l'ambito cloud-platform per accedere all'API CA Service.

  4. Salva l'indirizzo IP del bilanciatore del carico di rete passthrough interno del gateway in entrata in un file:

    kubectl get services istio-ingressgateway \
   --namespace GATEWAY_NAMESPACE \
   --output jsonpath='{.status.loadBalancer.ingress[0].ip}' > ilb-ip.txt

  5. Salva il certificato di chiave pubblica della tua CA radice in un file:

    gcloud privateca roots describe ROOT_CA \
    --location CA_LOCATION \
    --pool ROOT_CA_POOL \
    --format 'value(pemCaCertificates)' > root-ca-cert.pem

  6. Copia nell'istanza VM il certificato CA radice e il file contenente l'indirizzo IP del bilanciatore del carico di rete passthrough interno del gateway in entrata:

    gcloud compute scp root-ca-cert.pem ilb-ip.txt cas-tutorial-client:~ \
   --zone ZONE

  7. Connettiti all'istanza VM tramite SSH:

    gcloud compute ssh cas-tutorial-client --zone ZONE

    Esegui gli altri comandi di questa sezione dalla sessione SSH.

  8. Installa i pacchetti ca-certificates e coreutils e gli strumenti a riga di comando curl, openssl e jq:

    sudo apt-get update --yes

sudo apt-get install --yes ca-certificates coreutils curl jq openssl

  9. Crea una coppia di chiavi per il certificato TLS del client:

    openssl genrsa -out private-key.pem 2048

openssl rsa -in private-key.pem -pubout -out public-key.pem

  10. Esegui una query sul server di metadati per ottenere l'indirizzo email dell'identità dell'account di servizio Google collegata all'istanza VM:

    GSA_EMAIL=$(curl --silent --header "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/email)

  11. Crea un file JSON da utilizzare come corpo della richiesta quando richiedi un certificato TLS client dall'API Certificate Authority Service:

    cat << EOF > request.json
{
  "config": {
    "publicKey": {
      "format": "PEM",
      "key": "$(base64 --wrap 0 public-key.pem)"
    },
    "subjectConfig": {
      "subject": {
        "commonName": "$(hostname --short)",
        "organization": "Example Organization"
      },
      "subjectAltName": {
        "dnsNames": [
          "$(hostname --fqdn)"
        ],
        "emailAddresses": [
          "$GSA_EMAIL"
        ]
      }
    },
    "x509Config": {
      "caOptions": {
        "isCa": false
      },
      "keyUsage": {
        "baseKeyUsage": {
          "digitalSignature": true,
          "keyEncipherment": true
        },
        "extendedKeyUsage": {
          "clientAuth": true
        }
      }
    }
  },
  "lifetime": "86400s"
}
EOF

    Per scoprire di più sui campi della sezione di configurazione, consulta il tipo di CertificateConfig nella documentazione dell'API CA Service.

  12. Richiedi un token di accesso OAuth 2.0 dal server di metadati:

    TOKEN=$(curl --silent --header "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token | jq --raw-output ".access_token")

    Questo token di accesso fornisce le autorizzazioni concesse all'account di servizio Google collegato all'istanza VM.

  13. Richiedi un certificato TLS client all'API CA Service e archivia il corpo della risposta in un file:

    curl --silent --request POST \
    --header "Authorization: Bearer $TOKEN" \
    --header "Content-Type: application/json" \
    --data @request.json \
    --output response.json \
    "https://privateca.googleapis.com/v1/projects/PROJECT_ID/locations/CA_LOCATION/caPools/SUBORDINATE_CA_POOL_GATEWAYS/certificates"

    Il comando utilizza il token di accesso per autenticare la richiesta API.

  14. Salva il certificato client e la catena di certificati in un file:

    jq --raw-output --join-output ".pemCertificate , .pemCertificateChain[]" response.json > client-cert-chain.pem

  15. Utilizza curl per inviare una richiesta HTTPS dall'istanza VM all'applicazione di esempio:

    curl --cert client-cert-chain.pem --key private-key.pem \
    --cacert root-ca-cert.pem \
    --resolve hello.example.com:443:$(cat ilb-ip.txt) \
    --silent https://hello.example.com | head -n1

    L'output sarà simile al seguente:

    Hello, world!

    Questa risposta mostra che curl ha inviato correttamente la richiesta HTTPS utilizzando mTLS. L'applicazione di esempio ha risposto con il messaggio che vedi nell'output del terminale.

    Il comando curl svolge le seguenti operazioni:

    • I flag --cert e --key indicano a curl di utilizzare il certificato TLS del client e la chiave privata per autenticare la richiesta. Il file del certificato client contiene l'intera catena di certificati, dal certificato client alla CA radice.

    • Il flag --cacert indica a curl di verificare che la CA radice creata in questo tutorial, o una delle sue CA subordinate, abbia emesso il certificato del server.

      Se ometti questo flag, curl tenta di verificare il certificato del server utilizzando il bundle CA predefinito del tuo sistema operativo, ad esempio il pacchetto ca-certificates su Debian. La verifica non va a buon fine perché il bundle di CA predefinito non include la CA radice che hai creato in questo tutorial.

    • Il flag --resolve indica a curl di utilizzare l'indirizzo IP del bilanciatore del carico di rete passthrough interno come destinazione per le richieste all'host hello.example.com sulla porta 443.

      Se ometti questo flag, curl tenta di utilizzare il DNS per risolvere il nome host hello.example.com. La risoluzione DNS non va a buon fine perché non è presente alcuna voce DNS per questo nome host.

      Nel tuo ambiente, ti consigliamo di creare un record A DNS che indirizzi all'indirizzo IP del bilanciatore del carico di rete passthrough interno ($LOAD_BALANCER_IP). Crea questo record utilizzando Cloud DNS seguendo la documentazione sulla gestione dei record.

    • Il flag --silent elimina i report sull'avanzamento del download delle risposte nell'output del terminale.

    • Il comando invia l'output curl a head -n1. Il risultato è che l'output nel terminale include solo la prima riga del corpo della risposta.

  16. Esci dalla sessione SSH:

    exit

In questa sezione hai richiesto un certificato TLS client direttamente dall'API CA Service. Nella situazione in cui il client è il gateway in uscita di un altro mesh di servizi in un cluster Kubernetes separato, puoi utilizzare lo strumento cert-manager e l'emittente di Certificate Authority Service con la stessa CA radice per fornire certificati client al gateway in uscita.

In altre situazioni, puoi utilizzare strumenti come Hashicorp Vault, Terraform o gcloud per richiedere certificati TLS client per carichi di lavoro esterni alla rete mesh di servizi. Per ulteriori informazioni, consulta la documentazione del servizio CA per le soluzioni di esempio e la documentazione di gcloud per il servizio CA.

(Facoltativo) Aggiungi certificati CA all'archivio di attendibilità

Questa sezione facoltativa mostra come aggiungere certificati CA all'archivio di certificati CA attendibili per la distribuzione Debian di Linux. Queste istruzioni si applicano anche alle distribuzioni derivate da Debian, come Ubuntu.

Se aggiungi i tuoi certificati CA a questo archivio, non devi specificare la posizione dei certificati CA attendibili durante l'invio di richieste HTTPS utilizzando curl, Python, Go e Ruby.

  1. Connettiti all'istanza VM tramite SSH:

    gcloud compute ssh cas-tutorial-client --zone ZONE

    Esegui gli altri comandi di questa sezione dalla sessione SSH.

  2. Copia il certificato CA radice nella directory /usr/local/share/ca-certificates e assicurati che il file abbia l'estensione .crt:

    sudo cp root-ca-cert.pem /usr/local/share/ca-certificates/cas-rootca.crt

  3. Imposta le autorizzazioni del file in modo che tutti gli utenti possano leggere il file del certificato CA radice:

    sudo chmod 644 /usr/local/share/ca-certificates/cas-rootca.crt

  4. Esegui lo script update-ca-certificates:

    sudo update-ca-certificates

    Questo script aggiunge il certificato al set di certificati attendibili nella directory /etc/ssl/certs e al file /etc/ssl/certs/ca-certificates.crt.

    L'output è il seguente:

    Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.

  5. Utilizza curl per inviare una richiesta HTTPS dall'istanza VM all'applicazione di esempio:

    curl --cert client-cert-chain.pem --key private-key.pem \
   --resolve hello.example.com:443:$(cat ilb-ip.txt) \
   --silent https://hello.example.com | head -n1

    L'output sarà simile al seguente:

    Hello, world!

    Questa risposta mostra che curl ha inviato correttamente la richiesta HTTPS utilizzando mTLS e ha convalidato il certificato TLS del server dal gateway in entrata utilizzando l'archivio certificati CA predefinito.

  6. Esci dalla sessione SSH:

    exit

Risolvere i problemi

Se il controller dell'emittente del servizio CA non crea il secret del certificato TLS, visualizza i log del controller dell'emittente del servizio CA:

kubectl logs deployment/google-cas-issuer --namespace cert-manager

In caso di problemi durante l'installazione di Anthos Service Mesh, esegui lo strumento asmcli per convalidare il tuo progetto Cloud e il tuo cluster GKE.

Se riscontri altri problemi con questo tutorial, ti consigliamo di consultare questi documenti:

Esegui la pulizia

Per evitare che al tuo account Google Cloud vengano addebitati ulteriori costi per le risorse utilizzate in questo tutorial, puoi eliminare il progetto o le singole risorse.

Elimina il progetto

  1. In Cloud Shell, elimina il progetto:

    gcloud projects delete PROJECT_ID

Elimina le risorse

Se vuoi mantenere il progetto Google Cloud che hai utilizzato in questo tutorial, elimina le singole risorse:

  1. In Cloud Shell, annulla la registrazione del cluster GKE da GKE Hub:

    gcloud container hub memberships unregister CLUSTER_NAME \
    --gke-cluster ZONE/CLUSTER_NAME

  2. Elimina il cluster GKE:

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

  3. Elimina le associazioni di criteri IAM sul pool di CA subordinato:

    gcloud privateca pools remove-iam-policy-binding SUBORDINATE_CA_POOL_GATEWAYS \
    --location CA_LOCATION \
    --member "serviceAccount:CAS_ISSUER_GSA@PROJECT_ID.iam.gserviceaccount.com" \
    --role roles/privateca.certificateRequester

gcloud privateca pools remove-iam-policy-binding SUBORDINATE_CA_POOL_GATEWAYS \
    --location CA_LOCATION \
    --member "serviceAccount:CLIENT_VM_GSA@PROJECT_ID.iam.gserviceaccount.com" \
    --role roles/privateca.certificateRequester

  4. Disabilita e pianifica l'eliminazione delle CA subordinate e della CA radice:

    gcloud privateca subordinates disable SUBORDINATE_CA_GATEWAYS \
    --location CA_LOCATION \
    --pool SUBORDINATE_CA_POOL_GATEWAYS \
    --quiet

gcloud privateca subordinates delete SUBORDINATE_CA_GATEWAYS \
    --location CA_LOCATION \
    --pool SUBORDINATE_CA_POOL_GATEWAYS \
    --ignore-active-certificates \
    --quiet

gcloud privateca subordinates disable SUBORDINATE_CA_SIDECARS \
    --location CA_LOCATION \
    --pool SUBORDINATE_CA_POOL_SIDECARS \
    --quiet

gcloud privateca subordinates delete SUBORDINATE_CA_SIDECARS \
    --location CA_LOCATION \
    --pool SUBORDINATE_CA_POOL_SIDECARS \
    --ignore-active-certificates \
    --quiet

gcloud privateca roots disable ROOT_CA \
    --location CA_LOCATION \
    --pool ROOT_CA_POOL \
    --quiet

gcloud privateca roots delete ROOT_CA \
    --location CA_LOCATION \
    --pool ROOT_CA_POOL \
    --ignore-active-certificates \
    --quiet

  5. Elimina l'associazione dei criteri IAM per l'account di servizio Google del titolare dell'emittente del servizio CA:

    gcloud iam service-accounts remove-iam-policy-binding \
    CAS_ISSUER_GSA@PROJECT_ID.iam.gserviceaccount.com \
    --member "serviceAccount:PROJECT_ID.svc.id.goog[cert-manager/ksa-google-cas-issuer]" \
    --role roles/iam.workloadIdentityUser

  6. Elimina gli account di servizio Google:

    gcloud iam service-accounts delete --quiet \
    CAS_ISSUER_GSA@PROJECT_ID.iam.gserviceaccount.com

gcloud iam service-accounts delete --quiet \
    CLIENT_VM_GSA@PROJECT_ID.iam.gserviceaccount.com

  7. Elimina l'indirizzo IP riservato del bilanciatore del carico:

    gcloud compute addresses delete asm-ingress-gateway-ilb \
    --region REGION --quiet

  8. Elimina l'istanza VM di Compute Engine:

    gcloud compute instances delete cas-tutorial-client \
    --zone ZONE --quiet

Passaggi successivi