Seguridad

lectura de 26 minutos

Descomponer una aplicación monolítica en services atómicos ofrece varios beneficios, incluyendo mayor agilidad, mejor escalabilidad y mayor capacidad de reutilizar services. Sin embargo, los microservicios también tienen necesidades de seguridad particulares:

Para defenderse de ataques de intermediario, necesitan cifrado de tráfico.
Para proporcionar un control de acceso flexible a los services, necesitan mTLS y políticas de acceso de grano fino.
Para determinar quién hizo qué en qué momento, necesitan herramientas de auditoría.

Istio Security proporciona una solución de seguridad integral para resolver estos problemas. Esta página ofrece una visión general de cómo puede usar las features de seguridad de Istio para proteger sus services, dondequiera que los ejecute. En particular, la seguridad de Istio mitiga tanto las amenazas internas como externas contra sus datos, endpoints, comunicación y plataforma.

Las features de seguridad de Istio proporcionan una identidad fuerte, una política potente, cifrado TLS transparente y herramientas de autenticación, autorización y auditoría (AAA) para proteger sus services y datos. Los objetivos de la seguridad de Istio son:

Seguridad por defecto: no se necesitan cambios en el código de la aplicación y la infraestructura
Defensa en profundidad: integración con sistemas de seguridad existentes para proporcionar múltiples capas de defensa
Red de confianza cero: construcción de soluciones de seguridad en redes no confiables

Visite nuestra documentación de migración de mTLS para comenzar a usar las features de seguridad de Istio con sus services desplegados. Visite nuestras Tareas de Seguridad para obtener instrucciones detalladas sobre cómo usar las features de seguridad.

Arquitectura de alto nivel

La seguridad en Istio involucra múltiples componentes:

Una Autoridad de Certificación (CA) para la gestión de claves y certificados
El servidor API de configuración distribuye a los proxies:
Los proxies sidecar y perimetrales funcionan como Puntos de Aplicación de Políticas (PEPs) para asegurar la comunicación entre clientes y servidores.
Un conjunto de extensiones de proxy Envoy para gestionar la telemetría y la auditoría

El control plane maneja la configuración del servidor API y configura los PEP en el data plane. Los PEP se implementan usando Envoy. El siguiente diagrama muestra la arquitectura.

En las siguientes secciones, introducimos las features de seguridad de Istio en detalle.

Identidad de Istio

La identidad es un concepto fundamental de cualquier infraestructura de seguridad. Al comienzo de una comunicación workload-to-workload, las dos partes deben intercambiar credenciales con su información de identidad para fines de autenticación mutua. En el lado del cliente, la identidad del servidor se verifica con la información de nombres seguros para ver si es un ejecutor autorizado del workload. En el lado del servidor, el servidor puede determinar a qué información puede acceder el cliente basándose en las políticas de autorización, auditar quién accedió a qué en qué momento, cobrar a los clientes en función de los workloads que utilizaron y rechazar a cualquier cliente que no haya pagado su factura para acceder a los workloads.

El modelo de identidad de Istio utiliza la identidad de service de primera clase para determinar la identidad del origen de una solicitud. Este modelo permite una gran flexibilidad y granularidad para que las identidades de service representen un usuario humano, un workload individual o un grupo de workloads. En plataformas sin una identidad de service, Istio puede usar otras identidades que pueden agrupar instancias de workload, como nombres de service.

La siguiente lista muestra ejemplos de identidades de service que puede usar en diferentes plataformas:

Kubernetes: cuenta de service de Kubernetes
GCE: cuenta de service de GCP
On-premises (no Kubernetes): cuenta de usuario, cuenta de service personalizada, nombre de service, cuenta de service de Istio o cuenta de service de GCP. La cuenta de service personalizada se refiere a la cuenta de service existente al igual que las identidades que gestiona el Directorio de Identidades del cliente.

Gestión de identidad y certificados

Istio aprovisiona de forma segura identidades fuertes a cada workload con certificados X.509. Los agentes de Istio, que se ejecutan junto a cada proxy Envoy, trabajan junto con istiod para automatizar la rotación de claves y certificados a escala. El siguiente diagrama muestra el flujo de aprovisionamiento de identidad.

Istio aprovisiona claves y certificados a través del siguiente flujo:

istiod ofrece un service gRPC para tomar solicitudes de firma de certificados (CSRs).
Al iniciarse, el agente de Istio crea la clave privada y el CSR, y luego envía el CSR con sus credenciales a istiod para su firma.
La CA en istiod valida las credenciales contenidas en el CSR. Tras una validación exitosa, firma el CSR para generar el certificado.
Cuando se inicia un workload, Envoy solicita el certificado y la clave al agente de Istio en el mismo contenedor a través de la API de service de descubrimiento de secretos (SDS) de Envoy.
El agente de Istio envía los certificados recibidos de istiod y la clave privada a Envoy a través de la API SDS de Envoy.
El agente de Istio monitorea la expiración del certificado del workload. El proceso anterior se repite periódicamente para la rotación de certificados y claves.

Autenticación

Istio proporciona dos tipos de autenticación:

Autenticación de pares: utilizada para la autenticación service-to-service para verificar el cliente que realiza la conexión. Istio ofrece mTLS como una solución completa para la autenticación de transporte, que se puede habilitar sin requerir cambios en el código del service. Esta solución:
- Proporciona a cada service una identidad fuerte que representa su rol para permitir la interoperabilidad entre clusters y nubes.
- Asegura la comunicación service-to-service.
- Proporciona un sistema de gestión de claves para automatizar la generación, distribución y rotación de claves y certificados.
Autenticación de solicitudes: utilizada para la autenticación de usuario final para verificar la credencial adjunta a la solicitud. Istio habilita la autenticación a nivel de solicitud con validación de JSON Web Token (JWT) y una experiencia de desarrollador simplificada utilizando un proveedor de autenticación personalizado o cualquier proveedor de OpenID Connect, por ejemplo:

En todos los casos, Istio almacena las políticas de autenticación en el almacén de configuración de Istio a través de una API de Kubernetes personalizada. Istiod las mantiene actualizadas para cada proxy, junto con las claves cuando corresponda. Además, Istio admite la autenticación en modo permisivo para ayudarle a comprender cómo un cambio de política puede afectar su postura de seguridad antes de que se aplique.

Autenticación mTLS

Istio tuneliza la comunicación service-to-service a través de los PEP del lado del cliente y del servidor, que se implementan como proxies Envoy. Cuando un workload envía una solicitud a otro workload utilizando la autenticación mTLS, la solicitud se maneja de la siguiente manera:

Istio reenvía el tráfico saliente de un cliente al sidecar Envoy local del cliente.
El Envoy del lado del cliente inicia un handshake mTLS con el Envoy del lado del servidor. Durante el handshake, el Envoy del lado del cliente también realiza una comprobación de nombres seguros para verificar que la cuenta de service presentada en el certificado del servidor está autorizada para ejecutar el service de destino.
El Envoy del lado del cliente y el Envoy del lado del servidor establecen una conexión mTLS, e Istio reenvía el tráfico del Envoy del lado del cliente al Envoy del lado del servidor.
El Envoy del lado del servidor autoriza la solicitud. Si está autorizado, reenvía el tráfico al service de backend a través de conexiones TCP locales.

Istio configura TLSv1_2 como la versión mínima de TLS para el cliente y el servidor con las siguientes suites de cifrado:

ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
AES256-GCM-SHA384
AES128-GCM-SHA256

Modo permisivo

Istio mTLS tiene un modo permisivo, que permite que un service acepte tanto tráfico de texto plano como tráfico mTLS al mismo tiempo. Esta feature mejora en gran medida la experiencia de incorporación de mTLS.

Muchos clientes que no son de Istio que se comunican con un servidor que no es de Istio presentan un problema para un operador que desea migrar ese servidor a Istio con mTLS habilitado. Comúnmente, el operador no puede instalar un sidecar de Istio para todos los clientes al mismo tiempo o ni siquiera tiene los permisos para hacerlo en algunos clientes. Incluso después de instalar el sidecar de Istio en el servidor, el operador no puede habilitar mTLS sin romper las comunicaciones existentes.

Con el modo permisivo habilitado, el servidor acepta tanto tráfico de texto plano como mTLS. El modo proporciona mayor flexibilidad para el proceso de incorporación. El sidecar de Istio instalado en el servidor toma el tráfico mTLS inmediatamente sin romper el tráfico de texto plano existente. Como resultado, el operador puede instalar y configurar gradualmente los sidecars de Istio del cliente para enviar tráfico mTLS. Una vez que la configuración de los clientes esté completa, el operador puede configurar el servidor en modo solo mTLS. Para obtener más información, visite el tutorial de migración de mTLS.

Nombres seguros

Las identidades del servidor se codifican en certificados, pero los nombres de service se recuperan a través del service de descubrimiento o DNS. La información de nombres seguros mapea las identidades del servidor a los nombres de service. Un mapeo de identidad A a nombre de service B significa “A está autorizado para ejecutar el service B”. El control plane observa el apiserver, genera los mapeos de nombres seguros y los distribuye de forma segura a los PEP. El siguiente ejemplo explica por qué los nombres seguros son críticos en la autenticación.

Supongamos que los servidores legítimos que ejecutan el service datastore solo usan la identidad infra-team. Un usuario malicioso tiene el certificado y la clave para la identidad test-team. El usuario malicioso intenta suplantar el service para inspeccionar los datos enviados desde los clientes. El usuario malicioso despliega un servidor falsificado con el certificado y la clave para la identidad test-team. Supongamos que el usuario malicioso secuestró con éxito (a través de suplantación de DNS, secuestro de BGP/ruta, suplantación de ARP, etc.) el tráfico enviado al datastore y lo redirigió al servidor falsificado.

Cuando un cliente llama al service datastore, extrae la identidad test-team del certificado del servidor y verifica si test-team está autorizado para ejecutar datastore con la información de nombres seguros. El cliente detecta que test-team no está autorizado para ejecutar el service datastore y la autenticación falla.

Tenga en cuenta que, para el tráfico que no es HTTP/HTTPS, el nombre seguro no protege contra la suplantación de DNS, en cuyo caso el atacante modifica las IPs de destino para el service. Dado que el tráfico TCP no contiene información de Host y Envoy solo puede confiar en la IP de destino para el enrutamiento, Envoy puede enrutar el tráfico a services en las IPs secuestradas. Esta suplantación de DNS puede ocurrir incluso antes de que el Envoy del lado del cliente reciba el tráfico.

Arquitectura de autenticación

Puede especificar los requisitos de autenticación para los workloads que reciben solicitudes en una mesh de Istio utilizando políticas de autenticación de pares y de solicitudes. El operador de la mesh utiliza ficheros .yaml para especificar las políticas. Las políticas se guardan en el almacén de configuración de Istio una vez desplegadas. El controlador de Istio observa el almacén de configuración.

Ante cualquier cambio de política, la nueva política se traduce a la configuración apropiada que le indica al PEP cómo realizar los mecanismos de autenticación requeridos. El control plane puede obtener la clave pública y adjuntarla a la configuración para la validación de JWT. Alternativamente, Istiod proporciona la ruta a las claves y certificados que el sistema Istio gestiona y los instala en el pod de la aplicación para mTLS. Puede encontrar más información en la sección Gestión de identidad y certificados.

Istio envía las configuraciones a los endpoints de destino de forma asíncrona. Una vez que el proxy recibe la configuración, el nuevo requisito de autenticación surte efecto inmediatamente en ese pod.

Los services cliente, aquellos que envían solicitudes, son responsables de seguir el mecanismo de autenticación necesario. Para la autenticación de solicitudes, la aplicación es responsable de adquirir y adjuntar la credencial JWT a la solicitud. Para la autenticación de pares, Istio actualiza automáticamente todo el tráfico entre dos PEP a mTLS. Si las políticas de autenticación deshabilitan el modo mTLS, Istio continúa usando texto plano entre los PEP. Para anular este comportamiento, deshabilite explícitamente el modo mTLS con reglas de destino. Puede encontrar más información sobre cómo funciona mTLS en la sección Autenticación mTLS.

Istio genera identidades con ambos tipos de autenticación, así como otros claims en la credencial si corresponde, a la siguiente capa: autorización.

Políticas de autenticación

Esta sección proporciona más detalles sobre cómo funcionan las políticas de autenticación de Istio. Como recordará de la sección Arquitectura, las políticas de autenticación se aplican a las solicitudes que recibe un service. Para especificar reglas de autenticación del lado del cliente en mTLS, debe especificar la TLSSettings en la DestinationRule. Puede encontrar más información en nuestra documentación de referencia de configuración de TLS.

Al igual que otras configuraciones de Istio, puede especificar políticas de autenticación en ficheros .yaml. Despliega políticas usando kubectl. La siguiente política de autenticación de ejemplo especifica que la autenticación de transporte para los workloads con la etiqueta app:reviews debe usar mTLS:

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: "example-peer-policy"
  namespace: "foo"
spec:
  selector:
    matchLabels:
      app: reviews
  mtls:
    mode: STRICT
EOF

Almacenamiento de políticas

Istio almacena las políticas con alcance de mesh en el namespace raíz. Estas políticas tienen un selector vacío que se aplica a todos los workloads de la mesh. Las políticas que tienen un alcance de namespace se almacenan en el namespace correspondiente. Solo se aplican a los workloads dentro de su namespace. Si configura un campo selector, la política de autenticación solo se aplica a los workloads que coinciden con las condiciones que configuró.

Las políticas de autenticación de pares y de solicitudes se almacenan por separado por tipo, PeerAuthentication y RequestAuthentication respectivamente.

Campo selector

Las políticas de autenticación de pares y de solicitudes utilizan campos selector para especificar la etiqueta de los workloads a los que se aplica la política. El siguiente ejemplo muestra el campo selector de una política que se aplica a los workloads con la etiqueta app:product-page:

selector:
  matchLabels:
    app: product-page

Si no proporciona un valor para el campo selector, Istio hace coincidir la política con todos los workloads en el ámbito de almacenamiento de la política. Por lo tanto, los campos selector le ayudan a especificar el ámbito de las políticas:

Política a nivel de malla: una política especificada para el namespace raíz sin o con un campo selector vacío.
Política a nivel de namespace: una política especificada para un namespace no raíz sin o con un campo selector vacío.
Política específica del workload: una política definida en el namespace regular, con campo selector no vacío.

Las políticas de autenticación de pares y de solicitudes siguen los mismos principios de jerarquía para los campos selector, pero Istio los combina y aplica de formas ligeramente diferentes.

Solo puede haber una política de autenticación de pares a nivel de mesh y solo una política de autenticación de pares a nivel de namespace por namespace. Cuando configura múltiples políticas de autenticación de pares a nivel de mesh o de namespace para la misma malla o namespace, Istio ignora las políticas más nuevas. Cuando más de una política de autenticación de pares específica del workload coincide, Istio elige la más antigua.

Istio aplica la política de coincidencia más restrictiva para cada workload utilizando el siguiente orden:

específica del workload
a nivel de namespace
a nivel de malla

Istio puede combinar todas las políticas de autenticación de solicitudes coincidentes para que funcionen como si provinieran de una única política de autenticación de solicitudes. Por lo tanto, puede tener múltiples políticas de autenticación de solicitudes a nivel de mesh o de namespace en un mesh o namespace. Sin embargo, sigue siendo una buena práctica evitar tener múltiples políticas de autenticación de solicitudes a nivel de mesh o de namespace.

Autenticación de pares

Las políticas de autenticación de pares especifican el modo mTLS que Istio aplica a los workloads de destino. Se admiten los siguientes modos:

PERMISSIVE: Los workloads aceptan tanto tráfico mTLS como tráfico de texto plano. Este modo es más útil durante las migraciones cuando los workloads sin sidecar no pueden usar mTLS. Una vez que los workloads se migran con inyección de sidecar, debe cambiar el modo a ESTRICTO.
ESTRICTO: Los workloads solo aceptan tráfico mTLS.
DESHABILITAR: mTLS está deshabilitado. Desde una perspectiva de seguridad, no debe usar este modo a menos que proporcione su propia solución de seguridad.

Cuando el modo no está establecido, se hereda el modo del ámbito padre. Las políticas de autenticación de pares a nivel de mesh con un modo no establecido usan el modo PERMISSIVE por defecto.

La siguiente política de autenticación de pares requiere que todos los workloads en el namespace foo usen mTLS:

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: "example-policy"
  namespace: "foo"
spec:
  mtls:
    mode: STRICT

Con las políticas de autenticación de pares específicas del workload, puede especificar diferentes modos mTLS para diferentes puertos. Solo puede usar puertos que los workloads hayan reclamado para la configuración mTLS a nivel de puerto. El siguiente ejemplo deshabilita mTLS en el puerto 80 para el workload app:example-app, y usa la configuración mTLS de la política de autenticación de pares a nivel de namespace para todos los demás puertos:

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: "example-workload-policy"
  namespace: "foo"
spec:
  selector:
     matchLabels:
       app: example-app
  portLevelMtls:
    80:
      mode: DISABLE

La política de autenticación de pares anterior funciona solo porque la configuración del service a continuación vinculó las solicitudes del workload example-app al puerto 80 del service example-service:

apiVersion: v1
kind: Service
metadata:
  name: example-service
  namespace: foo
spec:
  ports:
  - name: http
    port: 8000
    protocol: TCP
    targetPort: 80
  selector:
    app: example-app

Autenticación de solicitudes

Las políticas de autenticación de solicitudes especifican los valores necesarios para validar un JSON Web Token (JWT). Estos valores incluyen, entre otros, los siguientes:

La ubicación del token en la solicitud
El emisor o la solicitud
El conjunto de claves públicas de JSON Web (JWKS)

Istio verifica el token presentado, si se presenta, con las reglas de la política de autenticación de solicitudes, y rechaza las solicitudes con tokens inválidos. Cuando las solicitudes no llevan token, se aceptan por defecto. Para rechazar solicitudes sin tokens, proporcione reglas de autorización que especifiquen las restricciones para operaciones específicas, por ejemplo, rutas o acciones.

Las políticas de autenticación de solicitudes pueden especificar más de un JWT si cada uno utiliza una ubicación única. Cuando más de una política coincide con un workload, Istio combina todas las reglas como si se hubieran especificado como una única política. Este comportamiento es útil para programar workloads para que acepten JWT de diferentes proveedores. Sin embargo, las solicitudes con más de un JWT válido no son compatibles porque el principal de salida de dichas solicitudes no está definido.

Principales

Cuando utiliza políticas de autenticación de pares y mTLS, Istio extrae la identidad de la autenticación de pares en source.principal. De manera similar, cuando utiliza políticas de autenticación de solicitudes, Istio asigna la identidad del JWT a request.auth.principal. Utilice estos principales para establecer políticas de autorización y como salida de telemetría.

Actualización de políticas de autenticación

Puede cambiar una política de autenticación en cualquier momento e Istio envía las nuevas políticas a los workloads casi en tiempo real. Sin embargo, Istio no puede garantizar que todos los workloads reciban la nueva política al mismo tiempo. Las siguientes recomendaciones ayudan a evitar interrupciones al actualizar sus políticas de autenticación:

Utilice políticas de autenticación de pares intermedias utilizando el modo PERMISSIVE al cambiar el modo de DISABLE a STRICT y viceversa. Cuando todos los workloads cambien con éxito al modo deseado, puede aplicar la política con el modo final. Puede usar la telemetría de Istio para verificar que los workloads hayan cambiado con éxito.
Al migrar políticas de autenticación de solicitudes de un JWT a otro, agregue la regla para el nuevo JWT a la política sin eliminar la regla antigua. Los workloads aceptarán ambos tipos de JWT, y puede eliminar la regla antigua cuando todo el tráfico cambie al nuevo JWT. Sin embargo, cada JWT debe usar una ubicación diferente.

Autorización

Las features de autorización de Istio proporcionan control de acceso a nivel de malla, namespace y workload para sus workloads en la mesh. Este nivel de control proporciona los siguientes beneficios:

Autorización de workload a workload y de usuario final a workload.
Una API simple: incluye un único CRD AuthorizationPolicy, que es fácil de usar y mantener.
Semántica flexible: los operadores pueden definir condiciones personalizadas en los atributos de Istio, y usar acciones CUSTOM, DENY y ALLOW.
Alto rendimiento: la autorización de Istio (ALLOW y DENY) se aplica de forma nativa en Envoy.
Alta compatibilidad: admite gRPC, HTTP, HTTPS y HTTP/2 de forma nativa, así como cualquier protocolo TCP simple.

Arquitectura de autorización

La política de autorización aplica el control de acceso al tráfico entrante en el proxy Envoy del lado del servidor. Cada proxy Envoy ejecuta un motor de autorización que autoriza las solicitudes en tiempo de ejecución. Cuando una solicitud llega al proxy, el motor de autorización evalúa el contexto de la solicitud con las políticas de autorización actuales y devuelve el resultado de la autorización, ya sea ALLOW o DENY. Los operadores especifican las políticas de autorización de Istio utilizando ficheros .yaml.

Habilitación implícita

No necesita habilitar explícitamente las features de autorización de Istio; están disponibles después de la instalación. Para aplicar el control de acceso a sus workloads, aplique una política de autorización.

Para los workloads sin políticas de autorización aplicadas, Istio permite todas las solicitudes.

Las políticas de autorización admiten las acciones ALLOW, DENY y CUSTOM. Puede aplicar múltiples políticas, cada una con una acción diferente, según sea necesario para asegurar el acceso a sus workloads.

Istio verifica las políticas coincidentes en capas, en este orden: CUSTOM, DENY y luego ALLOW. Para cada tipo de acción, Istio primero verifica si hay una política con la acción aplicada, y luego verifica si la solicitud coincide con la especificación de la política. Si una solicitud no coincide con una política en una de las capas, la verificación continúa a la siguiente capa.

El siguiente gráfico muestra la precedencia de las políticas en detalle:

Precedencia de la Política de Autorización

Cuando aplica múltiples políticas de autorización al mismo workload, Istio las aplica de forma aditiva.

Políticas de autorización

Para configurar una política de autorización, cree un recurso personalizado AuthorizationPolicy. Una política de autorización incluye un selector, una acción y una lista de reglas:

El campo selector especifica el destino de la política
El campo action especifica si se permite o se deniega la solicitud
Las rules especifican cuándo activar la acción
- El campo from en las rules especifica los orígenes de la solicitud
- El campo to en las rules especifica las operaciones de la solicitud
- El campo when especifica las condiciones necesarias para aplicar la regla

El siguiente ejemplo muestra una política de autorización que permite a dos orígenes, la cuenta de service cluster.local/ns/default/sa/curl y el namespace dev, acceder a los workloads con las etiquetas app: httpbin y version: v1 en el namespace foo cuando las solicitudes enviadas tienen un token JWT válido.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
 name: httpbin
 namespace: foo
spec:
 selector:
   matchLabels:
     app: httpbin
     version: v1
 action: ALLOW
 rules:
 - from:
   - source:
       principals: ["cluster.local/ns/default/sa/curl"]
   - source:
       namespaces: ["dev"]
   to:
   - operation:
       methods: ["GET"]
   when:
   - key: request.auth.claims[iss]
     values: ["https://accounts.google.com"]

El siguiente ejemplo muestra una política de autorización que deniega las solicitudes si el origen no es el namespace foo:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
 name: httpbin-deny
 namespace: foo
spec:
 selector:
   matchLabels:
     app: httpbin
     version: v1
 action: DENY
 rules:
 - from:
   - source:
       notNamespaces: ["foo"]

La política de denegación tiene precedencia sobre la política de permiso. Las solicitudes que coinciden con las políticas de permiso pueden ser denegadas si coinciden con una política de denegación. Istio evalúa las políticas de denegación primero para asegurar que una política de permiso no pueda eludir una política de denegación.

Destino de la política

Puede especificar el ámbito o destino de una política con el campo metadata/namespace y un campo selector opcional. Una política se aplica al namespace en el campo metadata/namespace. Si se establece su valor en el namespace raíz, la política se aplica a todos los namespaces de una malla. El valor del namespace raíz es configurable, y el predeterminado es istio-system. Si se establece en cualquier otro namespace, la política solo se aplica al namespace especificado.

Puede usar un campo selector para restringir aún más las políticas para que se apliquen a workloads específicos. El selector usa etiquetas para seleccionar el workload de destino. El selector contiene una lista de pares {clave: valor}, donde la clave es el nombre de la etiqueta. Si no se establece, la política de autorización se aplica a todos los workloads en el mismo namespace que la política de autorización.

Por ejemplo, la política allow-read permite el acceso "GET" y "HEAD" al workload con la etiqueta app: products en el namespace default.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-read
  namespace: default
spec:
  selector:
    matchLabels:
      app: products
  action: ALLOW
  rules:
  - to:
    - operation:
         methods: ["GET", "HEAD"]

Coincidencia de valores

La mayoría de los campos en las políticas de autorización admiten todos los siguientes esquemas de coincidencia:

Coincidencia exacta: coincidencia de cadena exacta.
Coincidencia de prefijo: una cadena que termina en "*". Por ejemplo, "test.abc.*" coincide con "test.abc.com", "test.abc.com.cn", "test.abc.org", etc.
Coincidencia de sufijo: una cadena que comienza con "*". Por ejemplo, "*.abc.com" coincide con "eng.abc.com", "test.eng.abc.com", etc.
Coincidencia de presencia: * se usa para especificar cualquier cosa excepto vacío. Para especificar que un campo debe estar presente, use el formato nombre_campo: ["*"]. Esto es diferente de dejar un campo sin especificar, lo que significa que coincide con cualquier cosa, incluido vacío.

Hay algunas excepciones. Por ejemplo, los siguientes campos solo admiten coincidencia exacta:

El campo key en la sección when
Los ipBlocks en la sección source
El campo ports en la sección to

La siguiente política de ejemplo permite el acceso a rutas con el prefijo /test/* o el sufijo */info.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: tester
  namespace: default
spec:
  selector:
    matchLabels:
      app: products
  action: ALLOW
  rules:
  - to:
    - operation:
        paths: ["/test/*", "*/info"]

Coincidencia de exclusión

Para hacer coincidir condiciones negativas como notValues en el campo when, notIpBlocks en el campo source, notPorts en el campo to, Istio admite la coincidencia de exclusión. El siguiente ejemplo requiere un principal de solicitud válido, que se deriva de la autenticación JWT, si la ruta de la solicitud no es /healthz. Por lo tanto, la política excluye las solicitudes a la ruta /healthz de la autenticación JWT:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: disable-jwt-for-healthz
  namespace: default
spec:
  selector:
    matchLabels:
      app: products
  action: ALLOW
  rules:
  - to:
    - operation:
        notPaths: ["/healthz"]
    from:
    - source:
        requestPrincipals: ["*"]

El siguiente ejemplo deniega la solicitud a la ruta /admin para solicitudes sin principales de solicitud:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: enable-jwt-for-admin
  namespace: default
spec:
  selector:
    matchLabels:
      app: products
  action: DENY
  rules:
  - to:
    - operation:
        paths: ["/admin"]
    from:
    - source:
        notRequestPrincipals: ["*"]

Política `allow-nothing`, `deny-all` y `allow-all`

El siguiente ejemplo muestra una política ALLOW que no coincide con nada. Si no hay otras políticas ALLOW, las solicitudes siempre serán denegadas debido al comportamiento de “denegar por defecto”.

Tenga en cuenta que el comportamiento de “denegar por defecto” solo se aplica si el workload tiene al menos una política de autorización con la acción ALLOW.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-nothing
spec:
  action: ALLOW
  # el campo rules no está especificado, y la política nunca coincidirá.

El siguiente ejemplo muestra una política DENY que deniega explícitamente todo el acceso. Siempre denegará la solicitud incluso si hay otra política ALLOW que permite la solicitud porque la política DENY tiene precedencia sobre la política ALLOW. Esto es útil si desea deshabilitar temporalmente todo el acceso al workload.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-all
spec:
  action: DENY
  # el campo rules tiene una regla vacía, y la política siempre coincidirá.
  rules:
  - {}

El siguiente ejemplo muestra una política ALLOW que permite el acceso completo al workload. Hará que otras políticas ALLOW sean inútiles ya que siempre permitirá la solicitud. Podría ser útil si desea exponer temporalmente el acceso completo al workload. Tenga en cuenta que la solicitud aún podría ser denegada debido a las políticas CUSTOM y DENY.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-all
spec:
  action: ALLOW
  # Esto coincide con todo.
  rules:
  - {}

Condiciones personalizadas

También puede usar la sección when para especificar condiciones adicionales. Por ejemplo, la siguiente definición de AuthorizationPolicy incluye una condición de que request.headers[version] sea "v1" o "v2". En este caso, la clave es request.headers[version], que es una entrada en el atributo de Istio request.headers, que es un mapa.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
 name: httpbin
 namespace: foo
spec:
 selector:
   matchLabels:
     app: httpbin
     version: v1
 action: ALLOW
 rules:
 - from:
   - source:
       principals: ["cluster.local/ns/default/sa/curl"]
   to:
   - operation:
       methods: ["GET"]
   when:
   - key: request.auth.claims[iss]
     values: ["https://accounts.google.com"]

Los valores key admitidos de una condición se enumeran en la página de condiciones.

Identidad autenticada y no autenticada

Si desea que un workload sea accesible públicamente, debe dejar la sección source vacía. Esto permite orígenes de todos (tanto autenticados como no autenticados) usuarios y workloads, por ejemplo:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
 name: httpbin
 namespace: foo
spec:
 selector:
   matchLabels:
     app: httpbin
     version: v1
 action: ALLOW
 rules:
 - to:
   - operation:
       methods: ["GET", "POST"]

Para permitir solo usuarios autenticados, establezca principals en "*" en su lugar, por ejemplo:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
 name: httpbin
 namespace: foo
spec:
 selector:
   matchLabels:
     app: httpbin
     version: v1
 action: ALLOW
 rules:
 - from:
   - source:
       principals: ["*"]
   to:
   - operation:
       methods: ["GET", "POST"]

Uso de la autorización de Istio en protocolos TCP simples

La autorización de Istio admite workloads que utilizan cualquier protocolo TCP simple, como MongoDB. En este caso, se configura la política de autorización de la misma manera que para los workloads HTTP. La diferencia es que ciertos campos y condiciones solo son aplicables a los workloads HTTP. Estos campos incluyen:

El campo request_principals en la sección de origen del objeto de política de autorización
Los campos hosts, methods y paths en la sección de operación del objeto de política de autorización

Las condiciones admitidas se enumeran en la página de condiciones. Si utiliza algún campo solo HTTP para un workload TCP, Istio ignorará los campos solo HTTP en la política de autorización.

Suponiendo que tiene un service MongoDB en el puerto 27017, el siguiente ejemplo configura una política de autorización para permitir que solo el service bookinfo-ratings-v2 en la mesh de Istio acceda al workload MongoDB.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: mongodb-policy
  namespace: default
spec:
 selector:
   matchLabels:
     app: mongodb
 action: ALLOW
 rules:
 - from:
   - source:
       principals: ["cluster.local/ns/default/sa/bookinfo-ratings-v2"]
   to:
   - operation:
       ports: ["27017"]

Dependencia de mTLS

Istio utiliza mTLS para pasar de forma segura cierta información del cliente al servidor. mTLS debe estar habilitado antes de utilizar cualquiera de los siguientes campos en la política de autorización:

los campos principals y notPrincipals en la sección source
los campos namespaces y notNamespaces en la sección source
la condición personalizada source.principal
la condición personalizada source.namespace

Tenga en cuenta que se recomienda encarecidamente utilizar siempre estos campos con el modo mTLS estricto en PeerAuthentication para evitar posibles rechazos de solicitudes inesperados o elusión de políticas cuando se utiliza tráfico de texto plano con el modo mTLS permisivo.

Consulte el aviso de seguridad para obtener más detalles y alternativas si no puede habilitar el modo mTLS estricto.

Más información

Después de aprender los conceptos básicos, hay más recursos para revisar:

Pruebe la política de seguridad siguiendo las tareas de autenticación y autorización.
Aprenda algunos ejemplos de políticas de seguridad que podrían utilizarse para mejorar la seguridad en su malla.
Lea problemas comunes para solucionar mejor los problemas de políticas de seguridad cuando algo sale mal.

Ver también

Autorización Externa

Muestra cómo integrar y delegar el control de acceso a un sistema de autorización externo.

Denegación Explícita

Muestra cómo configurar el control de acceso para denegar el tráfico explícitamente.

Dry Run

Shows how to dry-run an authorization policy without enforcing it.

Ingress Access Control

Shows how to set up access control on an ingress gateway.

Migración de trust domain

Muestra cómo migrar de un trust domain a otro sin cambiar la política de autorización.

Tráfico HTTP

Muestra cómo configurar el control de acceso para el tráfico HTTP.

Seguridad

Arquitectura de alto nivel

Identidad de Istio

Gestión de identidad y certificados

Autenticación

Autenticación mTLS

Modo permisivo

Nombres seguros

Arquitectura de autenticación

Políticas de autenticación

Almacenamiento de políticas

Campo selector

Autenticación de pares

Autenticación de solicitudes

Principales

Actualización de políticas de autenticación

Autorización

Arquitectura de autorización

Habilitación implícita

Políticas de autorización

Destino de la política

Coincidencia de valores

Coincidencia de exclusión

Política allow-nothing, deny-all y allow-all

Condiciones personalizadas

Identidad autenticada y no autenticada

Uso de la autorización de Istio en protocolos TCP simples

Dependencia de mTLS

Más información

Política `allow-nothing`, `deny-all` y `allow-all`