Bottlerocket - Un SO Linux mínimo e inmutable con arranque verificado
(bottlerocket.dev)- Bottlerocket es un sistema operativo basado en Linux, orientado al hospedaje de contenedores, y se usa como sistema operativo base para los nodos worker de clústeres administrados por orquestadores como Kubernetes
- Con una configuración mínima que elimina paquetes, herramientas e intérpretes de una distribución de propósito general, reduce la carga operativa y la superficie de ataque, y ofrece solo las combinaciones necesarias mediante variants según el entorno
- No incluye shell ni gestor de paquetes; el sistema se maneja mediante contenedores host privilegiados y una API, y las actualizaciones se aplican de forma atómica mediante imágenes y cambio de partición
- La configuración se administra mediante API, lo que permite migraciones entre versiones y rollback, y la gestión de actualizaciones puede hacerse manualmente o con herramientas específicas de cada orquestador
- Mediante un sistema de archivos raíz inmutable, dm-verity, SELinux restringido, y una implementación en Rust y parcialmente en Golang, reduce la manipulación del sistema y las rutas de ejecución de código no verificado
SO base para clústeres de contenedores
- Bottlerocket es un sistema operativo basado en Linux optimizado para el hospedaje de contenedores
- Es software libre y de código abierto, desarrollado públicamente en GitHub
- Se instala como sistema operativo base en las máquinas o instancias donde se ejecutan contenedores
- Está diseñado para funcionar junto con orquestadores de contenedores como Kubernetes, y soporta la automatización del ciclo de vida de los contenedores dentro del clúster
- Puede ejecutarse en la nube y en centros de datos
- Sus objetivos de diseño se resumen en tres ejes: Minimal, Safe Updates y Security Focused
Configuración mínima y variants por entorno
- Como su único objetivo es el hospedaje de contenedores, elimina muchos paquetes, herramientas, intérpretes y dependencias que vienen por defecto en las distribuciones Linux de propósito general
- Al reducir el software innecesario, también baja la sobrecarga operativa y la sobrecarga de seguridad
- Los distintos requisitos de orquestadores, plataformas y arquitecturas se gestionan mediante variants, que son builds para cada combinación compatible
- Un variant es una composición de los elementos necesarios para ejecutarse en un entorno específico
- Si se elige el variant adecuado, no se necesitan componentes adicionales para unirse al clúster
- Bottlerocket no incluye shell
- El acceso al sistema es posible mediante contenedores host privilegiados que sí cuentan con shell
- Desde el contenedor host se puede explorar el sistema operativo subyacente y cambiar la configuración del sistema en ejecución mediante la API
Actualizaciones seguras basadas en imágenes
- Bottlerocket está diseñado para poder actualizarse, pero no incluye gestor de paquetes
- Las actualizaciones se entregan como imágenes que se descargan a una partición específica
- Durante la actualización, el orquestador hace drain del nodo y luego le indica a Bottlerocket que aplique la actualización y reinicie
- Bottlerocket cambia de partición y arranca atómicamente con la nueva versión
- La configuración del sistema se administra mediante API, por lo que Bottlerocket puede encargarse de la migración de configuraciones entre versiones
- Si ocurre un problema durante la actualización, es posible volver a la versión anterior que sí funcionaba manteniendo la configuración
- La gestión de actualizaciones puede hacerse manualmente o con herramientas específicas de cada orquestador
Diseño centrado en la seguridad
- La configuración mínima y el método de actualización respaldan el diseño centrado en la seguridad de Bottlerocket
- Como los variants se entregan como imágenes, no hacen falta un registro de paquetes ni un gestor que puedan modificar el sistema y generar problemas de seguridad
- Las funciones propias de Bottlerocket están escritas en Rust y parcialmente en Golang
- Ambos son lenguajes compilados y ofrecen protecciones integradas frente a problemas de seguridad de memoria
- Todo el código se entrega en imágenes precompiladas, por lo que no se necesitan shell ni intérpretes, y se reducen las rutas de ejecución de código no verificado
- El sistema de archivos raíz es inmutable
- dm-verity proporciona verificación transparente de integridad del sistema de archivos raíz
- Si se detecta una modificación en el dispositivo de bloques subyacente, el kernel se reinicia
- Sobre los sistemas de archivos modificables se aplica una política restringida de SELinux, siempre activa y forzada
- Esta política ayuda a evitar que los contenedores ejecuten operaciones peligrosas incluso si corren como root
1 comentarios
Opiniones de Hacker News
Todavía tiene un carácter muy marcado de proyecto de AWS/Amazon, y no se ve un camino claro para que se convierta en un proyecto independiente.
Por ejemplo, si necesitas escanear vulnerabilidades del OS, puedes usar un producto de Amazon; si no, el método es poco claro https://bottlerocket.dev/en/faq/#4_2
Si piensas ejecutar Bottlerocket solo en AWS, está bien, pero si quiere ser un producto que “se ejecuta en la nube o en centros de datos”, como dice el sitio web, debe resolver este tipo de cosas.
Si quieres saber si está parcheado, basta con ver si estás ejecutando la versión más reciente; si lo estás, todos los parches disponibles ya están aplicados.
Pero en industrias reguladas esto puede ser un problema, porque hay que completar el ítem de “gestión de vulnerabilidades” en las listas de verificación de cumplimiento.
Una gran razón por la que la gestión de vulnerabilidades es necesaria en los OS tradicionales es que el espacio de configuración es muy amplio, y la configuración de software mezcla arbitrariamente varias fuentes y proveedores, con cada versión moviéndose de forma independiente.
Pero un OS para contenedores no es algo que se use así.
Encontrar vulnerabilidades adicionales en “latest” se parece más al trabajo de un investigador de seguridad que a que el dueño del sistema aplique a tiempo parches de upstream.
Es un proyecto más antiguo que Bottlerocket.
Es una pregunta sincera: si hay una forma de entrar por SSM o usar un contenedor admin para ejecutar el escaneo, ¿no se podría hacer de la misma manera?
Es algo que se puede hacer antes de desplegar la imagen en la máquina host.
Bottlerocket, a diferencia de la mayoría de las distribuciones *nix empresariales, no ofrece modo FIPS.
Si usas un programa de cumplimiento que exige criptografía aprobada por FIPS para el OS host de trabajo, mejor ahórrate el tiempo.
Por esto Bottlerocket no es una opción para nosotros, y aunque el issue relacionado lleva más de 2 años abierto y activo, el equipo de desarrollo no parece convencido de que sea importante.
También hablamos con el equipo de desarrollo a través de nuestro representante dedicado de AWS, pero no parecían tener voluntad de agregarlo.
El hilo abierto desde hace más de 2 años está aquí: https://github.com/bottlerocket-os/bottlerocket/issues/1667
El soporte FIPS sigue siendo, por mucho, la solicitud número 1 de los clientes.
Pero no es un buen momento para una distribución nueva que no tiene historial previo de ofrecer FIPS.
Ya no se pueden obtener nuevas certificaciones FIPS 140-2, y las nuevas certificaciones FIPS 140-3 tienen que pasar por una larga cola porque toda la industria está en transición.
Si fuera algo que el equipo de desarrollo pudiera resolver simplemente empujándolo, ya estaría hecho.
Pido disculpas si dimos la impresión de que no es importante; en realidad sí lo es, pero en este caso eso no ayuda con el cronograma.
Si la necesitas, no hay mucho que hacer, pero personalmente veo que tener la certificación es una señal algo mala.
No soy el único que piensa así; el equipo de Microsoft Windows parece verlo de forma similar: https://techcommunity.microsoft.com/t5/microsoft-security-ba...
Aunque FIPS en sí no sea malvado, hay que recordar que se mueve entre personas malvadas y en entornos malvados https://threadreaderapp.com/thread/1433451378391883782.html
Se ve muy interesante, pero como señalan otros comentarios, la ruta para ejecutarlo directamente se ve difusa.
La página de GitHub también solo aparece en la página principal.
Encontré la guía de VMware aquí: https://github.com/bottlerocket-os/bottlerocket/blob/develop...
Es muy similar a la dirección de CoreOS https://fedoraproject.org/coreos/
Ni en “Get Started” ni en las FAQ aparece cómo ejecutarlo.
Es un buen proyecto, pero existe desde 2020: https://aws.amazon.com/about-aws/whats-new/2020/08/announcin...
Me pregunto si hay alguien que lo use con éxito fuera de AWS
Parece bastante útil para usos como AMD SEV-SNP
Porque para garantizar un comportamiento específico de la máquina se necesitan mediciones del kernel + initrd + argumentos
Idealmente, sería bueno usar esto como hipervisor de contenedores y poder generar una atestación vinculada al hash del contenedor en ejecución
Aunque no debería haber escapes de contenedor, y no sé bien cuál es el estado del arte actual en ese campo
Preferiría usar CoreOS
¿Han lanzado algo open source que se use ampliamente fuera de AWS?
En el sitio web dice que el OS no tiene shell
Me cuesta imaginar un contenedor Docker útil que no tenga al menos un script de shell
Entonces, ¿que no tenga shell no significa que Bottlerocket sea en general inutilizable salvo en algunos escenarios de nicho?
El que no tiene shell es el host, y si traes un contenedor Docker que sí tenga shell y lo ejecutas con privilegios, puedes usar un shell en el host
No es común proporcionar el binario del shell de la máquina host a un contenedor que se está ejecutando en el host
En su lugar, delega esa responsabilidad al contenedor admin, y la conexión real se hace allí mediante SSM/SSH
Si ahí necesitas un shell root, puedes usar la utilidad
sheltiePor ejemplo, está distroless
shells | containers | Bottlerocket | kernel del OS