¿Cuáles son las mejores prácticas integrales a tener en cuenta al ejecutar Docker en producción?

Finalmente, está tan enamorado de Docker que desea mover sus sistemas de producción críticos para el negocio en línea con datos confidenciales de los clientes a un Docker Swarm. Algunos incluso podrían haberlo hecho. La otra organización no puede permitírselo mediante una política que prohíbe los procesos de producción que se ejecutan en modo raíz.

¿Cuál podría ser una lista de verificación de bloques de construcción a considerar para un entorno de producción de Docker? Uno no los necesita a todos, pero todos deben ser importantes para ser evaluados.

Descargo de responsabilidad: Sé que hay una política de SE para evitar "grandes listas interminables", pero creo que esta lista de verificación no puede ser muy grande ... y de todos modos infinita.

Entonces, ¿qué son estos bloques de construcción?

1. Si aún no está implementado, considere ejecutar un sistema host Linux con configuraciones de seguridad avanzadas: kernel reforzado, SELinux, etc.
2. Considere usar una pequeña imagen base de Docker, como alpine, busybox o incluso scratch, por ejemplo, comience con una imagen base vacía
3. Utilice la configuración de USUARIO que no sea root
4. Evalúe cuidadosamente para reducir aún más el conjunto ya reducido de capacidades de kernel otorgadas al contenedor
5. Considere tener solo un binario ejecutable por contenedor para iniciar su proceso, idealmente vinculado estáticamente
6. Aquellos que quieran romper su sistema para obtener un acceso de shell pueden preguntarse si descubrieron que su contenedor tiene todos los shells desactivados
7. Monte volúmenes de solo lectura donde solo sea posible

Pregunta: ¿qué más?

El host en el que se ejecutan los contenedores.

Ejecute el banco de seguridad de Docker en cada nodo que ejecute contenedores Docker https://github.com/docker/docker-bench-security

Ejecutando el siguiente comando en un nodo que ejecuta contenedores acoplables:

docker run -it --net host --pid host --cap-add audit_control \
    -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \
    -v /var/lib:/var/lib \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -v /usr/lib/systemd:/usr/lib/systemd \
    -v /etc:/etc --label docker_bench_security \
    docker/docker-bench-security

devuelve una lista de cheques:

[INFO] 1 - Host Configuration

[WARN] 1.1  - Ensure a separate partition for containers has been created

[NOTE] 4.2  - Ensure that containers use trusted base images

[PASS] 4.6  - Ensure HEALTHCHECK instructions have been added to the container image

Cita del repositorio README:

Docker Bench for Security es un script que verifica docenas de mejores prácticas comunes para implementar contenedores Docker en producción. Todas las pruebas están automatizadas y están inspiradas en el CIS Docker Community Edition Benchmark v1.1.0 .

Algunos de los problemas que informa el banco de seguridad podrían resolverse leyendo el artículo oficial de seguridad de la ventana acoplable y comparándolo con las viñetas que se definen en la pregunta, las siguientes cosas también son importantes:

• proteger el zócalo de Docker Daemon implementando SSL
• confianza de contenido usando notario y DOCKER_CONTENT_TRUSTvariable

Docker todavía está en desarrollo.

Al igual que con cualquier otro software, los errores en el desarrollo sucederán, podrían agregarse características inseguras, podría haber fallas arquitectónicas que conduzcan a violaciones de seguridad. ¡No subestimes esto! Su sistema podría estar completamente seguro hoy, pero con el parche de la próxima semana, alguien encuentra un error, escribe un exploit y, de repente, su sistema está completamente abierto.

A menos que deba hacerlo, no actualice a la última versión. Utilice la última versión bien probada en su lugar.

Docker no es virtualización

Si alguien escapa de un contenedor Docker, ese atacante está en la máquina real de inmediato. No hay una segunda puerta como la virtualización que evite una violación.

Trate un contenedor Docker como cualquier otro programa. Ejecute con los derechos de usuario más bajos posibles, bloquee todo el tráfico de red que no sea necesario, virtualice todo el host Docker si el rendimiento lo permite.

Docker no es protección

Cualquier código que se ejecute dentro de los contenedores Docker se ejecuta sin preguntas de Docker. Cualquier atacante puede simplemente instalar su software dentro del contenedor, y Docker lo ejecutaría como cualquier otro código.

Además de las cosas que mencionó en la pregunta, considere usar métricas y alertas para recibir notificaciones si alguna imagen de Docker está haciendo cosas extrañas. ¿Hay un pico repentino y continuo de CPU? ¿El programa está escaneando repentinamente los puertos de red? ¿Hay acceso sospechoso al disco? Debería recibir una notificación si algo de eso sucede. Hay muchas herramientas disponibles para medir estas cosas, debe usarlas.

Imágenes de Docker en sí

Una opción adicional es usar Clair .

Clair es un proyecto de código abierto para el análisis estático de vulnerabilidades en contenedores de aplicaciones (actualmente incluye appc y docker).

En intervalos regulares, Clair ingiere metadatos de vulnerabilidad de un conjunto configurado de fuentes y lo almacena en la base de datos.

Los clientes usan la API de Clair para indexar sus imágenes de contenedor; Esto crea una lista de características presentes en la imagen y las almacena en la base de datos.

Los clientes usan la API de Clair para consultar la base de datos en busca de vulnerabilidades de una imagen en particular; se correlaciona vulnerabilidades y características para cada solicitud, evitando la necesidad de volver a escanear imágenes.

Cuando se producen actualizaciones de metadatos de vulnerabilidad, se puede enviar una notificación a los sistemas de alerta de que se ha producido un cambio.

Nuestro objetivo es permitir una visión más transparente de la seguridad de la infraestructura basada en contenedores. Por lo tanto, el proyecto fue nombrado Clair por el término francés que se traduce en claro, brillante y transparente.

Además de los puntos en este hilo; La siguiente sería mi recomendación:

• Obtenga control sobre Docker PID1 con dumb-init
  • ref: PID1 y problema de cosecha de zombis
• No ejecute docker en producción sin un sistema de orquestación de contenedores
  • Elige entre Kubernetes, Mesos, Swarm, etc.
• Use gosu para el control del usuario dentro de una imagen acoplable
• Siga el paradigma de la aplicación de 12 factores, si está ejecutando aplicaciones con estado en contenedores, cámbielo.
  • Si realmente necesita ejecutar aplicaciones con estado (mysql, zookeeper, elasticsearch) en contenedores, aproveche los paradigmas del orquestador como Kubernetes Statefulsets
• Realice una sólida gestión de configuración / secreto con herramientas como hashicorp vault / consul
• Envíe el mismo contenedor construido por los desarrolladores para pinchar a través de una tubería de CI que lo lleva a través de etapas, pruebas de integración a fondo.
• Cree notificaciones alrededor de CVE y parches, active compilaciones en notificaciones de parches
• Tenga un registro extenso para obtener información sobre el contenedor en ejecución, no desea dar a los desarrolladores acceso SSH ni al host ni a los contenedores
  • recomendación: fluido
• Tener métricas de contenedor y host
  • recomendación: prometeo + exportador de nodos

Si está llenando su punto de entrada de Docker con sedcomandos, considere esta práctica:

• Use una herramienta como confd para administrar sus archivos de configuración de imágenes de Docker y mantenerlos actualizados

Confd leerá los datos de muchos almacenes de valores clave compatibles y representará las plantillas de configuración de forma dinámica.

Se podría usar A2D para hornear una aplicación en una imagen acoplable mientras se tienen en cuenta ciertas cosas, por ejemplo, permisos no root, ubicación de la aplicación:

docker run -v $PWD:/projectName utrecht/a2d:1.0.0 \
       -projectName someProjectName -dockerfile /projectName/Dockerfile

devoluciones:

FROM golang:1.12.4-alpine as builder
COPY . ./someProjectName/
WORKDIR someProjectName
RUN adduser -D -g '' someProjectName && \
    apk add git && \
    CGO_ENABLED=0 go build && \
    cp someProjectName /someProjectName && \
    chmod 100 /someProjectName

FROM scratch
COPY --from=builder /etc/group /etc/group
COPY --from=builder /etc/passwd /etc/passwd
COPY --from=builder --chown=someProjectName:someProjectName /someProjectName /usr/local/someProjectName
COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
USER someProjectName
ENTRYPOINT ["/usr/local/someProjectName"]