sistema_operativo

Para aquellos que no lo saben, los sistemas operativos inmutables han aumentado recientemente en popularidad. Un sistema operativo inmutable es aquel en el que algunos o todos los sistemas de archivos del sistema operativo son de solo lectura y no se pueden cambiar.

Los sistemas operativos inmutables tienen muchas ventajas. Son intrínsecamente más seguros, porque muchos ataques y exploits dependen de la escritura o modificación de archivos. Además, incluso si se encuentra un exploit, los malintencionados no pueden cambiar el sistema operativo en el disco (lo que en sí frustrará los ataques que dependen de la escritura en el sistema de archivos), por lo que un reinicio eliminará cualquier malware residente en la memoria y se recuperará a un no -Estado explotado.

Los sistemas inmutables también son más fáciles de administrar y actualizar: las imágenes del sistema operativo no se parchean ni actualizan, sino que se reemplazan de forma atómica (en una operación que se garantiza que se completará por completo o fallará por completo, ¡sin actualizaciones parciales!)
Los sistemas inmutables también pueden afirmar ser más estables que los sistemas operativos tradicionales, simplemente en virtud de eliminar muchos de los vectores que introducen inestabilidad en un sistema, la mayoría de los cuales son humanos. Ningún administrador de sistemas puede "simplemente cambiar esta configuración para arreglar las cosas", con impactos imprevistos que no se encuentran hasta horas después. (He sido ese administrador de sistemas). No hay terraformas parcialmente completas ni ejecuciones de marionetas que dejen los sistemas en estados extraños...

En el lado de la estación de trabajo, existen enfoques para sistemas operativos inmutables como rpm-ostree . Esto intenta crear inmutabilidad e implementaciones basadas en imágenes en el sistema operativo, pero coloca una arquitectura de sistema de archivos flexible en la parte superior, de modo que RPM aún puede administrar y actualizar los paquetes.

En el lado del servidor, existe un espectro de inmutabilidad entre los sistemas operativos específicos del contenedor. Todos admiten actualizaciones del sistema operativo basadas en imágenes y ningún administrador de paquetes. Algunos sistemas operativos, como Flatcar Linux , hacen que /usr sea de solo lectura, pero permiten modificaciones comunes en el tiempo de ejecución, como la carga dinámica de módulos del kernel y la anulación de las configuraciones de systemd.

Bottlerocket , de Amazon Web Services , agrega la partición /root que es de solo lectura y deshabilita el acceso SSH de forma predeterminada (se puede ejecutar en un contenedor privilegiado). Bottlerocket permite que los módulos del kernel se carguen en versiones anteriores, pero ha cambiado para permitir solo los módulos que están firmados con la clave de imagen de Bottlerocket: esos módulos se envían con Bottlerocket.

Talos Linux , de Sidero Labs, lleva el concepto de inmutable aún más lejos. Es otro sistema operativo con un sistema de archivos completamente inmutable y una API completa para la administración y, a diferencia de Bottlerocket, elimina por completo SSH y el acceso a la consola, y se ejecuta en cualquier lugar donde ejecute Kubernetes: todos los proveedores de la nube, bare metal, sistemas virtualizados, incluso dentro de Docker y en SBC como Raspberry Pis. Talos Linux también requiere que los módulos del kernel se firmen con la misma clave que se usó para construir el kernel, y debido a que esta clave es efímera, hace que el kernel sea completamente estático e inmutable.

Por supuesto, como en todas las cosas, las fortalezas inherentes a los sistemas operativos inmutables también son sus debilidades. No todos los sistemas necesitan ejecutar las mismas cargas de trabajo, firmware y paquetes. ¿Cómo se personaliza un sistema operativo inmutable para adaptarse a una variedad de aplicaciones?

Flatcar Linux, que tiene características menos inmutables (el sistema de archivos raíz se puede escribir y los nodos admiten SSH, por ejemplo), soluciona este problema con el proyecto Ignition (a menudo junto con Afterburn), que se ejecuta en el primer arranque de un nodo y puede modificar el sistema de archivos, agregar archivos, configurar usuarios y otras operaciones. Esto es similar a un flujo de trabajo típico de Linux donde se utilizan herramientas como Puppet, Chef, etc. (excepto que solo se puede ejecutar una vez en el primer arranque).

De manera similar, Bottlerocket usa el concepto de contenedores Bootstrap para personalizar la forma en que se ejecuta el nodo. Estos son contenedores que systemd ejecuta después de que se haya iniciado el nodo, que tienen acceso al sistema de archivos raíz y a los dispositivos host. Pueden ejecutarse en cada arranque, o solo en el primer arranque. El orden de estos contenedores no es determinista. Por lo tanto, los contenedores de arranque no están restringidos por la inmutabilidad del sistema de archivos, lo que reduce un poco la efectividad de la inmutabilidad por motivos de seguridad.

Extensiones del sistema

Talos Linux, al ser completamente inmutable, tiene que adoptar un enfoque más estricto para modificar los nodos. Talos Linux utiliza un concepto llamado System Extensions . Puede funcionar manteniendo la inmutabilidad total del sistema operativo porque requiere que dichas extensiones se configuren durante la instalación o actualización del nodo. Para efectuar cualquier cambio en las extensiones del sistema, se debe volver a instalar Talos Linux en el nodo.

Esto fomenta (¡de hecho, hace cumplir!) la idea de 'mascotas, no ganado', ya que para agregar o cambiar un nodo a través de extensiones del sistema, el contenido del disco se borrará y reemplazará. Durante la instalación/reinstalación, las imágenes del contenedor de extensión del sistema se almacenarán en initramfs como imágenes squashfs ; durante el arranque, se superponen en la parte superior del sistema de archivos raíz squashfs de Talos Linux utilizando montajes squashfs overlayfs de solo lectura . Todos los sistemas de archivos (excepto / var para los datos de Kubernetes) son inmutables a partir de entonces.

El concepto de extensión de sistemas preserva la inmutabilidad de los sistemas de archivos al tiempo que permite que los nodos carguen diferentes capacidades, como firmware específico o gVisor para un mayor aislamiento de los contenedores.

Estos diferentes enfoques para permitir la modificación de sistemas inmutables tienen diferentes fortalezas, pero permiten al usuario seleccionar lo que es apropiado para ellos: desde administrar sistemas de una manera familiar (como con rpm-ostree o usando SSH) hasta nuevos paradigmas como ese implementado por Talos Linux, donde no hay SSH, toda la administración se realiza mediante API y la seguridad es primordial, con el requisito de aprender una nueva forma de administrar los sistemas.

 

Fuente: thenewstack | somoslibres

¿Quién está en línea?

Hay 581 invitados y ningún miembro en línea