Risoluzione dei problemi di sicurezza in Anthos Service Mesh
Questa sezione illustra i problemi comuni di Anthos Service Mesh e come risolverli. Se hai bisogno di ulteriore assistenza, vedi Richiedere assistenza.
In Anthos Service Mesh, Mesh CA o Istio rilascia i certificati per i carichi di lavoro in tutti i cluster nel mesh. Viene eseguito il push dei criteri di autenticazione (mTLS, ad esempio) e di autorizzazione (consenti/deny) ad ogni cluster. Questi criteri determinano i carichi di lavoro che possono comunicare e come.
Problemi relativi a TLS
Le seguenti sezioni spiegano come risolvere i problemi relativi a TLS in Anthos Service Mesh.
Gli esempi in questa sezione utilizzano la variabile ${CTX}
, che è il nome di contesto nel
file di configurazione Kubernetes predefinito
che utilizzi per accedere al cluster. Imposta la variabile ${CTX}
nel seguente modo:
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 quest'ultimo richiede connessioni TLS:
kubectl exec SOURCE_POD -n SOURCE_NAMESPACE -c \ SOURCE_CONTAINER -- curl -v DESTINATION_URL
Se il servizio richiede connessioni TLS, la richiesta di testo normale indicata sopra non dovrebbe riuscire, 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 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 che riceve.Usa
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
sulla barra laterale 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 mostra la catena di certificati. Se utilizzi Mesh CA, verifica che il CN del certificato radice contenga
istio_v1_cloud_workload_root-signer-...
. Se utilizzi Istiod come autorità di certificazione, verifica che il certificato radice sia impostato conO = <var>YOUR_TRUST_DOMAIN</var>
.
Errori bad certificate
di TLS nei log Istio
Se nei log compaiono errori bad certificate
di handshake TLS, è possibile che Istio non riesca 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 di solito informativi e temporanei. Tuttavia, se persiste, potrebbe indicare un problema del sistema.
Verifica che il
MutatingWebhookConfiguration
diistio-sidecar-injector
disponga di un bundle CA.Il webhook iniettore sidecar (utilizzato per l'inserimento automatico dei file collaterali) richiede un bundle di CA per stabilire connessioni sicure con il server API e Istiod. A questo bundle CA è applicato un patch nella configurazione da istiod, ma a volte può essere sovrascritto (ad esempio, se applichi di nuovo la configurazione webhook).
Verifica la presenza del bundle CA:
kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io istio-sidecar-injector -o=jsonpath='{.webhooks[0].clientConfig.caBundle}'
Se l'output non è vuoto, viene configurato il bundle CA. Se il bundle CA non è presente, riavvia
istiod
per causare una nuova scansione del webhook e la reinstallazione.
Logging del criterio di autorizzazione
Per informazioni sul log di rifiuto dei criteri di autorizzazione, consulta Log di rifiuto.
I criteri di autorizzazione non vengono applicati
Se noti uno sintomo di mancata applicazione dei criteri di autorizzazione, utilizza il seguente comando per verificarli:
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 applicati correttamente, come segue:
RBAC: access denied
Se confermi che i criteri di autorizzazione non sono applicati, impedisci 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
'customresourceDefinitions.apiextensions.k8s.io è vietato' errore nei log di Istio
Potresti vedere 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 dell'espressione regolare /error.*cannot list resource/
per trovare questi errori nei log.
Questo errore può verificarsi quando il deployment Istio non presenta l'associazione IAM corretta o non dispone di autorizzazioni RBAC insufficienti per leggere una risorsa personalizzata.
Controlla se manca un'associazione IAM nel tuo account. Innanzitutto, assicurati di avere impostato correttamente le credenziali e le 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 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 le regole RBAC non sono presenti, esegui nuovamente
istioctl install
(o il metodo di installazione utilizzato per installare Anthos Service Mesh) per ricrearle.Se sono presenti regole RBAC e gli errori persistono, verifica che
ClusterRoleBindings
eRoleBindings
allegano le regole RBAC all'account di servizio Kubernetes corretto. Verifica inoltre che il deployment istiod utilizzi l'account di servizio specificato.
serverca
errori di processo nei log Istio
Potresti vedere errori simili ai seguenti:
Authentication failed: Authenticator ClientCertAuthenticator at index 0 got error
Puoi utilizzare la stringa dell'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 token scaduto o qualche altro problema di sicurezza impedisce una connessione corretta per l'autenticazione sull'istituzione.