kube-tarian/tarianAgente de seguridad en tiempo de ejecución basado en eBPF para Kubernetes que detecta procesos desconocidos y cambios en archivos, aplica restricciones previamente registradas y automatiza la eliminación de pods o la generación de alertas para mitigar ransomware y otros ataques.
Protege tus aplicaciones ejecutándose en Kubernetes de ataques maliciosos pre-registrando tus procesos confiables y firmas de archivos confiables. Tarian detectará procesos desconocidos y cambios en los archivos registrados, luego enviará alertas y tomará una acción automatizada. ¡Protege tu entorno K8s de Ransomware!
Queremos mantener esto como un proyecto de código abierto para luchar contra los ataques en nuestro ecosistema favorito de Kubernetes. Con la contribución continua, podemos combatir amenazas juntos como comunidad.
¿Cómo funciona Tarian?
El Agente de Clúster de Tarian se ejecuta en el clúster de Kubernetes detectando procesos desconocidos y cambios desconocidos en archivos, los reporta al Servidor Tarian y opcionalmente toma acción: elimina el pod infractor. Utiliza eBPF para detectar nuevos procesos. Para la detección de cambios en archivos, el Agente de Clúster de Tarian inyecta un contenedor sidecar en el pod de tu aplicación principal que verificará los checksums de los archivos en la ruta configurada y los comparará con los checksums registrados en el Servidor Tarian. Tarian será parte del pod de tu aplicación desde el entorno de desarrollo hasta producción, por lo que puedes registrar en tu Base de Datos Tarian lo que se supone que debe suceder y ejecutarse en tu contenedor + las firmas de archivos a vigilar + lo que se puede notificar + la acción a tomar (autodestruir el pod) según los cambios detectados. ¡Desplaza a la izquierda tu mecanismo de detección!
¿Qué sucede si ocurre un cambio desconocido dentro del contenedor que no está en la base de datos de registro de Tarian? ¿Cómo reacciona Tarian?
Si ocurre un cambio desconocido, Tarian puede simplemente notificar los análisis observados a tu Equipo de Seguridad. Luego, tus Ingenieros de Seguridad pueden registrar ese cambio en la Base de Datos de Tarian, ya sea que se considere una amenaza o no. Además, basándose en su análisis, pueden configurar qué acción tomar cuando ese cambio vuelva a ocurrir.
¿Cómo ayuda la contribución de la comunidad a combatir las amenazas a través de Tarian?
Cualquier nueva detección analizada y marcada como amenaza por tus Expertos en Seguridad, si así lo deciden, puede compartirse en la base de datos comunitaria de código abierto de Tarian con todos los registros, cadenas a buscar, observación, transparencia, acciones a configurar, ... Básicamente, cualquier cosa que los Expertos quieran advertir y compartir con la comunidad. Puedes usar esa información como usuario de Tarian y configurar acciones en la aplicación Tarian que se utiliza en tu entorno. Este es básicamente un mecanismo para compartir información sobre amenazas y qué hacer con ellas. Esto ayuda a todos los que usan Tarian a tomar acciones juntos en sus respectivos entornos K8s compartiendo su conocimiento y experiencia.
¿Qué tipo de acción(es) tomaría Tarian basándose en una(s) amenaza(s) conocida(s)?
Tarian simplemente autodestruiría el pod en el que se está ejecutando. Si el malware/virus se propaga al resto del entorno, bueno, ya sabes lo que pasa. Por lo tanto, Tarian está diseñado básicamente para ayudar a reducir el riesgo tanto como sea posible destruyendo pods. El aprovisionamiento de un nuevo pod será manejado por el despliegue de K8s. Tarian solo destruirá los pods si le dices que lo haga. Si no deseas que ocurra ninguna acción, no tienes que configurar ni activar ninguna; simplemente puedes decirle a Tarian que solo te notifique. Tarian básicamente hace lo que quieres que se haga para reducir el riesgo.
¿Por qué otra herramienta de seguridad nueva cuando ya hay muchas herramientas disponibles, como Falco, Kube-Hunter, Kube-Bench, Calico Enterprise Security y muchas más herramientas de seguridad (de código abierto y comerciales) que pueden detectar y prevenir amenazas a nivel de red, infraestructura y aplicación? ¿Por qué Tarian?
La razón principal por la que nació Tarian es para luchar contra las amenazas en Kubernetes juntos como comunidad. Otra razón fue, ¿qué pasa si aún existe algún ataque sofisticado capaz de penetrar todas las capas de tu seguridad, capaz de alcanzar tu aplicación en tiempo de ejecución (Ejecución Remota de Código) y tus volúmenes de almacenamiento, y capaz de propagarse para dañar o bloquear tu infraestructura y datos? ¿Qué quieres hacer con tales ataques, especialmente los que se convierten en ransomware? Tarian está diseñado para reducir esos riesgos, tomando acciones. Sabemos que Tarian no es la solución definitiva, pero estamos seguros de que puede ayudar a reducir los riesgos, especialmente cuando el conocimiento se comparte continuamente por la comunidad. Desde una perspectiva técnica, Tarian puede ayudar a reducir el riesgo destruyendo los recursos infectados.
kubectl create namespace tarian-system
Puedes usar cualquier opción de instalación de Dgraph siempre que sea accesible desde el servidor tarian.
helm repo add tarian https://kube-tarian.github.io/helm-charts
helm repo update
helm upgrade -i tarian-server tarian/tarian-server --devel -n tarian-system --set server.dgraph.address=DIRECCIÓN_DGRAPH:PUERTO
helm upgrade -i tarian-cluster-agent tarian/tarian-cluster-agent --devel -n tarian-system
kubectl wait --for=condition=ready pod --all -n tarian-system
kubectl exec -ti deploy/tarian-server -n tarian-system -- ./tarian-server dgraph apply-schema
Descarga el binario tarianctl desde la página de lanzamientos de github.
Ejecuta:
tarianctl install
Puedes usar las siguientes banderas para personalizar tu instalación.
Instalar Tarian en Kubernetes.
Uso:
tarianctl install [banderas]
Banderas:
--agents-values strings Ruta al archivo de valores de helm para el Agente de Clúster Tarian y el agente de nodo.
--charts string Ruta al directorio de charts helm de tarian.
--dgraph-values strings Ruta al archivo de valores de helm para DGraph.
-h, --help ayuda para install
-n, --namespace string Namespace para instalar Tarian. (por defecto "tarian-system")
--nats-values strings Ruta al archivo de valores de helm para Nats.
--server-values strings Ruta al archivo de valores de helm para el Servidor Tarian.
Banderas Globales:
-k, --kubeconfig string ruta al archivo kubeconfig a usar
-e, --log-formatter string formateadores de registro válidos: json, text(por defecto) (por defecto "text")
-l, --log-level string niveles de registro válidos: debug, info(por defecto), warn/warning, error, fatal (por defecto "info")
-s, --server-address string dirección del servidor tarian para comunicarse (por defecto "localhost:50051")
-c, --server-tls-ca-file string archivo ca que el servidor usa para la conexión TLS
-t, --server-tls-enabled si está habilitado, se comunicará con el servidor usando TLS
-i, --server-tls-insecure-skip-verify si se establece en true, omitirá la verificación de la cadena de certificados y el nombre del host del servidor (por defecto true)
Consulta los valores del chart helm para
Un clúster GKE privado crea por defecto reglas de firewall que restringen la comunicación del maestro a los nodos solo en los puertos 443 y 10250.
Para inyectar el contenedor tarian-pod-agent, tarian utiliza un webhook de admisión mutante. El servidor webhook se ejecuta en el puerto 9443. Por lo tanto, necesitamos
crear una nueva regla de firewall para permitir el tráfico entrante desde el rango de direcciones IP del maestro a los nodos en el puerto TCP 9443.
Para más detalles, consulta la documentación de GKE sobre este tema: https://cloud.google.com/kubernetes-engine/docs/how-to/private-clusters#add_firewall_rules.
kubectl port-forward svc/tarian-server -n tarian-system 41051:80
export TARIAN_SERVER_ADDRESS=localhost:41051
tarianctl get events
tarianctl add constraint --name nginx --namespace default \
--match-labels run=nginx \
--allowed-processes=pause,tarian-pod-agent,nginx
tarianctl get constraints
tarianctl add constraint --name nginx-files --namespace default \
--match-labels run=nginx \
--allowed-file-sha256sums=/usr/share/nginx/html/index.html=38ffd4972ae513a0c79a8be4573403edcd709f0f572105362b08ff50cf6de521
tarianctl get constraints
Luego de que se creen las restricciones, inyectamos tarian-pod-agent al pod agregando una anotación:
metadata:
annotations:
pod-agent.k8s.tarian.dev/threat-scan: "true"
Un pod con esta anotación tendrá un contenedor adicional inyectado (tarian-pod-agent). El contenedor tarian-pod-agent verificará
continuamente el entorno de ejecución según las restricciones registradas. Cualquier violación será reportada, y se podrá acceder
a ella con tarianctl get events.
kubectl apply -f https://raw.githubusercontent.com/kube-tarian/tarian/main/dev/config/monitored-pod/configmap.yaml
kubectl apply -f https://raw.githubusercontent.com/kube-tarian/tarian/main/dev/config/monitored-pod/pod.yaml
# esperar a que esté listo
kubectl wait --for=condition=ready pod nginx
# simular la ejecución de un proceso desconocido
kubectl exec -ti nginx -c nginx -- sleep 15
# deberías verlo reportado en tarian
tarianctl get events
Tarian incluye Prometheus Alert Manager por defecto. Si deseas usar otra instancia de alert manager:
helm install tarian-server tarian/tarian-server --devel \
--set server.alert.alertManagerAddress=http://alertmanager.monitoring.svc:9093 \
--set alertManager.install=false \
-n tarian-system
Para deshabilitarlo, puedes establecer el valor alertManagerAddress a vacío.
Cuando tarian-pod-agent se ejecuta en modo de registro, en lugar de reportar procesos y archivos desconocidos como violaciones, los registra automáticamente como una nueva restricción. Esto es conveniente para ahorrar tiempo de registro manual.
Para habilitar el registro de restricciones, el agente de clúster debe estar configurado.
helm install tarian-cluster-agent tarian/tarian-cluster-agent --devel -n tarian-system \
--set clusterAgent.enableAddConstraint=true
metadata:
annotations:
# registrar tanto procesos como checksums de archivos
pod-agent.k8s.tarian.dev/register: "processes,files"
# ignorar rutas específicas del registro automático
pod-agent.k8s.tarian.dev/register-file-ignore-paths: "/usr/share/nginx/**/*.txt"
El registro automático de restricciones también se puede realizar en un clúster de desarrollo/staging, para que haya menos cambios en producción.
metadata:
annotations:
# especificar con qué frecuencia tarian-pod-agent debe verificar el checksum de los archivos
pod-agent.k8s.tarian.dev/file-validation-interval: "1m"
Para asegurar tarian-server con TLS, crea un secreto que contenga el certificado TLS. Puedes crear el secreto manualmente, o usando Cert Manager. Una vez que tengas el secreto, puedes pasar el nombre al valor del chart helm:
helm upgrade -i tarian-server tarian/tarian-server --devel -n tarian-system \
--set server.tlsSecretName=tarian-server-tls
Ver MAINTAINERS.md
| Entorno | Funciona | Notas |
|---|
| Kind v0.14.0 | ✔️ | |
| Minikube v1.26.0 | ✔️ | |
| Linode Kubernetes Engine (LKE) 1.22 | ✔️ | |
| Digital Ocean Kubernetes Engine (DOKS) 1.22 | ✔️ | |
| Google Kubernetes Engine (GKE) 1.22 | ✔️ | |
| Amazon Elastic Kubernetes Engine (EKS) | ➖ | kernel < 5.8 |
| Azure Kubernetes Service (AKS) | ➖ | kernel < 5.8 |