Como resolver problemas de segurança no Cloud Service Mesh

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

No Cloud Service Mesh, o Mesh CA ou o Istiod emite 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 a TLS no Cloud Service Mesh.

Os exemplos nesta seção usam a variável ${CTX}, que é o nome do contexto no arquivo de configuração padrão do Kubernetes usado 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 requer conexões TLS, a solicitação de texto simples acima falhará, resultando em saída semelhante à seguinte:

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 exec --context=${CTX} SOURCE_POD -n SOURCE_NAMESPACE -c istio-proxy \
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:

    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.