Seguridad de Istio
¿Qué es Seguridad de Istio?
Seguridad de IstioConjunto de funciones de seguridad de la malla Istio: identidad de workload vía SPIFFE, TLS mutuo automático y AuthorizationPolicy/RequestAuthentication para control de acceso fino.
La Seguridad de Istio es el subsistema de seguridad de la malla Istio. El control plane (istiod) emite identidades X.509 basadas en SPIFFE para cada workload y configura los sidecars Envoy para establecer TLS mutuo entre pods, eliminando el tráfico este-oeste en claro. Las políticas PeerAuthentication aplican mTLS STRICT o PERMISSIVE a nivel de namespace o workload. AuthorizationPolicy ofrece reglas allow/deny sobre identidades de origen, hosts, rutas, métodos y condiciones; RequestAuthentication valida JWT contra emisores. Los riesgos operativos incluyen el modo PERMISSIVE mal configurado que permite tráfico en claro, políticas demasiado permisivas y CVEs de istiod sin parchear (como CVE-2024-3727). La buena práctica combina mTLS STRICT, AuthorizationPolicy default-deny y auditoría de cambios.
● Ejemplos
- 01
PeerAuthentication mtls.mode=STRICT en el namespace prod para exigir mTLS en todos los pods.
- 02
AuthorizationPolicy que deniega por defecto y permite reviews-service llamar a ratings-service.
● Preguntas frecuentes
¿Qué es Seguridad de Istio?
Conjunto de funciones de seguridad de la malla Istio: identidad de workload vía SPIFFE, TLS mutuo automático y AuthorizationPolicy/RequestAuthentication para control de acceso fino. Pertenece a la categoría de Seguridad en la nube en ciberseguridad.
¿Qué significa Seguridad de Istio?
Conjunto de funciones de seguridad de la malla Istio: identidad de workload vía SPIFFE, TLS mutuo automático y AuthorizationPolicy/RequestAuthentication para control de acceso fino.
¿Cómo funciona Seguridad de Istio?
La Seguridad de Istio es el subsistema de seguridad de la malla Istio. El control plane (istiod) emite identidades X.509 basadas en SPIFFE para cada workload y configura los sidecars Envoy para establecer TLS mutuo entre pods, eliminando el tráfico este-oeste en claro. Las políticas PeerAuthentication aplican mTLS STRICT o PERMISSIVE a nivel de namespace o workload. AuthorizationPolicy ofrece reglas allow/deny sobre identidades de origen, hosts, rutas, métodos y condiciones; RequestAuthentication valida JWT contra emisores. Los riesgos operativos incluyen el modo PERMISSIVE mal configurado que permite tráfico en claro, políticas demasiado permisivas y CVEs de istiod sin parchear (como CVE-2024-3727). La buena práctica combina mTLS STRICT, AuthorizationPolicy default-deny y auditoría de cambios.
¿Cómo defenderse de Seguridad de Istio?
Las defensas contra Seguridad de Istio combinan habitualmente controles técnicos y prácticas operativas, como se detalla en la definición.
¿Cuáles son otros nombres para Seguridad de Istio?
Nombres alternativos comunes: mTLS de Istio, AuthorizationPolicy de Istio.
● Términos relacionados
- cloud-security№ 1014
Seguridad de Service Mesh
Conjunto de controles de identidad, cifrado y autorización que un service mesh provee para asegurar el tráfico servicio-a-servicio en entornos cloud-native.
- cloud-security№ 1078
SPIFFE
Estándar abierto para asignar identidades criptográficas y portables a workloads usando SPIFFE IDs basados en URI y SVIDs X.509 o JWT de corta duración.
- cloud-security№ 1248
Identidad de Workload
Identidad criptográfica asignada a un servicio, contenedor o función para autenticarse ante otros sistemas sin secretos compartidos de larga duración.
- network-security№ 1262
Red Zero Trust
Arquitectura de red que nunca confía en usuarios, dispositivos o servicios por defecto y exige verificación continua basada en identidad para cada conexión.
- cloud-security№ 600
Seguridad de Kubernetes
Protección de un cluster de Kubernetes —su API server, plano de control, nodos, cargas y red— frente a configuraciones erróneas, compromisos y movimiento lateral.
● Véase también
- № 1079Runtime SPIRE