Cloud Service Mesh y Traffic Director ahora son Cloud Service Mesh. Para obtener más información, consulta la información general sobre Cloud Service Mesh.

Esta página se ha traducido con Cloud Translation API.

Habilitar funciones opcionales en el plano de control gestionado

En esta página se describe cómo habilitar funciones opcionales en Cloud Service Mesh gestionado. Para obtener información sobre el plano de control en clústeres, consulta el artículo Habilitar funciones opcionales en el plano de control en clústeres.

Cuando aprovisionas Cloud Service Mesh gestionado, las funciones admitidas varían en función de la implementación del plano de control, y algunas funciones solo están disponibles a través de una lista de permitidos. Consulta las funciones admitidas para obtener más información. Si actualmente usas una configuración basada en IstioOperator, la herramienta Migrate from IstioOperator (Migrar desde IstioOperator) puede ayudarte a convertirla en la configuración compatible con el plano de control gestionado.

Imagen de proxy sin distribución

Si has incorporado directamente Cloud Service Mesh con una TRAFFIC_DIRECTOR implementación del plano de control gestionada, solo se admite el tipo de imagen sin distribución. No puedes cambiarlo.
Si tu flota usaba originalmente la implementación del plano de control ISTIOD y se migró a la implementación TRAFFIC_DIRECTOR, el tipo de imagen no se modificó durante la migración y puedes cambiarlo a distroless tú mismo.

Como práctica recomendada, solo debes incluir en el contenido de un tiempo de ejecución de contenedor los paquetes necesarios. Este enfoque mejora la seguridad y la relación señal/ruido de los escáneres de vulnerabilidades y exposiciones comunes (CVE). Istio proporciona imágenes de proxy basadas en imágenes base sin distribución.

La imagen de proxy sin distribución no contiene ningún archivo binario que no sea el 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 conectarte a un pod de carga de trabajo en ejecución y, de esta forma, inspeccionarlo y ejecutar comandos personalizados. Por ejemplo, consulta el artículo Recoger registros de Cloud Service Mesh.

La siguiente configuración habilita las imágenes sin distribución para toda la malla de servicios de Cloud. Para que se aplique un cambio de tipo de imagen, es necesario reiniciar cada pod y volver a insertarlo.

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

Puedes anular el imageType mediante la siguiente anotación de pod.

sidecar.istio.io/proxyImageType: debug

Después de cambiar el tipo de imagen de un despliegue mediante la anotación, el despliegue debe reiniciarse.

kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

Como 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 está configurado como ALLOW_ANY. En este modo, se permite todo el tráfico a cualquier servicio externo. Para controlar y restringir el tráfico únicamente a los servicios externos para los que se han definido entradas de servicio, puedes cambiar el comportamiento predeterminado de ALLOW_ANY a REGISTRY_ONLY.

La siguiente configuración define outboundTrafficPolicy como REGISTRY_ONLY:

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

donde release-channel es tu canal de lanzamiento (asm-managed, asm-managed-stable o asm-managed-rapid).

Puedes hacer los cambios de configuración necesarios en el configmap con el siguiente comando:
```
kubectl edit configmap istio-release-channel -n istio-system -o yaml
```

Ejecuta el siguiente comando para ver el configmap:

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

Para verificar que outboundTrafficPolicy está habilitado con REGISTRY_ONLY, asegúrate de que las siguientes líneas aparecen en la sección mesh:.
```
...
apiVersion: v1
data:
  mesh: |
    outboundTrafficPolicy:
     mode: REGISTRY_ONLY
...
```

Autenticación de usuarios finales

Puedes configurar la autenticación de usuarios de Cloud Service Mesh gestionado para la autenticación de usuarios finales basada en navegador y el control de acceso a tus cargas de trabajo implementadas. Para obtener más información, consulta el artículo sobre cómo configurar la autenticación de usuarios de Cloud Service Mesh.

Configurar la versión mínima de TLS para las cargas de trabajo

Si has incorporado directamente Cloud Service Mesh con una TRAFFIC_DIRECTOR implementación del plano de control, no podrás cambiar este ajuste.

Puedes usar el campo minProtocolVersion para especificar la versión mínima de TLS de las conexiones TLS entre tus cargas de trabajo. Para obtener más información sobre cómo definir la versión mínima de TLS y comprobar 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 ConfigMap que define la versión mínima de TLS para las cargas de trabajo como 1.3:

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