Habilita Istio CNI para el complemento de malla de servicio basado en Istio para Azure Kubernetes Service

En este artículo se muestra cómo habilitar Istio CNI para el complemento de malla de servicio basado en Istio en Azure Kubernetes Service (AKS). Istio CNI mejora la seguridad mediante la eliminación de la necesidad de funcionalidades de red con privilegios en las cargas de trabajo de aplicación dentro de la malla de servicio.

Información general

Istio redirige el tráfico de la aplicación al proxy sidecar de Envoy mediante uno de los dos mecanismos:

  • Istio CNI (CNIChaining): un complemento de CNI de nivel de clúster configura la redirección del tráfico, por lo que los pods de aplicación no necesitan funcionalidades de red con privilegios. El contenedor de inicialización istio-validation se añade durante la inyección del sidecar para verificar que la redirección del tráfico esté configurada correctamente.
  • Contenedores de inicialización (InitContainers): cada pod de aplicación usa un contenedor de inicialización con istio-init privilegios que requiere NET_ADMIN y NET_RAW funcionalidades para configurar el redireccionamiento del tráfico. Estas funcionalidades suelen plantear problemas de seguridad en entornos empresariales.

A partir de la revisión asm-1-30, Istio CNI es el mecanismo de redirección predeterminado para las nuevas instalaciones de malla. Para las revisiones desde asm-1-25 hasta asm-1-29, los contenedores de inicialización siguen siendo la opción predeterminada y se debe habilitar explícitamente Istio CNI. Las revisiones anteriores no admiten Istio CNI.

Istio CNI proporciona las siguientes ventajas sobre los contenedores de inicialización:

  • Mejora la seguridad: quita la necesidad de funcionalidades de red con privilegios (NET_ADMIN, NET_RAW) de las cargas de trabajo de aplicación.
  • Simplifica las directivas de seguridad de pods: los pods de aplicación solo requieren funcionalidades mínimas
  • Mantiene la funcionalidad: proporciona las mismas funcionalidades de administración del tráfico que el enfoque tradicional del contenedor de inicialización.

Nota:

Istio CNI no es un reemplazo de Azure CNI y no interferirá con las redes normales de AKS. Es un complemento independiente diseñado para controlar la configuración de redirección de tráfico de Istio en el nivel de nodo, lo que mejora la seguridad mediante la eliminación de la necesidad de contenedores de inicialización con privilegios en pods de aplicación.

Antes de empezar

  • Instale el CLI de Azure versión 2.86.0 o posterior. Puede ejecutar az --version para comprobar la versión. Para la instalación o la actualización, consulte Instalación de la CLI de Azure.

  • Debe tener un clúster de AKS con la extensión de malla de servicio basada en Istio habilitada. Si no tiene esta configuración, consulte Implementación del complemento de malla de servicio basado en Istio para Azure Kubernetes Service.

  • Asegúrese de que la malla de servicio de Istio usa la revisión asm-1-25 o posterior. Puede comprobar la revisión actual con:

    az aks show --resource-group <resource-group-name> --name <cluster-name> --query 'serviceMeshProfile.istio.revisions'
    

Establecimiento de variables de entorno

export CLUSTER=<cluster-name>
export RESOURCE_GROUP=<resource-group-name>

Habilitar Istio CNI

Habilitar Istio CNI en una nueva instalación de malla

A partir de la versión asm-1-30, CNIChaining es el mecanismo de redirección de proxy predeterminado para las nuevas instalaciones del complemento de malla de servicios. No es necesario especificar ningún parámetro adicional. Para las revisiones asm-1-25 a asm-1-29, habilite explícitamente Istio CNI especificando el parámetro --proxy-redirection-mechanism:

az aks mesh enable --resource-group ${RESOURCE_GROUP} --name ${CLUSTER} --proxy-redirection-mechanism CNIChaining

Habilitación de Istio CNI en una instalación de malla existente

Si ya tiene habilitado el add-on de malla de servicio Istio, puede cambiar a Istio CNI mediante el siguiente comando:

az aks mesh proxy-redirection-mechanism --resource-group ${RESOURCE_GROUP} --name ${CLUSTER} --mechanism CNIChaining

El asm-1-30 valor predeterminado solo se aplica a las nuevas instalaciones, por lo que actualizar una malla existente no cambia su mecanismo de redirección.

Nota:

Los pods existentes no cambiarán automáticamente al contenedor de inicialización istio-validation. Reinicie las implementaciones después de habilitar Istio CNI para que los pods detecten el cambio (por ejemplo, kubectl rollout restart deployment/<name>).

Comprobación de que Istio CNI está habilitado

Use az aks get-credentials para obtener las credenciales del clúster de AKS:

az aks get-credentials --resource-group ${RESOURCE_GROUP} --name ${CLUSTER}

Después de habilitar Istio CNI, compruebe la instalación comprobando que el DaemonSet de CNI se está ejecutando:

kubectl get daemonset -n aks-istio-system

Debería ver el daemonSet de Istio CNI en ejecución:

NAME                                      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
azure-service-mesh-istio-cni-addon-node   3         3         3       3            3           kubernetes.io/os=linux   94s

Implementación de cargas de trabajo y comprobación del comportamiento

Para comprobar la mejora de la seguridad, puede implementar la aplicación de ejemplo bookinfo y comprobar que las cargas de trabajo usan el contenedor init seguro istio-validation en lugar del contenedor con privilegios istio-init .

Implementación de una aplicación de ejemplo

En primer lugar, habilite la inyección de sidecar para el espacio de nombres predeterminado:

# Get the current Istio revision
REVISION=$(az aks show --resource-group ${RESOURCE_GROUP} --name ${CLUSTER} --query 'serviceMeshProfile.istio.revisions[0]' -o tsv)

# Label the namespace for sidecar injection
kubectl label namespace default istio.io/rev=${REVISION}

Implemente la aplicación de ejemplo bookinfo:

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.25/samples/bookinfo/platform/kube/bookinfo.yaml

Comprobación del uso seguro del contenedor de inicialización

Compruebe que los pods implementados usan el contenedor init seguro istio-validation en lugar de istio-init:

kubectl get pods -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.initContainers[0].name}{"\t"}{.spec.initContainers[0].securityContext.capabilities}{"\n"}{end}'

La salida esperada debe mostrarse istio-validation como el contenedor de inicialización con funcionalidades eliminadas:

details-v1-799dc5d847-7x9gl     istio-validation        {"drop":["ALL"]}
productpage-v1-99d6d698f-89gpj  istio-validation        {"drop":["ALL"]}
ratings-v1-7545c4bb6c-m7t42     istio-validation        {"drop":["ALL"]}
reviews-v1-8679d76d6c-jz4vg     istio-validation        {"drop":["ALL"]}
reviews-v2-5b9c77895c-b2b7m     istio-validation        {"drop":["ALL"]}
reviews-v3-5b57874f5f-kk9rt     istio-validation        {"drop":["ALL"]}

También puede comprobar el CÓDIGO YAML de un pod específico para comprobar el contexto de seguridad:

kubectl get pod <pod-name> -n <namespace> -o yaml | grep -A 20 -B 25 "name: istio-validation"

La salida debe mostrar que el istio-validation contenedor de inicialización no tiene funcionalidades con privilegios:

initContainers:
  - args:
    …
    name: istio-validation
    …
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - ALL
      privileged: false
      readOnlyRootFilesystem: true
      runAsGroup: 1337
      runAsNonRoot: true
      runAsUser: 1337

Deshabilitar Istio CNI

Para deshabilitar Istio CNI y volver al uso de contenedores de inicialización tradicionales, use el siguiente comando:

az aks mesh proxy-redirection-mechanism --resource-group ${RESOURCE_GROUP} --name ${CLUSTER} --mechanism InitContainers

Después de deshabilitar Istio CNI:

  1. El DaemonSet de CNI se quitará:

    kubectl get daemonset azure-service-mesh-istio-cni-addon-node -n aks-istio-system
    

    Salida esperada (sin el DaemonSet de CNI):

    Error from server (NotFound): daemonsets.apps "azure-service-mesh-istio-cni-addon-node" not found
    
  2. Las nuevas cargas de trabajo usarán el contenedor de inicialización tradicional istio-init con funcionalidades de red. Reinicie todas las implementaciones existentes para aplicar el cambio:

    kubectl rollout restart deployment/details-v1
    kubectl rollout restart deployment/productpage-v1
    kubectl rollout restart deployment/ratings-v1
    kubectl rollout restart deployment/reviews-v1
    kubectl rollout restart deployment/reviews-v2
    kubectl rollout restart deployment/reviews-v3
    
  3. Compruebe el nombre y las funcionalidades del contenedor de inicialización:

    kubectl get pods -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.initContainers[0].name}{"\t"}{.spec.initContainers[0].securityContext.capabilities}{"\n"}{end}'
    

    La salida esperada debe mostrarse istio-init con funcionalidades de red:

    details-v1-57bc58c559-722v8     istio-init        {"add":["NET_ADMIN","NET_RAW"],"drop":["ALL"]}
    productpage-v1-7bb64f657c-jw6gs istio-init        {"add":["NET_ADMIN","NET_RAW"],"drop":["ALL"]}
    ratings-v1-57d5594c75-4zd49     istio-init        {"add":["NET_ADMIN","NET_RAW"],"drop":["ALL"]}
    reviews-v1-7fd8f9cd59-mdcf9     istio-init        {"add":["NET_ADMIN","NET_RAW"],"drop":["ALL"]}
    reviews-v2-7b8bdc9cdf-k9qgb     istio-init        {"add":["NET_ADMIN","NET_RAW"],"drop":["ALL"]}
    reviews-v3-588854d9d7-s2f7j     istio-init        {"add":["NET_ADMIN","NET_RAW"],"drop":["ALL"]}
    

Pasos siguientes