nicholasjackson/cnitchContainer Snitch verifica los procesos en ejecución bajo el motor Docker y alerta si se encuentra alguno ejecutándose como root.
cnitch (snitch o container snitch) es un framework simple y una herramienta de línea de comandos para monitorear contenedores Docker con el fin de identificar cualquier proceso que se esté ejecutando como root.
¿Por qué es malo esto? Si aún no has visitado ¿Puedo tener contenedores no privilegiados? por mhausenblas, te recomiendo que vayas ahora mismo para obtener toda la información.
Cuando estaba desarrollando cnitch, me encontré con lo que pensé que era un error en la aplicación; cnitch se reportaba a sí mismo como un proceso root en un contenedor Docker. No sabía cómo podía ser esto, ya que el Dockerfile indicaba explícitamente que estaba creando un usuario que no se ejecutaba como root. Después de mucho depurar y verificar, decidí revisar el Dockerfile y encontré esto:
FROM alpine
RUN adduser -h /home/cnitch -D cnitch cnitch
COPY ./cmd/cnitch /home/cnitch/
RUN chmod +x /home/cnitch/cnitch
#USER cnitch
ENTRYPOINT ["/home/cnitch/cnitch"]
Cuando estaba probando el contenedor de la aplicación para solucionar un problema de permisos con el socket de Docker, debí haber comentado el comando USER. Bastante meta: cnitch ayudó a encontrar un problema en cnitch; esto va directo a las pruebas de integración.
cnitch se conecta al motor de Docker usando la API y consulta los contenedores en ejecución, luego inspecciona los procesos que se ejecutan dentro de este contenedor e identifica aquellos que se ejecutan como usuario root. Cuando se encuentra un proceso root, esta información se envía a los módulos de reporte configurables, permitiendo auditar o tomar acciones sobre esta información.
2017/07/29 16:04:27 Starting Cnitch: Monitoring Docker Processes at: tcp://172.16.255.128:2376
2017/07/29 16:04:27 Checking for root processes every: 10s
2017/07/29 16:05:08 Checking image: ubuntu, id: 7bd489560a310343c39186500daa680290289c27f7a730524a31355a3aaf0430
2017/07/29 16:05:08 >> WARNING: found process running as root: tail -f /dev/null pid: 365
Actualmente cnitch tiene la capacidad de reportar a StatsD y StdOut. Los backends de reporte son extensibles para facilitar la compatibilidad con cualquier backend; por ejemplo, sería un proceso bastante trivial construir un backend para soportar Logstash u otra herramienta de agregación de archivos de registro.
Las excepciones se envían al endpoint de statsD como un conteo usando la métrica cnitch.exception.root_process. Las métricas también están etiquetadas con el nombre del host de la instancia de cnitch y el nombre del container.
El registrador StdOut es un registrador de salida simple que envía las excepciones reportadas a StdOut.
Ya sea que ejecutes cnitch en un contenedor Docker o como binario, necesita acceso a la API de Docker configurando la URL del servidor o la ruta al socket mediante la variable de entorno DOCKER_HOST.
--hostname=[hostname] el nombre o dirección IP que se usará para la agregación de métricas--statsd-server=[hostname:port] la URI del recolector statsd; si se omite, el reporte statsd se deshabilitará--check=[duración, ej. 10s (10 segundos), 1m (1 minuto)], la frecuencia con la que snitch escaneará en busca de procesos rootEstablece la variable de entorno DOCKER_HOST a tu API del motor Docker y luego ejecuta snitch con los flags necesarios.
$ cnitch --hostname=myhost --statsd-server=127.0.0.1:8125 --check=10s
cnitch se ejecuta en un contenedor no privilegiado y, si deseas usar el socket de Docker para acceder a la API, debes agregar el usuario cnitch al grupo docker. Esto se puede lograr mediante el flag --group-add, configurándolo con el ID de grupo para el grupo de usuarios de docker.
Por ejemplo:
--group-add=$(stat -f "%g" /var/run/docker.sock
Ejemplo usando el archivo del socket de Docker para acceso a la API
$ docker run -i -t --rm \
-v /var/run/docker.sock:/var/run/docker.sock \
--group-add=$(stat -f "%g" /var/run/docker.sock) \
-e "DOCKER_HOST:unix:///var/run/docker.sock" \
quay.io/nicholasjackson/cnitch [options]
Si estás ejecutando en un Mac y usando Docker Machine, el socket de Docker está dentro de la VM, por lo que no puedes usar el comando stat para descubrir el ID de grupo.
Hay un stack de ejemplo de Docker Compose dentro de la carpeta ./example que muestra cómo cnitch exporta datos a statsd. Para ejecutar este ejemplo:
$ cd ./example
$ docker-compose up
Una vez que todo se haya iniciado, abre http://[docker host ip]:3000 en tu navegador web y deberías ver la pantalla de inicio de sesión de Grafana.
Inicia sesión en Grafana con las siguientes credenciales:
Luego selecciona el panel de cnitch. Este panel muestra los procesos root actualmente en ejecución.
Si no estás usando /var/run/docker.sock para comunicarte con tu host Docker, deberás cambiar algunas configuraciones dentro del archivo ./example/docker-compose.yml para que coincidan con tu configuración.
Implementar características del Script de Seguridad de Docker Bench https://github.com/docker/docker-bench-security
[ ] 1.1 Asegurar que se haya creado una partición separada para los contenedores
[ ] 1.2 Asegurar que el host del contenedor esté endurecido
[ ] 1.3 Asegurar que Docker esté actualizado
[ ] 1.4 Asegurar que solo usuarios de confianza puedan controlar el daemon Docker
[ ] 1.5 Asegurar que la auditoría esté configurada para el daemon Docker
[ ] 1.6 Asegurar que la auditoría esté configurada para archivos y directorios de Docker - /var/lib/docker
[ ] 1.7 Asegurar que la auditoría esté configurada para archivos y directorios de Docker - /etc/docker
[ ] 1.8 Asegurar que la auditoría esté configurada para archivos y directorios de Docker - docker.service
[ ] 1.9 Asegurar que la auditoría esté configurada para archivos y directorios de Docker - docker.socket
[ ] 1.10 Asegurar que la auditoría esté configurada para archivos y directorios de Docker - /etc/default/docker
[ ] 1.11 Asegurar que la auditoría esté configurada para archivos y directorios de Docker - /etc/docker/daemon.json
[ ] 1.12 Asegurar que la auditoría esté configurada para archivos y directorios de Docker - /usr/bin/docker-containerd
[ ] 1.13 Asegurar que la auditoría esté configurada para archivos y directorios de Docker - /usr/bin/docker-runc
[ ] 2.1 Asegurar que el tráfico de red esté restringido entre contenedores en el puente por defecto
[ ] 2.2 Asegurar que el nivel de registro esté configurado como 'info'
[ ] 2.3 Asegurar que Docker pueda realizar cambios en iptables
[ ] 2.4 Asegurar que no se usen registros inseguros
[ ] 2.5 Asegurar que no se use el controlador de almacenamiento aufs
[ ] 2.6 Asegurar que la autenticación TLS para el daemon Docker esté configurada
[ ] 2.7 Asegurar que el ulimit por defecto esté configurado adecuadamente
[ ] 2.8 Habilitar el soporte de espacios de nombres de usuario
[ ] 2.9 Asegurar que el uso del cgroup por defecto haya sido confirmado
[ ] 2.10 Asegurar que el tamaño del dispositivo base no se cambie hasta que sea necesario
[ ] 2.11 Asegurar que la autorización para comandos del cliente Docker esté habilitada
[ ] 2.12 Asegurar que el registro centralizado y remoto esté configurado
[ ] 2.13 Asegurar que las operaciones en el registro legacy (v1) estén deshabilitadas
[ ] 2.14 Asegurar que la restauración en vivo esté habilitada
[ ] 2.15 Asegurar que el proxy de espacio de usuario esté deshabilitado
[ ] 2.16 Asegurar que se aplique un perfil seccomp personalizado a nivel de daemon, si es necesario
[ ] 2.17 Asegurar que las características experimentales se eviten en producción
[ ] 2.18 Asegurar que los contenedores tengan restringida la adquisición de nuevos privilegios
[ ] 3.x ...
[x] 4.1 Asegurar que se haya creado un usuario para el contenedor
[ ] 4.2 Asegurar que los contenedores usen imágenes base de confianza
[ ] 4.3 Asegurar que no se instalen paquetes innecesarios en el contenedor
[ ] 4.4 Asegurar que las imágenes se escaneen y reconstruyan para incluir parches de seguridad
[ ] 4.5 Asegurar que la confianza de contenido para Docker esté habilitada
[ ] 4.6 Asegurar que se hayan agregado instrucciones HEALTHCHECK a la imagen del contenedor
[ ] 4.7 Asegurar que las instrucciones de actualización no se usen solas en el Dockerfile
[ ] 4.8 Asegurar que los permisos setuid y setgid se eliminen en las imágenes
[ ] 4.9 Asegurar que se use COPY en lugar de ADD en el Dockerfile
[ ] 4.10 Asegurar que los secretos no se almacenen en los Dockerfiles
[ ] 4.11 Asegurar que solo se instalen paquetes verificados
[ ] 5.x ...
[ ] 6.x ...
[ ] 7.x ...