Estás viendo la documentación de Service Mesh v1.22.

Versiones disponibles

Cloud Service Mesh
Archivo 1.22
Archivo 1.21
Archivo 1.20
Archivo 1.19
Archivo 1.18

Se usó la API de Cloud Translation para traducir esta página.

Resuelve problemas de seguridad en Cloud Service Mesh

En esta sección, se explican los problemas comunes de Cloud Service Mesh con las APIs de Istio y cómo resolverlos. Si necesitas asistencia adicional, consulta Obtén asistencia.

En Cloud Service Mesh, la AC de Cloud Service Mesh o Istiod emite certificados para las cargas de trabajo en todos los clústeres de la malla. Las políticas de autenticación (por ejemplo, mTLS) y de autorización (por ejemplo, permitir/rechazar) se envían a cada clúster. Estas políticas determinan qué cargas de trabajo se pueden comunicar y cómo.

Problemas con TLS

En las siguientes secciones, se explica cómo resolver problemas relacionados con TLS en la malla de servicios en la nube.

En los ejemplos de esta sección, se usa la variable ${CTX}, que es el contexto en la archivo de configuración predeterminado de Kubernetes que usas para acceder al clúster. Configura la variable ${CTX} como se muestra en el siguiente ejemplo:

export CTX=gke_PROJECT_ID_CLUSTER_LOCATION_CLUSTER_NAME

Verifica la aplicación de TLS

Verifica que las solicitudes de texto sin formato no estén permitidas para un servicio cuando este requiera conexiones TLS:

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

Si suponemos que el servicio requiere conexiones TLS, la solicitud de texto sin formato anterior debería fallar, lo que generará un resultado similar al siguiente:

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

Revisa certificados mTLS

Cuando mTLS esté habilitado, verifica el certificado mTLS de la carga de trabajo mediante la visualización del encabezado X-Forwarded-Client-Cert. Para ello, haz lo siguiente:

Implementa el servicio de muestra httpbin, que puede mostrar los encabezados que recibe.

Usa curl para ver el encabezado 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

El encabezado X-Forwarded-Client-Cert muestra la información de los certificados mTLS, como en el siguiente ejemplo:

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

También puedes usar openssl en el sidecar para ver toda la cadena 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
```
El resultado mostrará la cadena de certificados. Si usas la CA de la malla, verifica que el certificado raíz CN contenga istio_v1_cloud_workload_root-signer-.... Si usas Istio como autoridad certificadora, verifica que el certificado raíz esté configurado con O = <var>YOUR_TRUST_DOMAIN</var>.

Errores `bad certificate` de TLS en los registros de Istio

Si ves errores bad certificate de protocolo de enlace TLS en los registros, puede indicar que Istio no pudo establecer una conexión TLS a un servicio.

Puedes usar la string de expresión regular TLS handshake error.*bad certificate para encontrar estos errores en los registros.

Por lo general, estos errores son informativos y transitorios. Sin embargo, si persisten, pueden indicar un problema en tu sistema.

Verifica que tu istio-sidecar-injector MutatingWebhookConfiguration tenga un paquete de CA.

El webhook de inyector de sidecar (que se usa para la inserción automática de sidecar) requiere un paquete de CA a fin de establecer conexiones seguras con Istiod y el servidor de la API. Istiod emparcha este paquete de CA, pero, a veces, se puede reemplazar (por ejemplo, si vuelves a aplicar la configuración de webhook).
Verifica la presencia del paquete de CA:

Nota: Si instalaste más de un plano de control, especifica una revisión en particular.
```
kubectl get mutatingwebhookconfiguration -l app=sidecar-injector -o=jsonpath='{.items[0].webhooks[0].clientConfig.caBundle}'
```
Si el resultado no está vacío, el paquete de CA está configurado. Si falta el paquete de CA, reinicia istiod para que vuelva a analizar el webhook y reinstale el paquete de CA.

Registro de denegación de la política de autorización

Para obtener información sobre el registro de denegación de la política de autorización, consulta Registro de denegación.

No se aplican las políticas de autorización

Si observas síntomas de políticas de autorización que no se aplican, usa el siguiente comando para verificarlas:

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

En el resultado, los mensajes access denied indican que las políticas de autorización se aplican correctamente, como se muestra a continuación:

RBAC: access denied

Si confirmas que las políticas de autorización no se aplican, deniega el acceso al espacio de nombres. En el siguiente ejemplo, se deniega el acceso al espacio de nombres llamado 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

Error “customresourcedefinitions.apiextensions.k8s.io is forbidden” en los registros de Istio

Es posible que veas errores similares a los siguientes:

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

Puedes usar la string de expresión regular /error.*cannot list resource/ para encontrar estos errores en los registros.

Este error puede ocurrir cuando tu implementación de Istio no tiene la vinculación de IAM correcta o no tiene los permisos de RBAC suficientes para leer un recurso personalizado.

Verifica si te falta una vinculación de IAM en tu cuenta. Primero, asegúrate de configurar credenciales y permisos de forma correcta. Luego, verifica que la vinculación de IAM esté presente con el siguiente comando. En este ejemplo, PROJECT_ID es el resultado de gcloud config get-value project y PROJECT_NUMBER es el 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"
```
Verifica que tus reglas de RBAC estén instaladas correctamente.
Si faltan las reglas de RBAC, vuelve a ejecutar asmcli install para volver a crearlas.
Si las reglas de RBAC están presentes y los errores persisten, verifica que ClusterRoleBindings y RoleBindings las adjunten a la cuenta de servicio de Kubernetes correcta. Además, verifica que tu implementación de istiod use la cuenta de servicio especificada.

Errores de proceso `serverca` en los registros de Istiod