Preguntas frecuentes sobre seguridad

Puede cambiar la configuración de TLS mutuo para sus servicios en cualquier momento utilizando la política de autenticación y la regla de destino. Consulte la tarea para obtener más detalles.

La política de autenticación puede ser mesh-wide (lo que afecta a todos los servicios de la malla), namespace-wide (todos los servicios del mismo namespace) o específicamente del servicio. Puede tener una o varias políticas para configurar TLS mutuo para los servicios de un cluster de la forma que desee.

Si instaló Istio con values.global.proxy.privileged=true, puede usar tcpdump para determinar el estado del cifrado. También en Kubernetes 1.23 y versiones posteriores, como alternativa a la instalación de Istio como privilegiado, puede usar kubectl debug para ejecutar tcpdump en un contenedor efímero. Consulte Migración de TLS mutuo de Istio para obtener instrucciones.

Cuando TLS mutuo STRICT está habilitado, los workloads que no son de Istio no pueden comunicarse con los servicios de Istio, ya que no tendrán un certificado de cliente de Istio válido.

Si necesita permitir estos clientes, el modo TLS mutuo se puede configurar en PERMISSIVE, lo que permite tanto texto sin formato como TLS mutuo. Esto se puede hacer para workloads individuales o para toda la malla.

Consulte Política de autenticación para obtener más detalles.

Si TLS mutuo está habilitado, las comprobaciones de estado HTTP y TCP del kubelet no funcionarán sin modificaciones, ya que el kubelet no tiene certificados emitidos por Istio.

Hay varias opciones:

1. Usar la reescritura de sondeo para redirigir las solicitudes de liveness y readiness a la workload directamente. Consulte Reescritura de sondeo para obtener más información. Esto está habilitado de forma predeterminada y se recomienda.

2. Usar un puerto separado para las comprobaciones de estado y habilitar TLS mutuo solo en el puerto de servicio normal. Consulte Comprobación de estado de los servicios de Istio para obtener más información.

3. Usar el modo PERMISSIVE para el workload, para que pueda aceptar tanto tráfico de texto sin formato como de TLS mutuo. Tenga en cuenta que TLS mutuo no se aplica con esta opción.

Para los workloads que se ejecutan en Kubernetes, el tiempo de vida de sus certificados de Istio es, de forma predeterminada, de 24 horas.

Esta configuración se puede anular personalizando el campo proxyMetadata de la configuración del proxy. Por ejemplo:

proxyMetadata:
  SECRET_TTL: 48h

No. Cuando se utiliza traffic.sidecar.istio.io/excludeInboundPorts en los workloads del servidor, Istio sigue configurando el Envoy del cliente para que envíe TLS mutuo de forma predeterminada. Para cambiar eso, debe configurar una regla de destino con el modo TLS mutuo establecido en DISABLE para que los clientes envíen texto sin formato a esos puertos.

Es posible que MySQL no se pueda conectar después de instalar Istio. Esto se debe a que MySQL es un protocolo primero del servidor, lo que puede interferir con la detección de protocolos de Istio. En particular, el uso del modo mTLS PERMISSIVE puede causar problemas. Es posible que vea mensajes de error como ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0.

Esto se puede solucionar asegurándose de que se utilice el modo STRICT o DISABLE, o de que todos los clientes estén configurados para enviar mTLS. Consulte protocolos primero del servidor para obtener más información.

Sí. Istio proporciona funciones de autorización tanto para servicios HTTP como para servicios TCP sin formato en la malla. Más información.

Siguiendo las instrucciones de la tarea Asegurar el tráfico de entrada, la entrada de Istio se puede proteger para que solo acepte tráfico TLS.

Sí, puedes. Funciona tanto con TLS mutuo habilitado como deshabilitado.