Resolver problemas de segurança na Cloud Service Mesh

Nota: este guia só suporta a Cloud Service Mesh com APIs Istio e não suporta Google Cloud APIs. Para mais informações, consulte o artigo Vista geral do 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:

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

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

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

1. 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).

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

1. 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"

2. Verifique se as regras de RBAC estão instaladas corretamente.

3. Se as regras de RBAC estiverem em falta, volte a executar o comando asmcli install para as recriar.

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

Pode ver erros semelhantes aos seguintes:

Authentication failed: Authenticator ClientCertAuthenticator at index 0 got error

Pode usar a string de expressão regular /serverca.*Authentication failed:.*JWT/ para encontrar estes erros nos registos.

Este erro pode ocorrer quando o emissor JWT está configurado incorretamente, um cliente está a usar um token expirado ou outro problema de segurança está a impedir que uma ligação seja autenticada corretamente no istiod.