Está a ver a documentação da malha de serviço v1.21.

Versões disponíveis

Cloud Service Mesh
Arquivo 1.24
Arquivo 1.23
Arquivo 1.22
Arquivo 1.21
Arquivo 1.20
Arquivo 1.19
Arquivo 1.18

Esta página foi traduzida pela API Cloud Translation.

Resolver problemas de segurança na Cloud Service Mesh

Esta secção explica problemas comuns da API Cloud Service Mesh com Istio e como resolvê-los. Se precisar de assistência adicional, consulte a secção Receber apoio técnico.

No Cloud Service Mesh, a autoridade de certificação do Cloud Service Mesh ou o Istiod emite certificados para cargas de trabalho em todos os clusters na malha. As políticas de autenticação (por exemplo, mTLS) e de autorização (por exemplo, permitir/negar) são enviadas para cada cluster. Estas políticas determinam que cargas de trabalho podem comunicar e como.

Problemas de TLS

As secções seguintes explicam como resolver problemas relacionados com o TLS no Cloud Service Mesh.

Os exemplos nesta secção usam a variável ${CTX}, que é o nome do contexto no ficheiro de configuração do Kubernetes predefinido que usa para aceder ao cluster. Defina a variável ${CTX} como no seguinte exemplo:

export CTX=gke_PROJECT_ID_CLUSTER_LOCATION_CLUSTER_NAME

Valide a aplicação da TLS

Verifique se os pedidos de texto simples não são permitidos para um serviço quando o serviço requer ligações TLS:

kubectl exec SOURCE_POD -n SOURCE_NAMESPACE -c \
    SOURCE_CONTAINER -- curl -v DESTINATION_URL

Partindo do princípio de que o serviço requer ligações TLS, o pedido de texto simples anterior deve falhar, o que resulta numa saída semelhante à seguinte:

curl: (56) Recv failure: Connection reset by peer command terminated with exit code 56

Verifique os certificados mTLS

Quando o mTLS está ativado, verifique o certificado mTLS da carga de trabalho visualizando o cabeçalho X-Forwarded-Client-Cert. Para tal, siga estes passos:

Implemente o serviço de exemplo httpbin, que pode apresentar os cabeçalhos que recebe.

Use curl para ver o cabeçalho 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

O cabeçalho X-Forwarded-Client-Cert mostra as informações dos certificados mTLS, como no exemplo seguinte:

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

Em alternativa, use openssl no sidecar para ver toda a cadeia de certificados:
```
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
```
O resultado apresenta a cadeia de certificados. Se estiver a usar a AC de malha, verifique se o CN do certificado de raiz contém istio_v1_cloud_workload_root-signer-.... Se estiver a usar o Istiod como autoridade de certificação, verifique se o certificado raiz está definido com O = <var>YOUR_TRUST_DOMAIN</var>.

Erros de TLS `bad certificate` nos registos do Istiod

Se vir erros de handshake TLS bad certificate nos registos, pode indicar que o Istiod não está a conseguir estabelecer uma ligação TLS a um serviço.

Pode usar a string de expressão regular TLS handshake error.*bad certificate para encontrar estes erros nos registos.

Normalmente, estes erros são informativos e temporários. No entanto, se persistirem, podem indicar um problema no seu sistema.

Verifique se o seu istio-sidecar-injector MutatingWebhookConfiguration tem um pacote de AC.

O webhook do injetor de sidecar (que é usado para a injeção automática de sidecar) requer um pacote de AC para estabelecer ligações seguras com o servidor da API e o Istiod. Este pacote de AC é corrigido na configuração pelo istiod, mas pode por vezes ser substituído (por exemplo, se reaplicar a configuração do webhook).
Verifique a presença do pacote de AC:

Nota: se tiver instalado mais do que um plano de controlo, especifique uma revisão específica.
```
kubectl get mutatingwebhookconfiguration -l app=sidecar-injector -o=jsonpath='{.items[0].webhooks[0].clientConfig.caBundle}'
```
Se o resultado não estiver vazio, o pacote de AC está configurado. Se o pacote de AC estiver em falta, reinicie o istiod para que volte a analisar o webhook e reinstale o pacote de AC.

Registo de negação da política de autorização

Para obter informações sobre o registo de recusas da política de autorização, consulte o artigo Registo de recusas.

As políticas de autorização não são aplicadas

Se observar sintomas de não aplicação das políticas de autorização, use o comando seguinte para as validar:

kubectl exec --context=${CTX} -it SOURCE_POD -n SOURCE_NAMESPACE \
    -c SOURCE_CONTAINER -- curl DESTINATION_URL

Na saída, as mensagens access denied indicam que as políticas de autorização são aplicadas corretamente, como as seguintes:

RBAC: access denied

Se confirmar que as políticas de autorização não são aplicadas, negue o acesso ao espaço de nomes. O exemplo seguinte nega o acesso ao espaço de nomes denominado 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

Erro "customresourcedefinitions.apiextensions.k8s.io is forbidden" nos registos do Istiod

Pode ver erros semelhantes aos seguintes:

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

Pode usar a string de expressão regular /error.*cannot list resource/ para encontrar estes erros nos registos.

Este erro pode ocorrer quando a implementação do Istiod não tem a associação de IAM correta ou tem autorizações de RBAC insuficientes para ler um recurso personalizado.

Verifique se lhe falta uma associação do IAM na sua conta. Primeiro, certifique-se de que definiu corretamente as credenciais e as autorizações. Em seguida, verifique se a associação de IAM está presente através do seguinte comando. Neste exemplo, PROJECT_ID é o resultado de gcloud config get-value project e PROJECT_NUMBER é o resultado de 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"
```
Verifique se as regras de RBAC estão instaladas corretamente.
Se as regras de RBAC estiverem em falta, volte a executar o comando asmcli install para as recriar.
Se as regras de RBAC estiverem presentes e os erros persistirem, verifique se o ClusterRoleBindings e o RoleBindings estão a anexar as regras de RBAC à conta de serviço do Kubernetes correta. Além disso, verifique se a implementação do istiod está a usar a conta de serviço especificada.

`serverca` erros de processo nos registos do Istiod