Anthos Service Mesh 1.9 llegó al final del ciclo de vida y ya no es compatible. Consulta Actualiza desde versiones anteriores.

Consulta la documentación más reciente o selecciona otra versión disponible:

Versiones disponibles

Resuelve problemas de seguridad en Anthos Service Mesh

En esta sección, se explican los problemas comunes de Anthos Service Mesh y cómo solucionarlos. Si necesitas asistencia adicional, consulta Obtén asistencia.

En Anthos Service Mesh, la CA de la malla 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 Anthos Service Mesh.

En los ejemplos de esta sección, se usa la variable ${CTX}, que es el nombre del contexto en el 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ía 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 exec --context=${CTX} SOURCE_POD -n SOURCE_NAMESPACE -c istio-proxy \
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:
```
kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io istio-sidecar-injector -o=jsonpath='{.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

La política de autorización rechazará cualquier solicitud que no esté permitida en ella. En el caso de los protocolos HTTP (incluido gRPC), se rechazará la solicitud con el código de estado 403. Para protocolos que no sean HTTP, la conexión se finalizará directamente. Para obtener más información sobre las políticas de autorización, consulta la página Autorización de Istio.

El registro de acceso de observabilidad de Google Cloud incluye la información necesaria cuando la política de autorización rechaza la solicitud, lo que puede ser útil en algunas situaciones. Por ejemplo, el registro indica cuántas solicitudes rechazó la política de autorización, lo que puede ayudarte a determinar qué regla provocó el rechazó y que rechazos se generaron de la aplicación de backend.

El registro de acceso de observabilidad de Google Cloud incluye las siguientes etiquetas para la denegación de la autorización.

response_details: Se establecerá como AuthzDenied si la denegación se debe a la política de autorización.
policy_name: Incluirá el espacio de nombres y el nombre de la política de DENY de autorización que causa el rechazo. El valor está en el formato de <Namespace>.<Name>, por ejemplo, foo.deny-method-get representa una política de autorización deny-method-get en el espacio de nombres foo.
policy_rule: Incluirá el índice de la regla dentro de la política de autorización que causa el rechazo, por ejemplo, 0 representa la primera regla dentro de la política.

Para obtener más información sobre cómo obtener el registro de acceso, consulta Accede a registros en Cloud Logging.

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 istioctl install (o el método de instalación que usaste para instalar Anthos Service Mesh) a fin de 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