Protección de contenedores de Windows

Se aplica a: Windows Server 2025, Windows Server 2022, Windows Server 2019, Windows Server 2016

El hecho de que los contenedores tengan un tamaño de imagen reducido se debe a que pueden confiar en el host para ofrecer 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. La extensión del uso compartido de recursos que se produce, sin embargo, puede tener un impacto significativo en el rendimiento y la seguridad del contenedor. Si se comparten demasiados recursos, la aplicación también puede ejecutarse como un proceso en el host. Si los recursos se comparten demasiado poco, el contenedor se vuelve indistinguible desde una máquina virtual. Ambas configuraciones son aplicables a muchos escenarios, pero la mayoría de las personas que usan contenedores suelen optar por algo en el medio.

La seguridad de un contenedor de Windows se deriva del grado de uso compartido que se produce con su host. El límite de seguridad de un contenedor se constituye mediante los mecanismos de aislamiento que separan el contenedor del host. Lo más importante es que 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 (administradores) 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 aislados por procesos y los contenedores de Linux comparten grados de aislamiento similares. Para ambos tipos de contenedor, el desarrollador debe asumir 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 compilan con 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 aislamiento y administración de recursos para cada contenedor que se ejecuta en el espacio de usuario. Si el kernel está comprometido, entonces lo está cada contenedor que comparte ese kernel.

El diseño fundamental de los contenedores de Linux y Windows Server intercambia la seguridad para ofrecer flexibilidad. Los contenedores de Windows Server y Linux se basan en los componentes primitivos proporcionados por el sistema operativo. Esto proporciona la flexibilidad para compartir recursos y espacios de nombres entre contenedores, pero agrega complejidad adicional que abre la puerta para la explotación. 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 mediante hipervisor

Los contenedores aislados por hipervisor proporcionan un mayor grado de aislamiento que los contenedores de Windows Server o Linux aislados por procesos y se consideran límites de seguridad sólidos. Los contenedores aislados por hipervisor constan de un contenedor de Windows Server encapsulado en una máquina virtual ultraligera y, a continuación, se ejecutan junto con el sistema operativo host a través del hipervisor de Microsoft. El hipervisor proporciona aislamiento de nivel de hardware que incluye un límite de seguridad muy sólido entre el host y otros contenedores. Incluso si una vulnerabilidad fuera a escapar del contenedor de Windows Server, se incluiría dentro de la máquina virtual aislada del hipervisor.

Ninguno de los contenedores de Windows Server ni los contenedores de Linux proporcionan lo que Microsoft considera un límite de seguridad sólido y no debe usarse en escenarios multiinquilino hostiles. Un contenedor debe estar limitado a una máquina virtual 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, al tiempo que ofrece varias mejoras de rendimiento en las máquinas virtuales tradicionales. Por lo tanto, se recomienda encarecidamente que, en escenarios de multitenencia hostiles, los contenedores aislados por hipervisor sean la opción preferida.

Criterios de mantenimiento de seguridad de contenedores

Microsoft se compromete a aplicar revisiones a todas las vulnerabilidades de seguridad y escape que interrumpen el límite de aislamiento establecido de cualquier tipo de contenedor de Windows. Sin embargo, solo las vulnerabilidades de seguridad que interrumpen un límite de seguridad se administran a través del proceso del Centro de respuesta de seguridad de Microsoft (MSRC). Sólo los contenedores aislados por hipervisor proporcionan un límite de seguridad, mientras que los contenedores aislados por proceso no lo hacen. La única manera de generar un error para un escape de contenedor aislado de procesos es si un proceso que no es administrador puede obtener acceso al host. Si una vulnerabilidad de seguridad usa un proceso de administración para escapar del contenedor, Microsoft considera que es un error que no es de seguridad y lo revisará según el proceso de mantenimiento normal. Si una vulnerabilidad de seguridad usa un proceso que no es de administración 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 la infraestructura y los recursos compartidos. Si una o varias cargas de trabajo que se ejecutan en una infraestructura no pueden ser de confianza, el entorno multiinquilino se considera hostil. Los contenedores de Windows Server y Linux comparten el kernel de host, por lo que cualquier vulnerabilidad de seguridad realizada en un único contenedor puede afectar a todas las demás cargas de trabajo que se ejecutan en la infraestructura compartida.

Puede realizar pasos para reducir la posibilidad de que se produzca una vulnerabilidad de seguridad, por ejemplo, mediante directivas de seguridad de pod, AppArmor y control de acceso basado en rol (RBAC), pero no proporcionan protección garantizada contra un atacante. Se recomienda seguir nuestros procedimientos recomendados para el aislamiento de clústeres en cualquier escenario multiinquilino.

Cuándo usar las 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 (como habilitar IIS dentro de un contenedor), realizar cambios de configuración y crear cuentas nuevas. Estas tareas son importantes para una serie de escenarios de TI que se pueden ejecutar 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 hostvolumes pueden montarse 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. Es una cuenta de usuario restringida diseñada exclusivamente para aplicaciones que no necesitan interactuar con el host. Se recomienda encarecidamente que, al implementar un contenedor de windows server en cualquier entorno multiinquilino que la aplicación ejecute a través de la cuenta ContainerUser. En un entorno multiinquilino, siempre es mejor seguir el principio de privilegios mínimos porque si un atacante pone en peligro la carga de trabajo, los recursos compartidos y las cargas de trabajo vecinas también tienen una menor posibilidad de verse afectados. La ejecución de contenedores con la cuenta ContainerUser reduce considerablemente la posibilidad de que el entorno se ponga en peligro en su conjunto. Sin embargo, esto sigue sin proporcionar un límite de seguridad sólido, por lo que cuando la seguridad es un problema, debe usar contenedores aislados del 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

Servicios de Windows

Los servicios de Microsoft Windows, anteriormente conocidos como servicios NT, permiten crear aplicaciones ejecutables de larga duración que se ejecutan en sus propias sesiones de Windows. Estos servicios se pueden iniciar automáticamente cuando se inicia el sistema operativo, se pueden pausar y reiniciar y no mostrar ninguna interfaz de usuario. También puede ejecutar servicios en el contexto de seguridad de una cuenta de usuario específica diferente del usuario que ha iniciado sesión o la cuenta de equipo predeterminada.

Al incluir en contenedores y proteger una carga de trabajo que se ejecuta como servicio de Windows, hay algunas consideraciones adicionales que debe tener en cuenta. En primer lugar, el ENTRYPOINT del contenedor no va a ser la carga de trabajo, ya que el servicio se ejecuta como un proceso en segundo plano, normalmente será ENTRYPOINT una herramienta como el monitor de servicio) o el monitor de registro). En segundo lugar, la cuenta de seguridad en la que opera la carga de trabajo se configurará mediante el servicio no mediante la directiva USER en el dockerfile. Puede comprobar bajo qué cuenta se ejecutará el servicio ejecutando Get-WmiObject win32_service -filter "name='<servicename>'" | Format-List StartName.

Por ejemplo, cuando se hospeda una aplicación web de IIS usando la imagen ASP.NET del Registro de artefactos de Microsoft, el ENTRYPOINT del contenedor es "C:\\ServiceMonitor.exe", "w3svc". Esta herramienta se puede usar para configurar el servicio IIS y, a continuación, supervisa el servicio para asegurarse de que permanece en ejecución y sale, deteniendo así el contenedor, si el servicio se detiene por cualquier motivo. De forma predeterminada, el servicio IIS y, por tanto, la aplicación web se ejecuta con una cuenta con pocos privilegios dentro del contenedor, pero la herramienta de supervisión de servicios requiere privilegios administrativos para configurar y supervisar el servicio.