Questa pagina è stata tradotta dall'API Cloud Translation.

Risolvere i problemi di sicurezza in Anthos Service Mesh

Questa sezione spiega i problemi comuni di Anthos Service Mesh e come risolverli. Se hai bisogno di ulteriore assistenza, vedi la sezione Richiedere assistenza.

In Anthos Service Mesh, CA CA o Istio applica i certificati ai carichi di lavoro in tutti i cluster nel mesh. I criteri di autorizzazione (mTLS ad esempio) e di autorizzazione (ad esempio Consenti/Nega) vengono sottoposti a push a ciascun cluster. Questi criteri determinano quali carichi di lavoro possono comunicare e come.

Problemi relativi a TLS

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

Gli esempi in questa sezione utilizzano la variabile ${CTX}, che è il nome del contesto nel file di configurazione di 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 solo 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

Presumendo che il servizio richieda connessioni TLS, la richiesta di testo normale riportata sopra 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 che riceve.

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

In alternativa, utilizza openssl sul 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 l'autorità di certificazione Mesh, verifica che il CN 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 su O = <var>YOUR_TRUST_DOMAIN</var>.

Errori `bad certificate` TLS nei log Istio

Se vedi errori di handshake bad certificate nei log, è possibile che Istio 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 temporanei e temporanei. Tuttavia, se persistono, potrebbero indicare un problema del sistema.

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

Il webhook iniettore sidecar (utilizzato per l'iniezione automatica sidecar) richiede un bundle CA per stabilire connessioni sicure con il server API e Istiod. Questo bundle CA viene applicato alla configurazione da parte di istiod, ma a volte può essere sovrascritto (ad esempio, se riapplichi la configurazione del webhook).
Verifica la presenza del bundle CA:

Nota: se hai installato più piani 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 manca, riavvia istiod per fare in modo che esegua nuovamente la scansione del webhook e reinstalla il bundle CA.

Log di rifiuto dei criteri di autorizzazione

Per informazioni sul logging dei rifiuti in base ai criteri di autorizzazione, vedi denial logging.

Criteri di autorizzazione non applicati

Se riscontri sintomi di violazione 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

Errore "customresourceDefinitionss.apiextensions.k8s.io forbidden" nei log 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 dispone dell'associazione IAM corretta o quando non dispone di autorizzazioni RBAC insufficienti per leggere una risorsa personalizzata.

Controlla se nel tuo account manca un'associazione IAM. Innanzitutto, assicurati di aver impostato credenziali e autorizzazioni correttamente. 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"
```
Verifica che le regole RBAC siano installate correttamente.
Se le regole RBAC non sono presenti, esegui nuovamente asmcli install per ricrearle.
Se sono presenti regole RBAC e gli errori persistono, verifica che ClusterRoleBindings e RoleBindings allegano le regole RBAC all'account di servizio kubernetes corretto. Inoltre, verifica che il tuo deployment sia in uso tramite l'account di servizio specificato.

`serverca` errori di processo nei log Istio