Habilita funciones opcionales en el plano de control administrado

Cloud Service Mesh administrado te permite habilitar funciones opcionales de la malla personalizando los recursos ConfigMap en tu clúster. Puedes configurar el endurecimiento de la seguridad, como imágenes de proxy sin distribución, restringir la salida externa con políticas de tráfico saliente y personalizar el muestreo de seguimiento mientras Google administra el mantenimiento y las actualizaciones del plano de control.

La disponibilidad de las funciones varía según la implementación del plano de control y el canal de lanzamiento. Para obtener más información, consulta Funciones compatibles con las APIs de Istio (plano de control administrado) y Habilita funciones opcionales en un plano de control en el clúster.

Imagen de proxy distroless

  • Clústeres incorporados directamente (clústeres incorporados directamente al plano de control administrado de TRAFFIC_DIRECTOR): Solo se admite el tipo de imagen distroless. No puedes cambiar esta opción. No se admite la imagen default.

  • Clústeres migrados (clústeres migrados del plano de control de ISTIOD a TRAFFIC_DIRECTOR): El tipo de imagen predeterminado es la imagen de default (que contiene archivos binarios de depuración). Puedes habilitar explícitamente las imágenes de distroless para mejorar la seguridad.

Distroless es el tipo de imagen recomendado para mejorar la seguridad. Como práctica recomendada, debes restringir el contenido de un entorno de ejecución de un contenedor solo a los paquetes necesarios. Este enfoque mejora la seguridad y la relación entre las señales y el ruido de los analizadores de vulnerabilidades y riesgos comunes (CVE). Istio proporciona imágenes de proxy basadas en imágenes base distroless.

La imagen de proxy distroless no contiene ningún objeto binario distinto del proxy. Por lo tanto, no es posible exec una shell ni usar curl, ping u otras utilidades de depuración dentro del contenedor. Sin embargo, puedes usar contenedores efímeros para adjuntarlos a un Pod de carga de trabajo en ejecución y, así, poder inspeccionarlo y ejecutar comandos personalizados. Por ejemplo, consulta Cómo recopilar registros de Cloud Service Mesh.

En la siguiente configuración, se habilitan las imágenes distroless para todo Cloud Service Mesh. Un cambio de tipo imagen requiere que cada pod se reinicie y se vuelva a insertar para que se aplique.

     apiVersion: v1
     kind: ConfigMap
     metadata:
       name: istio-release-channel
       namespace: istio-system
     data:
       mesh: |-
         defaultConfig:
           image:
             imageType: distroless

Puedes anular imageType con la siguiente anotación de Pod. Ten en cuenta que, para los clústeres con el plano de control TRAFFIC_DIRECTOR administrado, solo se admite distroless como un valor de anulación explícito (no se permiten debug ni otros tipos de imágenes que no sean distroless).

sidecar.istio.io/proxyImageType: distroless

Después de cambiar el tipo de imagen de una implementación con la anotación, la implementación debe reiniciarse. Para volver a la imagen predeterminada, quita la anotación sidecar.istio.io/proxyImageType o el campo imageType de tu MeshConfig y, luego, reinicia la implementación.

kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

Dado que no requiere una imagen base de depuración, la mayoría de los tipos de depuración de proxy deben usar gcloud beta container fleet mesh debug proxy-status / proxy-config (detalles).

Política de Tráfico Saliente

De forma predeterminada, outboundTrafficPolicy se configura como ALLOW_ANY. En este modo, se permite todo el tráfico a cualquier servicio externo. Para controlar y restringir el tráfico solo a los servicios externos para los que se definen entradas de servicio, puedes cambiar el comportamiento predeterminado de ALLOW_ANY a REGISTRY_ONLY.

  1. La siguiente configuración establece outboundTrafficPolicy en REGISTRY_ONLY:

    apiVersion: v1
kind: ConfigMap
metadata:
  name: istio-release-channel
  namespace: istio-system
data:
  mesh: |-
    outboundTrafficPolicy:
      mode: REGISTRY_ONLY

    En el ejemplo anterior, release-channel es tu canal de versiones (asm-managed, asm-managed-stable o asm-managed-rapid).

  2. Puedes realizar los cambios de configuración necesarios anteriores en el configmap con el siguiente comando:

    kubectl edit configmap istio-release-channel -n istio-system -o yaml

  3. Ejecuta el siguiente comando para ver el configmap:

    kubectl get configmap istio-release-channel -n istio-system -o yaml

  4. Para verificar que outboundTrafficPolicy esté habilitado con REGISTRY_ONLY, asegúrate de que las siguientes líneas aparezcan en la sección mesh:.

    ...
apiVersion: v1
data:
  mesh: |
    outboundTrafficPolicy:
     mode: REGISTRY_ONLY
...

Autenticación del usuario final

Puedes configurar la autenticación de usuarios administrada de Cloud Service Mesh para la autenticación de usuarios finales basada en el navegador y el control de acceso a tus cargas de trabajo implementadas. Para obtener más información, consulta Configura la autenticación de usuarios de Cloud Service Mesh.

Configura la versión mínima de TLS para tus cargas de trabajo

Si realizaste la incorporación directamente a Cloud Service Mesh con una implementación del plano de control administrada por TRAFFIC_DIRECTOR, no podrás cambiar este parámetro de configuración.

Puedes usar el campo minProtocolVersion a fin de especificar la versión mínima de TLS para las conexiones de TLS entre tus cargas de trabajo. Para obtener más información sobre cómo establecer la versión mínima de TLS y verificar la configuración de TLS de tus cargas de trabajo, consulta Configuración de la versión mínima de TLS de las cargas de trabajo de Istio.

En el siguiente ejemplo, se muestra un comando ConfigMap que establece la versión mínima de TLS para las cargas de trabajo en 1.3:

apiVersion: v1
kind: ConfigMap
metadata:
  name: istio-release-channel
  namespace: istio-system
data:
  mesh: |-
    meshMTLS:
      minProtocolVersion: TLSV1_3