Endurecimiento / reducción de la superficie de ataque para un contenedor Docker

Me gustaría configurar una instancia de Docker reforzada, principalmente para ejecutar microservicios como las aplicaciones de Golang compiladas estáticamente. Lo que estoy buscando es proteger el sistema operativo host de un contenedor malicioso y contenedores entre sí. Intenté resumir la situación con el siguiente escenario.

Scenario:

Tenemos un servidor con un sistema operativo mínimo, como alpine linux (sistema operativo basado en busybox), con SElinux y grsec instalados, activados y configurados correctamente.

En este servidor se ejecuta una instancia de Docker con 2 contenedores en ejecución, A y B y un volumen V.

El contenedor A contiene una aplicación compilada estáticamente sin dependencias, conectada a la red pública de Internet (aplicación web o API pública). Esta aplicación contiene un ENORME error, algo así como la ejecución de código arbitrario / carga / shell inverso completo, peor se puede imaginar. Este contenedor también está conectado en red al volumen V como destino de carga, base de datos, etc.

El sistema operativo host contiene una bandera que solo se puede leer cuando se trata de una raíz (impuesta por SElinux).

El contenedor B también contiene una bandera y una aplicación, pero no hay conexión con el mundo exterior.

Attacker:

• Humano, conoce el gran error en la aplicación.
• Él quiere conseguir las banderas. Los datos en V no son importantes.
• No es una agencia de espías, pero sigue siendo un especialista en seguridad de alto grado.
• Es posible que tengamos acceso a algunos días cero de los que no tenemos conocimiento.

Asunciones:

• El kernel de Linux tiene errores pero grsec es suficiente para cubrir eso. No puede ser un vector de ataque a menos que Grsec esté desactivado
• Grsec y SElinux no tienen errores y no están mal configurados.
• Una raíz de usuario en el contenedor es una raíz fuera del contenedor (quizás algún día esto ya no sea cierto ...)
• Docker es un Docker del mundo real. No hay errores conocidos, pero ha sido afectado por errores en el pasado y podría volver a ocurrir.
• Un sistema de registro para futuras investigaciones ya está configurado correctamente.

Goz :

• Protege las banderas. Probablemente no sea posible ya que asumimos que Docker tiene errores.
• Reducir la superficie de ataque.
• Haz que la vida del atacante sea difícil.
• Establece una alarma que se dispare si el atacante intenta obtener las banderas. Preferiblemente antes de que logre conseguirlos.

Preguntas :

• ¿Qué tan realistas son mis suposiciones?
• ¿Cómo lograrías esos objetivos?
• ¿Cómo son mis bienes las siguientes sugerencias?
• ¿Algún consejo de seguridad general para Docker?

Mis sugerencias:

• Configure SElinux como ningún usuario puede escribir en A, y ningún usuario puede ejecutar archivos en V.

• Utilice una imagen Docker extremadamente mínima, sin ningún país de usuario. Algo como:

  FROM scratch
  COPY app /
  ENTRYPOINT ["/app"]
  

• Disminuye los privilegios antes de ejecutar la aplicación (No estoy seguro de cuál es la forma correcta de hacerlo ...)

• ¿Una tierra de usuarios falsa de busybox? Algo que activaría una alarma si intentamos llamar a /bin/sh , /bin/ls o algo así.