Resolver problemas de seguridad en Cloud Service Mesh

Nota: Esta guía solo admite Cloud Service Mesh con APIs de Istio y no admite APIs de Google Cloud . Para obtener más información, consulta la descripción general de Cloud Service Mesh.

En esta sección se explican los problemas habituales de Cloud Service Mesh con las APIs de Istio y cómo resolverlos. Si necesitas más ayuda, consulta el artículo Obtener asistencia.

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

Problemas de TLS

En las siguientes secciones se explica cómo resolver problemas relacionados con TLS en Cloud 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. Define la variable ${CTX} como en el siguiente ejemplo:

export CTX=gke_PROJECT_ID_CLUSTER_LOCATION_CLUSTER_NAME

Verificar la implementación obligatoria de TLS

Verifica que no se permitan solicitudes de texto sin cifrar para un servicio cuando el servicio requiera conexiones TLS:

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

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

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

Comprobar certificados mTLS

Cuando mTLS esté habilitado, comprueba el certificado mTLS de la carga de trabajo consultando el encabezado X-Forwarded-Client-Cert. Para ello, sigue estos pasos:

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

2. 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 de 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

3. También puedes usar openssl en el panel acoplable 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 una AC de malla, comprueba que el CN del certificado raíz contenga istio_v1_cloud_workload_root-signer-.... Si usas Istiod como autoridad de certificación, comprueba que el certificado raíz esté configurado con O = <var>YOUR_TRUST_DOMAIN</var>.

Errores de TLS bad certificate en los registros de Istiod

Si ves errores de handshake TLS bad certificate en los registros, puede indicar que Istiod no puede establecer una conexión TLS con un servicio.

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

Estos errores suelen ser informativos y temporales. Sin embargo, si persisten, puede que indiquen que hay un problema en tu sistema.

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

   El webhook del inyector de sidecar (que se usa para la inyección automática de sidecar) requiere un paquete de CA para establecer conexiones seguras con el servidor de la API e Istiod. istiod aplica este paquete de CA a la configuración, pero a veces se puede sobrescribir (por ejemplo, si vuelves a aplicar la configuración del webhook).

2. Verifica la presencia del paquete de CA:

   Nota: Si has instalado más de un plano de control, especifica una revisión concreta.

   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 denegaciones de la política de autorización

Para obtener información sobre el registro de denegaciones de políticas de autorización, consulta Registro de denegaciones.

No se aplican las políticas de autorización

Si observas síntomas de que no se aplican las políticas de autorización, 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 en el siguiente ejemplo:

RBAC: access denied

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

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 cadena de expresión regular /error.*cannot list resource/ para encontrar estos errores en los registros.

Este error puede producirse cuando tu implementación de Istiod no tiene el enlace de gestión de identidades y accesos correcto o no tiene suficientes permisos de control de acceso basado en roles para leer un recurso personalizado.

1. Comprueba si falta un enlace de gestión de identidades y accesos en tu cuenta. Primero, asegúrate de haber configurado correctamente las credenciales y los permisos. A continuación, comprueba que el enlace 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"

2. Comprueba que las reglas de RBAC estén instaladas correctamente.

3. Si faltan las reglas de RBAC, vuelve a ejecutar asmcli install para volver a crearlas.

4. Si las reglas de RBAC están presentes y los errores persisten, comprueba que ClusterRoleBindings y RoleBindings adjunten las reglas de RBAC a la cuenta de servicio de Kubernetes correcta. Además, comprueba que tu implementación de istiod esté usando la cuenta de servicio especificada.

serverca errores de proceso en los registros de Istiod

Es posible que veas errores similares a los siguientes:

Authentication failed: Authenticator ClientCertAuthenticator at index 0 got error

Puedes usar la cadena de expresión regular /serverca.*Authentication failed:.*JWT/ para encontrar estos errores en los registros.

Este error puede producirse cuando el emisor de JWT está mal configurado, cuando un cliente usa un token caducado o cuando algún otro problema de seguridad impide que una conexión se autentique correctamente en istiod.

Actualizaciones lentas del certificado y la clave privada de TLS de Ingress Gateway

Si tu clúster usa la TRAFFIC_DIRECTOR implementación del plano de control y tu gateway de entrada usa una implementación sin credenciales montadas, las actualizaciones de las credenciales pueden tardar hasta 60 minutos.

Para que el nuevo certificado entre en vigor inmediatamente, puedes reiniciar los pods de la pasarela de entrada o seguir las instrucciones para optimizar la implementación.