Como resolver problemas de segurança no Cloud Service Mesh

Observação: este guia só oferece suporte ao Cloud Service Mesh com APIs do Istio e não oferece suporte às APIs do Google Cloud. Para mais informações, consulte Visão geral do Cloud Service Mesh.

Esta seção explica problemas comuns do Cloud Service Mesh com APIs Istio e como resolvê-los. Se você precisar de mais ajuda, consulte Como receber suporte.

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

Problemas com o TLS

As seções a seguir explicam como resolver problemas relacionados ao TLS em do Cloud Service Mesh.

Os exemplos nesta seção usam a variável ${CTX}, que é o contexto nome no arquivo de configuração padrão do Kubernetes que você usa para acessar o cluster. Defina a variável ${CTX} como o exemplo a seguir:

export CTX=gke_PROJECT_ID_CLUSTER_LOCATION_CLUSTER_NAME

Verificar a aplicação de TLS

Verifique se as solicitações de texto simples não são permitidas para um serviço quando o serviço requer conexões TLS:

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

Supondo que o serviço exija conexões TLS, a solicitação de texto simples anterior vai falhar, resultando em uma saída semelhante a esta:

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

Verificar os certificados mTLS

Quando mTLS estiver ativado, verifique o certificado mTLS da carga de trabalho visualizando o cabeçalho X-Forwarded-Client-Cert. Para isso, siga estas etapas:

1. Implante o serviço de amostra httpbin, que pode exibir os cabeçalhos recebidos.

2. Use curl para visualizar 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 a seguir:

   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. Como alternativa, use openssl no sidecar para visualizar 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

   A saída mostrará a cadeia de certificados. Se você estiver usando o Mesh CA, verifique se o certificado raiz CN contém istio_v1_cloud_workload_root-signer-.... Se você estiver usando o Istiod como autoridade de certificação, verifique se o certificado raiz está definido com O = <var>YOUR_TRUST_DOMAIN</var>.

Erros bad certificate TLS nos registros do Istiod

Se você vir erros de handshake de TLS bad certificate nos registros, isso pode indicar que o Istiod está falhando ao estabelecer uma conexão TLS com um serviço.

Use a string de expressão regular TLS handshake error.*bad certificate para encontrar esses erros nos registros.

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

1. Verifique se o istio-sidecar-injector MutatingWebhookConfiguration tem um pacote de CA.

   O webhook do injetor de arquivo secundário (usado para injeção automática de arquivo secundário) requer um pacote de CA para estabelecer conexões seguras com o servidor de API e o Istiod. Esse pacote de CA é reparado na configuração pelo istiod, mas às vezes pode ser substituído (por exemplo, se você aplicar novamente a configuração do webhook).

2. Verifique a presença do pacote de CA:

   Observação: se você tiver instalado mais de um plano de controle, especifique uma revisão específica.

   kubectl get mutatingwebhookconfiguration -l app=sidecar-injector -o=jsonpath='{.items[0].webhooks[0].clientConfig.caBundle}'
   

   Se a saída não estiver vazia, o pacote de CA estará configurado. Se o pacote de CA estiver ausente, reinicie o istiod para que ele verifique novamente o webhook e reinstale o pacote de CA.

Geração de registros de negação da política de autorização

Saiba mais sobre a geração de registros de negação de política de autorização em Geração de registros de negação.

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

Se você observar os sintomas de políticas de autorização não aplicadas, use o comando a seguir para verificá-las:

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 a seguir:

RBAC: access denied

Se você confirmar que as políticas de autorização não são aplicadas, negue o acesso ao namespace. O exemplo a seguir nega o acesso ao namespace chamado 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 é proibido" nos registros do Istiod

Talvez você veja 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

Use a string de expressão regular /error.*cannot list resource/ para encontrar esses erros nos registros.

Esse erro pode ocorrer quando sua implantação do Istiod não tem a vinculação correta do IAM ou não tem permissões do RBAC suficientes para ler um recurso personalizado.

1. Verifique se você não tem uma vinculação do IAM na conta. Primeiro, verifique se você definiu credenciais e permissões corretamente. Em seguida, verifique se a vinculação do IAM está presente usando o comando a seguir. Neste exemplo, PROJECT_ID é a saída de gcloud config get-value project e PROJECT_NUMBER é a saída 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 do RBAC estão instaladas corretamente.

3. Se as regras do RBAC estiverem ausentes, execute novamente asmcli install para recriá-las.

4. Se as regras do RBAC estiverem presentes e os erros persistirem, verifique se o ClusterRoleBindings e o RoleBindings estão anexando as regras do RBAC à conta de serviço kubernetes correta. Além disso, verifique se a implantação do istiod usa a conta de serviço especificada.

Erros de processo serverca em registros do Istiod

Talvez você veja erros semelhantes aos seguintes:

Authentication failed: Authenticator ClientCertAuthenticator at index 0 got error

Use a string de expressão regular /serverca.*Authentication failed:.*JWT/ para encontrar esses erros nos registros.

Esse erro pode ocorrer quando o emissor JWT está mal configurado, um cliente está usando um token expirado ou algum outro problema de segurança está impedindo a conexão de uma autenticação com o istiod corretamente.