O Anthos Service Mesh 1.10 chegou ao fim da vida útil e não é mais compatível. Consulte Como fazer upgrade de versões anteriores.

Veja uma mais recente ou selecione outra versão disponível:

Versões disponíveis

Como resolver problemas de segurança no Anthos Service Mesh

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

No Anthos 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 Anthos 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:

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

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

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.

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).
Verifique a presença do pacote de CA:
```
kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io istio-sidecar-injector -o=jsonpath='{.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

A política de autorização negará uma solicitação se ela não for permitida pela política. Para protocolos HTTP (incluindo gRPC), a solicitação será negada com o código de status 403. Em protocolos não HTTP, a conexão será encerrada diretamente. Para mais informações sobre políticas de autorização, consulte Autorização do Istio.

O registro de acesso de observabilidade do Google Cloud inclui informações necessárias quando a solicitação é negada pela política de autorização, o que pode ser útil em algumas situações. Por exemplo, o registro indica quantas solicitações foram negadas pela política de autorização, o que pode ajudar a determinar qual regra de política causou a negação versus as negações do aplicativo de back-end.

O registro de acesso de observabilidade do Google Cloud inclui os rótulos a seguir para a negação de autorização.

response_details será definido como AuthzDenied se a negação for causada pela política de autorização.
policy_name incluirá o namespace e o nome da política de autorização DENY que causa a negação. O valor está no formato <Namespace>.<Name>. Por exemplo, foo.deny-method-get significa uma política de autorização deny-method-get no namespace foo.
policy_rule incluirá o índice da regra dentro da política de autorização que causa a negação. Por exemplo, 0 significa a primeira regra dentro da política.

Para mais informações sobre como conseguir o registro de acesso, consulte Como acessar registros no Cloud Logging.

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.

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"
```
Verifique se as regras do RBAC estão instaladas corretamente.
Se as regras do RBAC não estiverem presentes, execute novamente o istioctl install (ou o método de instalação usado para instalar o Anthos Service Mesh) para recriá-las.
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