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 autoridad certificadora de Cloud Service Mesh o Istiod emite certificados para cargas de trabajo en todos los clústeres de la malla. Authentication (por ejemplo, mTLS) y Las políticas de autorización (por ejemplo, las de permiso o denegación) 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í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 encabezadoX-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 conO = <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 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 degcloud 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
yRoleBindings
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
Es posible que veas errores similares a los siguientes:
Authentication failed: Authenticator ClientCertAuthenticator at index 0 got error
Puedes usar la string de expresión regular /serverca.*Authentication failed:.*JWT/
para encontrar estos errores en los registros.
Este error puede ocurrir cuando el emisor de JWT está mal configurado, un cliente usa un token vencido o hay otro problema de seguridad que impide que una conexión se autentique en istiod correctamente.