Risoluzione dei problemi di sicurezza in Cloud Service Mesh

Questa sezione spiega i problemi comuni relativi alle API Cloud Service Mesh con Istio e come risolverli. Se hai bisogno di ulteriore assistenza, consulta la sezione Richiedere assistenza.

In Cloud Service Mesh, l'autoritร  di certificazione Cloud Service Mesh o Istiod rilascia certificati ai workload in tutti i cluster del mesh. Le norme di autenticazione (ad esempio mTLS) e autorizzazione (ad esempio consenti/nega) vengono inviate a ogni cluster. Queste norme determinano quali carichi di lavoro possono comunicare e in che modo.

Problemi TLS

Le sezioni seguenti spiegano come risolvere i problemi relativi a TLS in Cloud Service Mesh.

Gli esempi in questa sezione utilizzano la variabile ${CTX}, che รจ il nome del contesto nel file di configurazione Kubernetes predefinito che utilizzi per accedere al cluster. Imposta la variabile ${CTX} come nell'esempio seguente:

export CTX=gke_PROJECT_ID_CLUSTER_LOCATION_CLUSTER_NAME

Verificare l'applicazione forzata di TLS

Verifica che le richieste di testo normale non siano consentite per un servizio quando il servizio richiede connessioni TLS:

kubectl exec SOURCE_POD -n SOURCE_NAMESPACE -c \
    SOURCE_CONTAINER -- curl -v DESTINATION_URL

Supponendo che il servizio richieda connessioni TLS, la richiesta di testo normale precedente non dovrebbe andare a buon fine, generando un output simile al seguente:

curl: (56) Recv failure: Connection reset by peer command terminated with exit code 56

Controllare i certificati mTLS

Quando mTLS รจ abilitato, controlla il certificato mTLS del workload visualizzando l'intestazione X-Forwarded-Client-Cert. Per farlo, segui questi passaggi:

  1. Esegui il deployment del servizio di esempio httpbin, che puรฒ visualizzare le intestazioni che riceve.

  2. Utilizza curl per visualizzare l'intestazione X-Forwarded-Client-Cert:

    kubectl exec --context=${CTX} SOURCE_POD -n SOURCE_NAMESPACE -c \
SOURCE_CONTAINER -- curl http://httpbin.sample:8000/headers -s | \
grep X-Forwarded-Client-Cert

    L'intestazione X-Forwarded-Client-Cert mostra le informazioni sui certificati mTLS, come nell'esempio seguente:

    X-Forwarded-Client-Cert": "By=spiffe://lt-multicluster-t2-5-15-2020.svc.id.goog/ns/sample/sa/httpbin;Hash=0781d68adfdab85b08b6758ed502f352464e81166f065cc6acde9433337b4494;Subject=\"OU=istio_v1_cloud_workload,O=Google LLC,L=Mountain View,ST=California,C=US\";URI=spiffe://lt-multicluster-t2-5-15-2020.svc.id.goog/ns/sample/sa/sleep

  3. In alternativa, utilizza openssl nel riquadro laterale per visualizzare l'intera catena di certificati:

    kubectl debug --image istio/base --target istio-proxy -it --context=${CTX} SOURCE_POD \
-n SOURCE_NAMESPACE -- openssl s_client -alpn istio -showcerts -connect httpbin.sample:8000

    L'output mostrerร  la catena di certificati. Se utilizzi Mesh CA, verifica che il nome comune del certificato radice contenga istio_v1_cloud_workload_root-signer-.... Se utilizzi Istiod come autoritร  di certificazione, verifica che il certificato root sia impostato con O = <var>YOUR_TRUST_DOMAIN</var>.

Errori TLS bad certificate nei log di Istiod

Se nei log vengono visualizzati errori di handshake TLS bad certificate, potrebbe indicare che Istiod non riesce a stabilire una connessione TLS a un servizio.

Puoi utilizzare la stringa di espressione regolare TLS handshake error.*bad certificate per trovare questi errori nei log.

Questi errori sono in genere informativi e temporanei. Tuttavia, se persistono, potrebbero indicare un problema nel tuo sistema.

  1. Verifica che il tuo istio-sidecar-injector MutatingWebhookConfiguration abbia un bundle CA.

    Il webhook di inserimento sidecar (utilizzato per l'inserimento automatico di sidecar) richiede un bundle CA per stabilire connessioni sicure con il server API e Istiod. Questo bundle CA viene applicato alla configurazione da istiod, ma a volte puรฒ essere sovrascritto (ad esempio, se riapplichi la configurazione webhook).

  2. Verifica la presenza del bundle CA:

    kubectl get mutatingwebhookconfiguration -l app=sidecar-injector -o=jsonpath='{.items[0].webhooks[0].clientConfig.caBundle}'

    Se l'output non รจ vuoto, il bundle CA รจ configurato. Se il bundle CA non รจ presente, riavvia istiod per forzare la nuova scansione del webhook e la reinstallazione del bundle CA.

Configurazione SNI esplicita

Quando utilizzi SNI per il routing del traffico in un servizio esterno, se vuoi stabilire una connessione TLS utilizzando l'origine TLS, devi specificare SNI in modo esplicito in ClientTLSSettings.sni in DestinationRule. Ad esempio,

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: my-external-service-dr
spec:
  host: external.example.com # The host for which this DestinationRule applies
  trafficPolicy:
    tls:
      mode: SIMPLE # Or MUTUAL, if mTLS is required
      sni: specific-sni.example.com # The SNI value to set for outbound TLS connections

Registrazione dei rifiuti delle policy di autorizzazione

Per informazioni sulla registrazione dei rifiuti dei criteri di autorizzazione, consulta Registrazione dei rifiuti.

I criteri di autorizzazione non vengono applicati

Se noti sintomi di mancata applicazione delle policy di autorizzazione, utilizza il seguente comando per verificarle:

kubectl exec --context=${CTX} -it SOURCE_POD -n SOURCE_NAMESPACE \
    -c SOURCE_CONTAINER -- curl DESTINATION_URL

Nell'output, i messaggi access denied indicano che le norme di autorizzazione vengono applicate correttamente, come segue:

RBAC: access denied

Se confermi che i criteri di autorizzazione non vengono applicati, nega l'accesso allo spazio dei nomi. L'esempio seguente nega l'accesso allo spazio dei nomi denominato authz-ns:

kubectl apply --context=${CTX} -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-authz-ns
  namespace: authz-ns
spec:
  {}
EOF

Errore "customresourcedefinitions.apiextensions.k8s.io is forbidden" nei log di Istiod

Potresti visualizzare errori simili ai seguenti:

error failed to list CRDs: customresourcedefinitions.apiextensions.k8s.io is forbidden: User "system:serviceaccount:istio-system:istiod-service-account" cannot list resource "customresourcedefinitions" in API group "apiextensions.k8s.io" at the cluster scope

Puoi utilizzare la stringa di espressione regolare /error.*cannot list resource/ per trovare questi errori nei log.

Questo errore puรฒ verificarsi quando il deployment di Istiod non dispone del binding IAM corretto o non dispone di autorizzazioni RBAC sufficienti per leggere una risorsa personalizzata.

  1. Controlla se nel tuo account manca un binding IAM. Innanzitutto, assicurati di aver impostato correttamente credenziali e autorizzazioni. Quindi, verifica che l'associazione IAM sia presente utilizzando il seguente comando. In questo esempio, PROJECT_ID รจ l'output di gcloud config get-value project e PROJECT_NUMBER รจ l'output di gcloud projects list --filter="project_id=${PROJECT_ID}" --format="value(project_number)":

    gcloud projects add-iam-policy-binding ${PROJECT_ID} --member "serviceAccount:service-${PROJECT_NUMBER}@gcp-sa-meshdataplane.iam.gserviceaccount.com" --role "roles/meshdataplane.serviceAgent"

  2. Verifica che le regole RBAC siano installate correttamente.

  3. Se le regole RBAC non sono presenti, esegui di nuovo asmcli install per ricrearle.

  4. Se le regole RBAC sono presenti e gli errori persistono, verifica che ClusterRoleBindings e RoleBindings colleghino le regole RBAC all'account di servizio Kubernetes corretto. Inoltre, verifica che il deployment di istiod utilizzi l'account di servizio specificato.

serverca errori di elaborazione nei log di Istiod

Potresti visualizzare errori simili ai seguenti:

Authentication failed: Authenticator ClientCertAuthenticator at index 0 got error

Puoi utilizzare la stringa di espressione regolare /serverca.*Authentication failed:.*JWT/ per trovare questi errori nei log.

Questo errore puรฒ verificarsi quando l'emittente JWT รจ configurato in modo errato, un client utilizza un token scaduto o un altro problema di sicurezza impedisce l'autenticazione di una connessione a istiod.

Aggiornamenti lenti del certificato e della chiave privata per TLS di Ingress Gateway

Se il tuo cluster utilizza l'TRAFFIC_DIRECTORimplementazione del control plane e il gateway in entrata utilizza un deployment senza credenziali montate, gli aggiornamenti delle credenziali potrebbero richiedere fino a 60 minuti.

Per applicare immediatamente il nuovo certificato, puoi riavviare i pod del gateway in entrata o seguire le istruzioni per ottimizzare il deployment.