Risolvere i problemi di sicurezza in Cloud Service Mesh

Questa sezione illustra i problemi comuni di Cloud Service Mesh e come risolverli. Se hai bisogno di ulteriore assistenza, consulta la sezione Ricevere assistenza.

In Cloud Service Mesh, Mesh CA o Istiod emette certificati per i carichi di lavoro su tutti i cluster nel mesh. I criteri di autenticazione (ad esempio mTLS) e di autorizzazione (ad esempio consenti/nega) vengono inviati a ogni cluster. Questi criteri determinano quali carichi di lavoro possono comunicare e come.

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 contesto nome 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 in testo 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 precedente richiesta in testo normale non dovrebbe riuscire, generando un output simile al seguente:

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

Controlla i certificati mTLS

Quando mTLS è abilitato, controlla il certificato mTLS del carico di lavoro 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 ricevute.

  2. Usa 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 sidecar per visualizzare l'intera catena di certificati:

    kubectl exec --context=${CTX} SOURCE_POD -n SOURCE_NAMESPACE -c istio-proxy \
openssl s_client -alpn istio -showcerts -connect httpbin.sample:8000

    L'output mostrerà la catena di certificati. Se utilizzi Mesh CA, verifica il CN del certificato radice contiene istio_v1_cloud_workload_root-signer-.... Se stai utilizzando Istiod come autorità di certificazione, verifica che l'istanza radice sia impostato su O = <var>YOUR_TRUST_DOMAIN</var>.

Errori TLS bad certificate nei log di Istiod

Se nei log vengono visualizzati errori bad certificate di handshake TLS, è possibile che Istiod non riesca a stabilire una connessione TLS a un servizio.

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

In genere questi errori sono informativi e temporanei. Tuttavia, se persistono, potrebbero indicare un problema del sistema.

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

    Il webhook di inserimento del sidecar (utilizzato per l'inserimento automatico del sidecar) richiede un bundle CA per stabilire connessioni sicure con il server API e Istio Questo bundle CA viene applicato alla configurazione da istiod, ma a volte può essere sovrascritto (ad esempio, se si applica di nuovo la configurazione del 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, viene configurato il bundle CA. Se il bundle CA è mancante, riavvia istiod per far sì che esegua di nuovo la scansione del webhook e lo reinstalli del bundle CA.

Log dei rifiuti dei criteri di autorizzazione

Per informazioni sul logging dei rifiuti dei criteri di autorizzazione, consulta Logging dei rifiuti.

I criteri di autorizzazione non vengono applicati

Se noti sintomi di mancata applicazione dei criteri di autorizzazione, utilizza seguente 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 i criteri di autorizzazione vengono applicati correttamente, ad esempio:

RBAC: access denied

Se confermi che i criteri di autorizzazione non sono applicati, nega l'accesso al nello 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 espressioni regolari /error.*cannot list resource/ per a trovare questi errori nei log.

Questo errore può verificarsi quando il deployment di Istiod non dispone dell'associazione IAM corretta o non dispone di autorizzazioni RBAC sufficienti per leggere una risorsa personalizzata.

  1. Verifica se nel tuo account manca un'associazione IAM. Innanzitutto, assicurati di avere correttamente impostare 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 nuovamente asmcli install per ricrearle.

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

serverca errori di processo nei log 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 non è configurato correttamente, un client utilizza un scaduto o dovuto a qualche altro problema di sicurezza che impedisce la connessione correttamente l'autenticazione su Istio.