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:
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
oasm-managed-rapid
).Ejecuta el siguiente comando para ver el configmap:
kubectl get configmap istio-release-channel -n istio-system -o yaml
Para verificar que el registro de acceso esté habilitado, asegúrate de que la línea
accessLogFile: /dev/stdout
aparezca en la secciónmesh:
.... apiVersion: v1 data: mesh: | .... accessLogFile: /dev/stdout ...
Habilitar seguimiento de nube
Ejecuta los siguientes comandos para habilitar Cloud Trace:
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
oasm-managed-rapid
).Ejecuta el siguiente comando para ver el configmap:
kubectl get configmap istio-release-channel -n istio-system -o yaml
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:{} ...
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
.
La siguiente configuración configura
outboundTrafficPolicy
enREGISTRY_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
oasm-managed-rapid
).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
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 conREGISTRY_ONLY
, asegúrate de que aparezcan las siguientes líneas en la secciónmesh:
.... 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.
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