Habilita funciones opcionales en Anthos Service Mesh administrado

En esta página, se describe cómo habilitar las funciones opcionales en un plano de control de Anthos Service Mesh administrado. Para obtener información sobre el plano de control del clúster, consulta Habilita funciones opcionales en el plano de control del clúster.

Cuando aprovisionas Anthos Service Mesh administrado, las funciones que se habilitan de forma predeterminada difieren según la plataforma. Si actualmente usas una configuración basada en IstioOperator, la herramienta Migrate from IstioOperator puede ayudarte a convertir a la configuración compatible con el plano de control administrado.

Registros de acceso de Envoy

Ejecuta los siguientes comandos para habilitar el registro de acceso de Envoy:

Advertencia: Puedes reemplazar tus propios cambios. Si ya tienes un mapa de configuración existente, debes incluir todos los parámetros de configuración de personalización anteriores dentro de la sección mesh: para conservar los cambios. Esto garantiza que no haya tiempo de inactividad cuando se habilitan las funciones opcionales.

1. Ejecuta el siguiente comando para agregar accessLogFile: /dev/stdout:

   cat <<EOF | kubectl apply -f -
   apiVersion: v1
   data:
     mesh: |-
       accessLogFile: /dev/stdout
   kind: ConfigMap
   metadata:
     name: istio-release-channel
     namespace: istio-system
   EOF
   

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

2. Ejecuta el siguiente comando para ver el configmap:

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

3. Para verificar que el registro de acceso esté habilitado, asegúrate de que la línea accessLogFile: /dev/stdout aparezca en la sección mesh:.

   ...
   apiVersion: v1
   data:
     mesh: |
       ....
       accessLogFile: /dev/stdout
   ...
   

Habilitar seguimiento de nube

Ejecuta los siguientes comandos para habilitar Cloud Trace:

Advertencia: Puedes reemplazar tus propios cambios. Si ya tienes un mapa de configuración existente, debes incluir todas las opciones de configuración anteriores de personalización en la sección mesh: para preservar tus cambios.

1. Ejecuta el siguiente comando:

   cat <<EOF | kubectl apply -f -
   apiVersion: v1
   data:
     mesh: |-
       defaultConfig:
         tracing:
           stackdriver: {}
   kind: ConfigMap
   metadata:
     name: istio-release-channel
     namespace: istio-system
   EOF
   

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

2. Ejecuta el siguiente comando para ver el configmap:

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

3. Para verificar que Cloud Trace esté habilitado, asegúrate de que aparezcan las siguientes líneas en la sección mesh:.

   ...
   apiVersion: v1
   data:
     mesh: |
       ....
       defaultConfig:
         tracing:
           stackdriver:{}
   ...
   

4. Reinicia los proxies.

   Ten en cuenta que, actualmente, la configuración del rastreador es parte de la configuración de arranque del proxy, por lo que cada pod debe reiniciarse y volver a insertarse para recoger la actualización del rastreador. Por ejemplo, puedes usar el siguiente comando para reiniciar los Pods que pertenecen a una implementación:

   kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

Para obtener más información sobre los encabezados de seguimiento admitidos, consulta Cómo acceder a los seguimientos.

Imagen de proxy distroless

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.

En la siguiente configuración, se habilitan las imágenes distroless para toda Anthos 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

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. Si necesitas acceso a estas herramientas para una implementación específica, puedes anular imageType con la siguiente anotación de Pod.

sidecar.istio.io/proxyImageType: debug

Después de cambiar el tipo de imagen de una implementación a través de la anotación, la implementación debe reiniciarse.

kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

Para la mayoría de los tipos de depuración de proxy, se debe usar istioctl proxy-cmd, que no requiere una imagen base de depuración.

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. Si deseas controlar y restringir el tráfico únicamente a los servicios externos para los cuales están definidas las entradas de servicio, puedes cambiar el comportamiento predeterminado de ALLOW_ANY a REGISTRY_ONLY.

Advertencia: Puedes reemplazar tus propios cambios. Si ya tienes un mapa de configuración existente, debes incluir todas las opciones de configuración anteriores de personalización en la sección mesh: para preservar tus cambios.

1. La siguiente configuración configura 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 anteriores necesarios 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 aparezcan las siguientes líneas 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 Anthos Service Mesh para la autenticación del usuario final 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 Anthos Service Mesh.

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

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. Si quieres obtener más información para configurar 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 para cargas de trabajo de Istio.

Advertencia: La guía de Istio vinculada en el párrafo anterior usa IstioOperator, que no es compatible con Anthos Service Mesh administrado. Debes convertir IstioOperator en un ConfigMap equivalente, como en el siguiente ejemplo.

En el siguiente ejemplo, se muestra un ConfigMap que configura 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