Anthos Service Mesh 1.9 ha raggiunto la fine del ciclo di vita e non è più supportato. Vedi Upgrade da versioni precedenti.

Visualizza la documentazione più recente o seleziona un'altra versione disponibile:

Versioni disponibili

1.20 (ultima versione)
1.19
1.18
1.17
1.16
1.15
1.14
1.13
1.12
1.11
1.10
1.9
1.8
1.7
1.6
1.5
1.4

Risolvere i 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 Ricevere assistenza.

In Anthos Service Mesh, Mesh CA o Istiod rilascia certificati per i carichi di lavoro in tutti i cluster nel mesh. L'autenticazione (ad esempio mTLS) e i criteri di autorizzazione (ad esempio, allow/deny) vengono inviati a ogni 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 contesto nel file di configurazione predefinito di Kubernetes che utilizzi per accedere al cluster. Imposta la variabile ${CTX} come nell'esempio seguente:

export CTX=gke_PROJECT_ID_CLUSTER_LOCATION_CLUSTER_NAME

Verifica l'applicazione forzata di TLS

Verifica che le richieste in testo normale 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 richiesta in testo normale riportata sopra non dovrebbe riuscire, con 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 eseguire questa operazione, procedi nel seguente modo:

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 dei 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 CA mesh, verifica che il certificato radice di CN contenga istio_v1_cloud_workload_root-signer-.... Se utilizzi Istio come autorità di certificazione, verifica che il certificato radice sia impostato su O = <var>YOUR_TRUST_DOMAIN</var>.

Errori di TLS `bad certificate` nei log Istiod

Se vedi errori bad certificate di handshake TLS nei log, è possibile che Istiod 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.

In genere questi errori sono informativi e temporanei. Se però persistono, potrebbero esserci problemi nel tuo sistema.

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

Il webhook injector sidecar (utilizzato per l'inserimento automatico di file collaterali) richiede un bundle CA per stabilire connessioni sicure con il server API e Istiod. Questo bundle CA ha una patch applicata alla configurazione da istiod, ma a volte può essere sovrascritto (ad esempio, se applichi di nuovo la configurazione del 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 manca, riavvia istiod per eseguire nuovamente la scansione del webhook e reinstallare il bundle CA.

Logging dei criteri di autorizzazione

Il criterio di autorizzazione rifiuta una richiesta se non è consentita dal criterio. Per i protocolli HTTP (incluso gRPC), la richiesta verrà rifiutata con codice di stato 403. Per i protocolli non HTTP, la connessione verrà interrotta direttamente. Per ulteriori informazioni sui criteri di autorizzazione, consulta la pagina relativa all'autorizzazione IBM.

Il log degli accessi a Observability di Google Cloud include le informazioni necessarie quando la richiesta viene rifiutata dal criterio di autorizzazione, il che può essere utile in alcune situazioni. Ad esempio, il log indica il numero di richieste rifiutate dal criterio di autorizzazione, il che può aiutarti a determinare quale regola del criterio ha causato il rifiuto e quale i rifiuti dell'applicazione di backend.

Il log degli accessi di osservabilità di Google Cloud include le seguenti etichette per il rifiuto delle autorizzazioni.

response_details: viene impostata su AuthzDenied se il rifiuto è causato dal criterio di autorizzazione.
policy_name: includerà lo spazio dei nomi e il nome del criterio di autorizzazione DENY che causa il rifiuto. Il valore è nel formato <Namespace>.<Name>, ad esempio foo.deny-method-get indica un criterio di autorizzazione deny-method-get nello spazio dei nomi foo.
policy_rule: include l'indice della regola all'interno del criterio di autorizzazione che causa il rifiuto, ad esempio 0 indica la prima regola all'interno del criterio.

Per maggiori informazioni su come ottenere il log degli accessi, consulta Accesso ai log in Cloud Logging.

I criteri di autorizzazione non vengono applicati

Se noti sintomi della 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 vengono applicati correttamente, come segue:

RBAC: access denied

Se confermi che i criteri di autorizzazione non vengono applicati in modo forzato, 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

Errore "customresourcedefinitions.apiextensions.k8s.io is forbidden" 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 espressione regolare /error.*cannot list resource/ per trovare questi errori nei log.

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

Controlla se manca un'associazione IAM nel tuo account. Innanzitutto, assicurati di aver impostato correttamente le credenziali e le autorizzazioni. Quindi, verifica che l'associazione IAM sia presente utilizzando il comando seguente. 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 mancano le regole RBAC, esegui nuovamente istioctl install (o il metodo di installazione utilizzato per installare Anthos Service Mesh) per ricrearle.
Se le regole RBAC sono presenti e gli errori persistono, verifica che ClusterRoleBindings e RoleBindings colleghino le regole RBAC all'account di servizio Kubernetes corretto. Inoltre, verifica che il deployment istiod utilizzi l'account di servizio specificato.

`serverca` errore di processo nei log Istiod