Seguridad, almacenamiento y redes con contenedores de Windows
Contoso le ha pedido, como administrador de Windows Server, que evalúe las necesidades de seguridad, almacenamiento y redes de contenedores de Windows. Está especialmente interesado en comprender cómo difieren esas necesidades entre contenedores y máquinas virtuales en Windows Server.
Seguridad de contenedores de Windows
Los contenedores de Windows se construyen en la misma base que las instancias de Windows que se ejecutan en máquinas físicas o virtuales. Sin embargo, algunos aspectos de seguridad se controlan de forma diferente o son específicos para los contenedores de Windows:
Componentes compartidos. Los contenedores de Windows comparten algunos de los componentes del host con fines de seguridad. Esto incluye el firewall de Windows, Windows Defender (Antivirus) y otras limitaciones de acceso a los recursos. No es necesario configurar estos componentes en el contenedor directamente porque el host del contenedor realiza los ajustes necesarios en función de la carga de trabajo del contenedor. Por ejemplo, si el contenedor realiza una solicitud web, el host del contenedor reenviará el tráfico necesario a través de su firewall para que el contenedor pueda acceder a la web.
Modo de aislamiento. Los contenedores de Windows se pueden implementar en modo de aislamiento de proceso o Hyper-V (Hyper-V proporciona el aislamiento más seguro). En aislamiento de procesos, el contenedor comparte su kernel, sistema de archivos y registro con el host, lo que permite que un proceso elevado (administrador) interactúe con los procesos y servicios del contenedor. Es importante elegir el modo de aislamiento correcto para la aplicación para garantizar el modo de seguridad adecuado.
Actualizaciones de Windows. Dado que la pila de mantenimiento no está presente en contenedores de Windows, los contenedores de Windows no reciben actualizaciones como las instancias generales de Windows. En su lugar, debe recompilar contenedores de Windows con la imagen de contenedor base disponible más reciente. Los clientes pueden aprovechar las canalizaciones de Azure para ese propósito. Microsoft actualiza las imágenes de contenedor base para todas sus imágenes oficiales mensualmente siguiendo la cadencia de Patch Tuesday.
Cuenta de usuario de contenedor. De forma predeterminada, las aplicaciones dentro de contenedores de Windows se ejecutan con privilegios elevados en la cuenta de usuario ContainerAdmin. Esto resulta útil para instalar y configurar los componentes necesarios dentro de la imagen de contenedor. Sin embargo, debe considerar la posibilidad de cambiar la cuenta de usuario a ContainerUser al ejecutar una aplicación que no requiera los privilegios elevados. En escenarios específicos, también puede crear una nueva cuenta con los privilegios adecuados.
Examen de imágenes y tiempo de ejecución. Los contenedores requieren que las imágenes de los repositorios y las instancias de contenedores sean seguras. Microsoft recomienda usar Microsoft Defender para contenedores para el análisis de imágenes y el análisis de entorno de ejecución. Defender para contenedores admite contenedores de Windows para la evaluación de vulnerabilidades con el examen de registros y la protección de entorno de ejecución con detección de amenazas.
Para obtener más información sobre la seguridad de los contenedores de Windows, consulte Protección de contenedores de Windows.
Almacenamiento persistente para contenedores de Windows
Los contenedores de Windows usan un almacenamiento efímero de forma predeterminada. Todas las E/S del contenedor se producen en un "espacio temporal". Un espacio temporal es un almacenamiento temporal proporcionado al contenedor para los cambios en el sistema de archivos. Cada contenedor obtiene su propio rasguño. La creación de archivos y las escrituras de archivos se capturan en el espacio de desecho y no escapan al host. Cuando se elimina una instancia de contenedor, se descartan todos los cambios que se produjeron en el espacio de desecho. Cuando se inicia una nueva instancia de contenedor, se proporciona un nuevo espacio de desecho para la instancia.
Puede haber casos en los que sea importante que una aplicación pueda conservar los datos en un contenedor o en los que quieras mostrar los archivos en un contenedor que no se incluyeron en el tiempo de compilación del contenedor. Con ese fin, el almacenamiento persistente se puede proporcionar a los contenedores de Windows.
El almacenamiento persistente se puede proporcionar a los contenedores de Windows a través del motor de Docker o del orquestador de contenedores. En entornos de desarrollo y pruebas, el motor de Docker proporciona una manera rápida y sencilla de asignar almacenamiento local a contenedores de Windows con montajes Bind o volúmenes con nombre. Enlazar montajes permite que un contenedor comparta un directorio con el host. Esto es útil si quiere un lugar para almacenar archivos en la máquina local que están disponibles si reinicia un contenedor o quiere compartirlos con varios contenedores. Si quieres que el contenedor se ejecute en varias máquinas con acceso a los mismos archivos, debe usarse en su lugar un volumen con nombre o el montaje SMB.
En entornos de producción, el orquestador de contenedores puede proporcionar opciones de almacenamiento persistente de nivel empresarial. Por ejemplo, Kubernetes proporciona de forma nativa volúmenes persistentes que se pueden usar para proporcionar almacenamiento persistente para varios contenedores que se ejecutan en varios hosts. Además, Kubernetes también proporciona complementos de terceros que se usarán para asignar volúmenes en el almacenamiento en la nube, como Azure Storage.
Para obtener más información sobre el almacenamiento persistente para contenedores de Windows, consulte Introducción a Container Storage.
Red de contenedores de Windows
Los contenedores de Windows funcionan de forma similar a las máquinas virtuales en lo referente a las redes. Cada contenedor tiene un adaptador de red virtual (vNIC) que se conecta a un conmutador virtual Hyper-V (vSwitch). Windows admite cinco controladores de red o modos diferentes que pueden crearse mediante Docker: nat, overlay, transparent, l2bridge y l2tunnel. En función de la infraestructura de red física y de los requisitos de red de un solo host o de varios hosts, debes elegir el controlador de red que mejor se adapte a tus necesidades.
| Controlador de red de Windows de Docker | Usos típicos | Contenedor a contenedor (nodo único) | Contenedor a externo (nodo único + varios nodos) | Contenedor a contenedor (varios nodos) |
|---|---|---|---|---|
| NAT (valor predeterminado) | Good para desarrolladores | Misma subred: conexión puenteda a través del conmutador virtual de Hyper-V Subred cruzada: no compatible (solo un prefijo interno NAT) |
Enrutado a través de la vNIC de administración (enlazado a WinNAT) | No se admite directamente: requiere exponer puertos a través del host. |
| Transparente | Adecuado para desarrolladores o implementaciones pequeñas | Misma subred: conexión puenteada a través del conmutador virtual de Hyper-V Subred cruzada: enrutada a través del host de contenedor |
Enrutado a través del host de contenedor con acceso directo al adaptador de red (físico) | Enrutado a través del host de contenedor con acceso directo al adaptador de red (físico) |
| Overlay | Bueno para varios nodos; obligatorio para Docker Swarm, disponible en Kubernetes | Misma subred: conexión puenteada a través del conmutador virtual de Hyper-V Subred cruzada: el tráfico de red se encapsula y enruta a través de Mgmt vNIC |
No compatible directamente: requiere el segundo punto de conexión de contenedor conectado a la red NAT en Windows Server 2016 o regla NAT de VFP en Windows Server 2019. | Misma subred/Subred cruzada: el tráfico de red se encapsula usando VXLAN y se enruta a través de Mgmt vNIC |
| L2Bridge | Se usa para Kubernetes y Microsoft SDN | Misma subred: conexión puenteada a través del conmutador virtual de Hyper-V Subred cruzada: la dirección MAC del contenedor se vuelve a escribir en la entrada y salida y enrutada |
Dirección MAC del contenedor reescribirse en la entrada y salida | Misma subred: conexión puenteda Subred cruzada: enrutada a través de Mgmt vNIC en WSv1809 y versiones posteriores |
| L2Tunnel | Solo Azure | Misma subred/entre subredes: anclado al conmutador virtual de Hyper-V del host físico en el que se aplica la directiva | El tráfico debe pasar por la puerta de enlace de red virtual de Azure | Misma subred/entre subredes: anclado al conmutador virtual de Hyper-V del host físico en el que se aplica la directiva |
Además de las opciones de Docker anteriores, Kubernetes proporciona diferentes complementos de interfaz de red de contenedor (CNI). Estas CNI implementan diferentes modos para la configuración de red, las directivas de red, etc.
Para obtener más información sobre las redes para contenedores de Windows, consulte Redes de contenedores de Windows.