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

Se usó la API de Cloud Translation para traducir esta página.

Habilita funciones opcionales en el plano de control administrado

En esta página, se describe cómo habilitar funciones opcionales en la malla de servicios en la nube. Para obtener información sobre el plano de control en el clúster, consulta Habilita funciones opcionales en el plano de control en el clúster.

Cuando aprovisionas Cloud Service Mesh administrado, las funciones compatibles difieren según la implementación del plano de control, y ciertas funciones solo disponibles en la lista de entidades permitidas. Consulta funciones compatibles para obtener más detalles. Si actualmente usas una configuración basada en IstioOperator, la La herramienta Migrate from IstioOperator puede ayudarte. convertirla en la configuración que admite el plano de control administrado.

Imagen de proxy distroless

Si te incorporaste directamente a Cloud Service Mesh con un TRAFFIC_DIRECTOR administrado implementación del plano de control, solo se admite el tipo de imagen Distrolas. No se puede cambiar.
Si tu flota originalmente usó la implementación del plano de control de ISTIOD y estaba se migró a la implementación de TRAFFIC_DIRECTOR, no se modificó tu tipo de imagen durante la migración y puedes cambiar el tipo de imagen para que se desroles.

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 un shell ni usar curl, ping ni otro de depuración dentro del contenedor. Sin embargo, puedes usar contenedores efímeros conectarse a un Pod de carga de trabajo en ejecución para poder inspeccionarlo y ejecutar con comandos de SQL sencillos. Por ejemplo, consulta Recopila registros de Cloud Service Mesh.

La siguiente configuración habilita las imágenes de distrol para toda la malla de servicios de Cloud. 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 el 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 con la anotación, la la implementación.

kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

Debido a 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, todas el tráfico a cualquier servicio externo. Para controlar y restringir el tráfico solo a los servicios externos para los que entradas de servicio puedes cambiar el comportamiento predeterminado de ALLOW_ANY a REGISTRY_ONLY

La siguiente configuración establece el 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).

Puedes hacer los cambios de configuración previos necesarios en el mapa de configuración 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 del usuario final

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

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

Si te incorporaste directamente a Cloud Service Mesh con un TRAFFIC_DIRECTOR administrado implementación del plano de control, no podrás cambiar esta 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. Más información sobre el parámetro de configuración 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 para cargas de trabajo de Istio.

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

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