Risoluzione dei 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 aiuto, vedi Ricevere assistenza.
In Cloud Service Mesh, Mesh CA o Istiod emette certificati per i carichi di lavoro in tutti i cluster nella rete. Criteri di autenticazione (ad esempio mTLS) e di autorizzazione (ad esempio allow/deny) vengono inviati a ciascun 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 normale non siano consentite per un servizio, quando quest'ultimo 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:
Esegui il deployment del servizio di esempio
httpbin
, che può visualizzare le intestazioni riceve.Utilizza
curl
per visualizzare l'intestazioneX-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
In alternativa, utilizza
openssl
sul file collaterale 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 suO = <var>YOUR_TRUST_DOMAIN</var>
.
Errori TLS bad certificate
nei log Istiod
Se vedi errori di handshake TLS bad certificate
nei log, 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.
In genere questi errori sono informativi e temporanei. Tuttavia, se persistono, potrebbero indicare un problema del sistema.
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 A questo bundle CA è stata applicata la patch alla configurazione da istiod, ma a volte vengono sovrascritti (ad esempio, se applichi di nuovo il webhook configurazione di base).
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 una nuova scansione del webhook e lo reinstalli del bundle CA.
Log di negazione dei criteri di autorizzazione
Per informazioni sul logging dei criteri di autorizzazione, consulta Denial logging.
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 sono
in modo corretto, come nell'esempio seguente:
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
"customresourcedefinitions.apiextensions.k8s.io è vietato" errore nei log 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 Istiod non ha l'associazione IAM corretta o non dispone di autorizzazioni RBAC sufficienti per leggere una risorsa personalizzata.
Controlla se manca un'associazione IAM nel tuo account. Innanzitutto, assicurati di avere correttamente impostare credenziali e autorizzazioni. Verifica quindi che sia presente l'associazione IAM utilizzando il comando seguente. Nel in questo esempio, PROJECT_ID è l'output di
gcloud config get-value project
e PROJECT_NUMBER è l'output digcloud 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"
Verifica che le regole RBAC siano installate correttamente.
Se mancano le regole RBAC, esegui nuovamente
asmcli install
per ricrearli.Se le regole RBAC sono presenti e gli errori persistono, verifica che
ClusterRoleBindings
eRoleBindings
stanno collegando le regole RBAC al l'account di servizio Kubernetes corretto. Verifica inoltre che il deployment Istio sia utilizzando 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 espressioni regolari /serverca.*Authentication failed:.*JWT/
per
a 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 istiod.