chen-keinan/mesh-kridikVerificador de seguridad automatizado para clústeres de Kubernetes con Istio service mesh, que aplica mejores prácticas mediante políticas OPA y genera informes de remediación para configuraciones incorrectas.
¡Mejora la seguridad de tu malla de servicios de Kubernetes!
mesh-kridik es un verificador de seguridad de código abierto que realiza varias comprobaciones de seguridad en un clúster de Kubernetes con malla de servicios Istio y genera un informe de seguridad.
Las pruebas de comprobación de seguridad son la implementación completa de las mejores prácticas de seguridad de Istio
Las comprobaciones de seguridad se realizan en un clúster de Kubernetes con malla de servicios Istio y se apoyan en OPA (Open Policy Agent) para hacer cumplir las reglas de seguridad, y el informe de auditoría generado incluye: la causa raíz del problema de seguridad y la solución propuesta para el mismo.
git clone https://github.com/chen-keinan/mesh-kridik
cd mesh-kridik
make build
Ejecuta Mesh-Kridik sin indicadores, ejecuta todas las pruebas
./mesh-kridik
Ejecuta mesh-kridik con indicadores, ejecuta pruebas bajo demanda
Usage: mesh-kridik [--version] [--help] <command> [<args>]
Available commands are:
-r , --report : run security checks and generate remediation report
-i , --include: execute only specific security check, example -i=1.1
-e , --exclude: ignore specific security check, example -e=1.1,2.0
Ejecuta las pruebas y genera un informe de pruebas fallidas y sus soluciones
./mesh-kridik -r
Kube-kridik expone un gancho para plugins de usuario Ejemplo :
go build -buildmode=plugin -o=~/<plugin folder>/<plugin>.so ~/<plugin folder>/<plugin>.go
cp ~/<plugin folder>/<plugin>.so ~/.kube-kridik/plugins/compile/<plugin>.so
Kube-kridik soporta estas especificaciones y se puede ampliar fácilmente:
estas especificaciones se pueden ampliar fácilmente modificando los archivos de especificación en la carpeta ~/.mesh-kridik/security/mesh/istio
| Nombre | Descripción | Impacto |
|---|---|---|
| TLS mutuo | Los proxies de TLS mutuo de Istio están configurados en modo permisivo por defecto | los proxies aceptarán tanto tráfico TLS mutuo como tráfico en texto plano |
| Patrones de política de autorización más seguros de Istio | Usa patrones ALLOW con coincidencia positiva o DENY con coincidencia negativa | Estos patrones de política de autorización son más seguros porque el peor resultado en caso de desajuste de política es un rechazo 403 inesperado en lugar de una omisión de la política de autorización. |
| normalización de rutas en la política de autorización | El punto de aplicación de las políticas de autorización es el proxy Envoy en lugar del punto de acceso a recursos habitual en la aplicación backend | Un desajuste puede provocar un rechazo inesperado o una omisión de la política |
| Originación de TLS para tráfico de salida | Uso de DestinationRule en ServiceEntry para tráfico de salida | No usar originación de TLS para el tráfico de salida a un servicio externo hará que se envíe en texto plano |
| Detección de protocolo | declara explícitamente el protocolo del servicio | una detección incorrecta puede resultar en un comportamiento inesperado del tráfico |
| Soporte CNI | captura de tráfico transparente de Istio | no se capturará todo el tráfico de red |
| hosts demasiado amplios | evita configuraciones de hosts demasiado amplios en Gateway | puede causar una posible exposición de dominios inesperados |
| Restringir privilegios de creación de Gateway | restringir la creación de recursos Gateway a administradores de clúster de confianza | puede causar la creación de gateway por usuarios no confiables |
| Configurar un límite en las conexiones descendentes | Actualiza global_downstream_max_connections en el config map según el número de conexiones concurrentes necesarias por las instancias de gateway individuales en tu implementación. Una vez alcanzado el límite, Envoy comenzará a rechazar conexiones TCP | la falta de límite en el número de conexiones descendentes puede ser explotada por un actor malicioso |
| Configurar tokens de cuenta de servicio de terceros | Se recomienda configurar tokens de terceros porque las propiedades del token de primera parte son menos seguras | las propiedades del token de primera parte son menos seguras y podrían causar una brecha de autenticación |
| Plano de control | Istiod expone algunos puertos de texto plano no autenticados por conveniencia de forma predeterminada | expone el puerto del servicio XDS 15010 y el puerto de depuración 8080 sobre texto plano no autenticado |
| Plano de datos | El proxy expone una variedad de puertos | Las aplicaciones que se ejecutan en el mismo pod que el proxy tienen acceso; no hay límite de confianza entre el sidecar y la aplicación |
| Comprender las limitaciones de captura de tráfico | Asegurar el tráfico de salida configurando meshConfig.outboundTrafficPolicy.mode | el acceso a servicios externos no será controlado |