Stai visualizzando la documentazione di Service Mesh 1.21.

Versioni disponibili

Cloud Service Mesh
Archivio 1.22
Archivio 1.21
Archivio 1.20
Archivio 1.19
Archivio 1.18

Questa pagina è stata tradotta dall'API Cloud Translation.

Risoluzione dei problemi di sicurezza in Cloud Service Mesh

Questa sezione spiega i problemi comuni di Cloud Service Mesh con le API Istio e come risolverli. Per ulteriore assistenza, consulta Assistenza.

In Cloud Service Mesh, l'autorità di certificazione Cloud Service Mesh o Istiod emette certificati per i carichi di lavoro su tutti i cluster del mesh. Autenticazione (ad esempio mTLS) e I criteri di autorizzazione (ad esempio Consenti/Nega) vengono inviati a ciascun cluster. Questi criteri determinano quali carichi di lavoro possono comunicare e come.

Problemi di TLS

Le seguenti sezioni 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 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

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 riceve.

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

In alternativa, utilizza openssl sul file collaterale 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 il CN del certificato radice contiene istio_v1_cloud_workload_root-signer-.... Se utilizzi Istiod come autorità di certificazione, verifica che il certificato radice sia impostato con O = <var>YOUR_TRUST_DOMAIN</var>.

Errori TLS `bad certificate` nei log 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 nel 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 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).
Verifica la presenza del bundle CA:

Nota: se hai installato più di un piano di controllo, specifica una revisione specifica.
```
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 è 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 sono in modo corretto, come nell'esempio seguente:

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

"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 di Istiod non dispone dell'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 impostato correttamente le credenziali e le autorizzazioni. Verifica quindi che sia presente l'associazione IAM utilizzando il comando seguente. Nella 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"
```
Verifica che le regole RBAC siano installate correttamente.
Se le regole RBAC non sono presenti, esegui nuovamente asmcli install per ricrearle.
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. Verifica inoltre che il deployment Istio sia utilizzando l'account di servizio specificato.

`serverca` errori di processo nei log Istiod