Proteger los contenedores de Windows
Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016
Los contenedores deben su tamaño de imagen reducido al hecho de que se basan en el host para proporcionar acceso limitado a varios recursos. Si el contenedor sabe que el host podrá proporcionar la funcionalidad necesaria para realizar un conjunto específico de acciones, el contenedor no necesita incluir el software pertinente en su imagen base. Sin embargo, el grado del uso compartido de los recursos que tiene lugar puede afectar de manera significativa al rendimiento y la seguridad del contenedor. Si se comparten demasiados recursos, es posible que la aplicación también se ejecute como un proceso en el host. Si los recursos se comparten demasiado poco, el contenedor no se distingue de una VM. Ambas configuraciones son aplicables a muchos escenarios, pero la mayoría de las personas que usan contenedores suelen optar por algo intermedio.
La seguridad de un contenedor de Windows se deriva del grado de uso compartido que tiene lugar en el host. El límite de seguridad de un contenedor se establece mediante los mecanismos de aislamiento que separan el contenedor del host. Más importante aún, estos mecanismos de aislamiento definen qué procesos del contenedor pueden interactuar con el host. Si el diseño de un contenedor permite que un proceso con privilegios elevados (de administración) interactúe con el host, Microsoft no considera que este contenedor tenga un límite de seguridad sólido.
Contenedores de Windows Server frente a contenedores de Linux
Los contenedores de Windows Server y los contenedores de Linux aislados por procesos comparten grados similares de aislamiento. Para ambos tipos de contenedor, el desarrollador debe suponer que cualquier ataque que se pueda realizar a través de un proceso con privilegios elevados en el host también se puede realizar a través de un proceso con privilegios elevados en el contenedor. Ambos funcionan a través de las funcionalidades primitivas que ofrecen sus respectivos kernels de host. Las imágenes de contenedor se crean de modo que incluyen archivos binarios en modo de usuario que usan las API proporcionadas por el kernel del host. El kernel del host proporciona las mismas funcionalidades de administración y aislamiento de recursos a cada contenedor que se ejecuta en el espacio de usuarios. Si el kernel está en peligro, también lo está cada contenedor que comparte ese kernel.
El diseño fundamental de los contenedores de Linux y Windows Server canjea seguridad por flexibilidad. Los contenedores de Windows Server y Linux se construyen sobre los componentes primitivos proporcionados por el sistema operativo. Esto brinda la flexibilidad para compartir recursos y espacios de nombres entre contenedores, pero agrega complejidad adicional que abre la puerta a vulnerabilidades. En términos generales, no consideramos que el kernel sea un límite de seguridad suficiente para cargas de trabajo multiinquilino hostiles.
Aislamiento del kernel con contenedores aislados por el hipervisor
Los contenedores aislados por el hipervisor ofrecen un mayor grado de aislamiento que los contenedores de Windows Server o Linux con aislamiento de procesos, y se consideran límites de seguridad sólidos. Los contenedores aislados por el hipervisor constan de un contenedor de Windows Server encapsulado en una VM ultraligera y, a continuación, se ejecutan junto con el sistema operativo host a través del hipervisor de Microsoft. El hipervisor proporciona aislamiento a nivel del hardware, que incluye un límite de seguridad muy sólido entre el host y otros contenedores. Incluso si una vulnerabilidad traspasara el contenedor de Windows Server, quedaría contenida dentro de la VM aislada por el hipervisor.
Ni los contenedores de Windows Server ni los contenedores de Linux brindan lo que Microsoft considera un límite de seguridad sólido, y no deben usarse en escenarios multiinquilino hostiles. Un contenedor debe limitarse a una VM dedicada para evitar que un proceso de contenedor no autorizado interactúe con el host u otros inquilinos. El aislamiento del hipervisor permite este grado de separación, a la vez que ofrece varias mejoras de rendimiento frente a las VM tradicionales. Por lo tanto, se recomienda encarecidamente que, en escenarios multiinquilino hostiles, los contenedores aislados por el hipervisor sean los contenedores de elección.
Criterios de mantenimiento de la seguridad de los contenedores
Microsoft se compromete a aplicar revisiones a todas las vulnerabilidades de seguridad y fugas que traspasen el límite de aislamiento establecido de cualquier tipo de contenedor de Windows. Sin embargo, solo las vulnerabilidades de seguridad que traspasan un límite de seguridad se abordan a través del proceso del Centro de respuestas de seguridad de Microsoft (MSRC). Solo los contenedores aislados por el hipervisor logran un límite de seguridad, los contenedores aislados por procesos no. La única manera de generar un error en caso de escape de un contenedor aislado por procesos es si un proceso no administrativo puede acceder al host. Si una vulnerabilidad de seguridad usa un proceso de administración para escapar el contenedor, Microsoft lo considera un error que no es de seguridad y le aplicará una revisión según el proceso de mantenimiento normal. Si una vulnerabilidad de seguridad usa un proceso no administrativo para realizar una acción que infringe un límite de seguridad, Microsoft lo investigará según los criterios de mantenimiento de seguridad establecidos.
¿Qué hace que una carga de trabajo multiinquilino sea hostil?
Existen entornos multiinquilino cuando varias cargas de trabajo funcionan en recursos e infraestructura compartidos. Si no se puede confiar en una o varias cargas de trabajo que se ejecutan en una infraestructura, el entorno multiinquilino se considera hostil. Los contenedores de Windows Server y Linux comparten el kernel del host, por lo que cualquier vulnerabilidad de seguridad en un solo contenedor puede afectar a todas las demás cargas de trabajo que se ejecutan en la infraestructura compartida.
Puede adoptar medidas para reducir la posibilidad de que se produzca una vulnerabilidad de seguridad, por ejemplo, mediante directivas de seguridad de pods, AppArmor y el control de acceso basado en roles (RBAC), pero no garantizan la protección frente a un atacante. Se recomienda seguir nuestros procedimientos recomendados para el aislamiento de clústeres en cualquier escenario multiinquilino.
Cuándo usar cuentas de usuario ContainerAdmin y ContainerUser
Los contenedores de Windows Server ofrecen dos cuentas de usuario predeterminadas, ContainerUser y ContainerAdministrator, cada una con su propio propósito específico. La cuenta ContainerAdministrator permite usar el contenedor con fines administrativos: instalar servicios y software (por ejemplo, habilitar IIS dentro de un contenedor), hacer cambios de configuración y crear nuevas cuentas. Estas tareas son importantes para distintos escenarios de TI que pueden ejecutarse en entornos de implementación locales personalizados.
La cuenta ContainerUser existe para todos los demás escenarios en los que no se necesitan privilegios de administrador en Windows. Por ejemplo, en Kubernetes si el usuario es ContainerAdministrator y se permite montar volúmenes de host en el pod, el usuario podría montar la carpeta .ssh y agregar una clave pública. Como ContainerUser, este ejemplo no sería posible. Se trata de una cuenta de usuario restringida diseñada exclusivamente para aplicaciones que no tienen que interactuar con el host. Se recomienda encarecidamente que, al implementar un contenedor de Windows Server en cualquier entorno multiinquilino, la aplicación se ejecute a través de la cuenta ContainerUser. En un entorno multiinquilino, siempre es mejor seguir el principio del mínimo de privilegios, ya que si un atacante pone en peligro la carga de trabajo, el recurso compartido y las cargas de trabajo vecinas tendrán una menor probabilidad de verse también afectados. La ejecución de contenedores con la cuenta ContainerUser reduce considerablemente la posibilidad de que el entorno se vea en peligro en su conjunto. Sin embargo, esto sigue sin brindar un límite de seguridad sólido, por lo que cuando la seguridad sea una inquietud, debe usar contenedores aislados por el hipervisor.
Para cambiar la cuenta de usuario, puede usar la instrucción USER en el dockerfile:
USER ContainerUser
Como alternativa, puede crear un nuevo usuario.
RUN net user username ‘<password>’ /ADD
USER username