Segurança, armazenamento e rede com contêineres do Windows
A Contoso pediu a você, como administrador do Windows Server, que avaliasse as necessidades de segurança, armazenamento e rede dos contêineres do Windows. Você está especialmente interessado em entender como essas necessidades diferem entre contêineres e VMs no Windows Server.
Segurança de contêineres do Windows
Os contêineres do Windows são criados na mesma base que as instâncias do Windows executadas em máquinas físicas ou virtuais. No entanto, alguns aspetos de segurança são tratados de forma diferente ou são específicos para contêineres do Windows:
Componentes compartilhados. Os contêineres do Windows compartilham alguns dos componentes do host para fins de segurança. Isso inclui o Firewall do Windows, o Windows Defender (Antivírus) e outras limitações de acesso a recursos. Você não precisa configurar esses componentes diretamente no contêiner porque o host do contêiner faz os ajustes necessários com base na carga de trabalho do contêiner. Por exemplo, se o contêiner fizer uma solicitação da Web, o host do contêiner encaminhará o tráfego necessário através de seu firewall para que o contêiner possa acessar a Web.
Modo de isolamento. Os contêineres do Windows podem ser implantados no processo ou no modo de isolamento do Hyper-V, com o Hyper-V fornecendo o isolamento mais seguro. No isolamento do processo, o contêiner compartilha seu kernel, sistema de arquivos e registro com o host, o que permite que um processo elevado (admin) interaja com os processos e serviços do contêiner. Escolher o modo de isolamento correto para seu aplicativo é importante para garantir o modo de segurança apropriado.
Atualizações do Windows. Como a pilha de serviços não está presente nos contêineres do Windows, os contêineres do Windows não recebem atualizações como instâncias gerais do Windows. Em vez disso, você precisa reconstruir contêineres do Windows usando a imagem de contêiner base mais recente disponível. Os clientes podem aproveitar os pipelines do Azure para essa finalidade. A Microsoft atualiza as imagens de contêiner base para todas as suas imagens oficiais a cada mês após a cadência da Patch Tuesday.
Conta de usuário do contêiner. Por padrão, os aplicativos dentro de contêineres do Windows são executados com privilégios elevados na conta de usuário ContainerAdmin. Isso é útil para instalar e configurar os componentes necessários dentro da imagem do contêiner. No entanto, você deve considerar alterar a conta de usuário para ContainerUser ao executar um aplicativo que não requer os privilégios elevados. Para cenários específicos, você também pode criar uma nova conta com os privilégios apropriados.
Digitalização de imagens e tempo de execução. Os contêineres exigem que as imagens em repositórios e instâncias de contêineres sejam seguras. A Microsoft recomenda que você use o Microsoft Defender for Containers para verificação de imagens e verificação de tempo de execução. O Defender for Containers oferece suporte a contêineres do Windows para avaliação de vulnerabilidades com verificação de registro e proteção de tempo de execução com deteção de ameaças.
Para obter mais informações sobre a segurança de contêineres do Windows, consulte Proteger contêineres do Windows.
Armazenamento persistente para contêineres do Windows
Por padrão, os contêineres do Windows usam armazenamento efêmero. Todas as E/S do contêiner acontecem em um "espaço de rascunho". Um espaço de trabalho é um armazenamento temporário fornecido ao contêiner para alterações no sistema de arquivos. Cada recipiente recebe seu próprio arranhão. A criação e a gravação de arquivos são capturadas no espaço de trabalho e não escapam para o host. Quando uma instância de contêiner é excluída, todas as alterações que ocorreram no espaço de rascunho são descartadas. Quando uma nova instância de contêiner é iniciada, um novo espaço de trabalho é fornecido para a instância.
Você pode ter casos em que é importante que um aplicativo seja capaz de persistir dados em um contêiner ou você deseja mostrar arquivos em um contêiner que não foram incluídos no tempo de compilação do contêiner. Para esse fim, o armazenamento persistente pode ser fornecido para contêineres do Windows.
O armazenamento persistente pode ser fornecido a contêineres do Windows por meio do mecanismo do Docker ou do orquestrador de contêineres. Em ambientes de desenvolvimento/teste, o mecanismo Docker fornece uma maneira rápida e fácil de atribuir armazenamento local a contêineres do Windows com montagens Bind ou volumes nomeados. As montagens de ligação permitem que um contêiner compartilhe um diretório com o host. Isso é útil se você quiser um local para armazenar arquivos na máquina local que estão disponíveis se você reiniciar um contêiner ou quiser compartilhá-lo com vários contêineres. Se você quiser que o contêiner seja executado em várias máquinas com acesso aos mesmos arquivos, um volume nomeado ou montagem SMB deve ser usado.
Para ambientes de produção, o orquestrador de contêineres pode fornecer opções de armazenamento persistente de nível empresarial. Por exemplo, o Kubernetes fornece nativamente Volumes Persistentes que podem ser usados para fornecer armazenamento persistente para vários contêineres executados em vários hosts. Além disso, o Kubernetes também fornece plug-ins de terceiros para serem usados para mapear volumes no armazenamento em nuvem, como o Armazenamento do Azure.
Para obter mais informações sobre armazenamento persistente para contêineres do Windows, consulte Visão geral do armazenamento de contêineres.
Rede de contêineres do Windows
Os contêineres do Windows funcionam de forma semelhante às máquinas virtuais em relação à rede. Cada contêiner tem um adaptador de rede virtual (vNIC) que está conectado a um comutador virtual Hyper-V (vSwitch). O Windows suporta cinco drivers ou modos de rede diferentes que podem ser criados através do Docker: nat, overlay, transparent, l2bridge e l2tunnel. Dependendo da sua infraestrutura de rede física e dos requisitos de rede de host único versus multihost, você deve escolher o driver de rede que melhor atenda às suas necessidades.
| Driver de rede do Docker para Windows | Utilizações típicas | Contêiner a contêiner (nó único) | Contêiner para externo (nó único + vários nós) | Contêiner a contêiner (vários nós) |
|---|---|---|---|---|
| NAT (padrão) | Bom para desenvolvedores | Mesma sub-rede: conexão em ponte através do comutador virtual Hyper-V Sub-rede cruzada: Não suportado (apenas um prefixo interno NAT) |
Roteado através do Management vNIC (vinculado ao WinNAT) | Não suportado diretamente: requer a exposição de portas através do host |
| Transparente | Bom para desenvolvedores ou pequenas implantações | Mesma sub-rede: conexão em ponte através do comutador virtual Hyper-V Sub-rede cruzada: Roteada através do host de contêiner |
Roteado através do host de contêiner com acesso direto ao adaptador de rede (físico) | Roteado através do host de contêiner com acesso direto ao adaptador de rede (físico) |
| Sobreposição | Bom para multi-nós; necessário para o Docker Swarm, disponível no Kubernetes | Mesma sub-rede: conexão em ponte através do comutador virtual Hyper-V Cross Subnet: O tráfego de rede é encapsulado e roteado através do Mgmt vNIC |
Sem suporte direto - requer o segundo ponto de extremidade de contêiner conectado à rede NAT no Windows Server 2016 ou a regra NAT VFP no Windows Server 2019. | Same/Cross Subnet: O tráfego de rede é encapsulado usando VXLAN e roteado através do Mgmt vNIC |
| L2Bridge [en] | Usado para Kubernetes e Microsoft SDN | Mesma sub-rede: conexão em ponte através do comutador virtual Hyper-V Cross Subnet: Endereço MAC do contêiner reescrito na entrada e saída e roteado |
Endereço MAC do contêiner reescrito na entrada e saída | Mesma sub-rede: conexão em ponte Cross Subnet: roteado através do Mgmt vNIC no WSv1809 e superior |
| Túnel L2 | Apenas Azure | Sub-rede Same/Cross: Hair-fixned ao comutador virtual Hyper-V do host físico para onde a política é aplicada | O tráfego deve passar pelo gateway de rede virtual do Azure | Sub-rede Same/Cross: Hair-fixned ao comutador virtual Hyper-V do host físico para onde a política é aplicada |
Além das opções do Docker acima, o Kubernetes fornece diferentes plug-ins CNI (Container Network Interface). Estes CNI implementam diferentes modos de configuração de rede, políticas de rede, etc.
Para obter mais informações sobre rede para contêineres do Windows, consulte Rede de contêineres do Windows.