Proteger contêineres do Windows

Aplica-se a: Windows Server 2025, Windows Server 2022, Windows Server 2019, Windows Server 2016

Os contentores devem o seu tamanho reduzido de imagem ao facto de poderem confiar no host para proporcionar acesso limitado a vários recursos. Se o contêiner souber que o host será capaz de fornecer a funcionalidade necessária para executar um conjunto específico de ações, o contêiner não precisará incluir o software relevante em sua imagem base. A extensão do compartilhamento de recursos que ocorre, no entanto, pode ter um impacto significativo no desempenho e na segurança do contêiner. Se muitos recursos forem compartilhados, o aplicativo pode muito bem ser executado como um processo no host. Se os recursos forem compartilhados muito pouco, o contêiner se tornará indistinguível de uma VM. Ambas as configurações são aplicáveis a muitos cenários, mas a maioria das pessoas que usam contêineres geralmente opta por algo no meio.

A segurança de um contêiner do Windows é derivada do grau de compartilhamento que ocorre com seu host. O limite de segurança de um contêiner é constituído pelos mecanismos de isolamento que separam o contêiner do host. Mais importante ainda, esses mecanismos de isolamento definem quais processos no contêiner podem interagir com o host. Se o design de um contêiner permitir que um processo elevado (admin) interaja com o host, a Microsoft não considera que esse contêiner tenha um limite de segurança robusto.

Contêineres do Windows Server versus contêineres do Linux

Contêineres do Windows Server isolados por processo e contêineres do Linux compartilham graus semelhantes de isolamento. Para ambos os tipos de contêiner, o desenvolvedor deve assumir que qualquer ataque que possa ser executado por meio de um processo elevado no host também pode ser executado por meio de um processo elevado no contêiner. Ambos operam através das capacidades primitivas oferecidas pelos seus respetivos kernels anfitriões. As imagens de contentor são construídas contendo binários em modo utilizador que utilizam as APIs fornecidas pelo kernel do host. O kernel do host fornece os mesmos recursos de isolamento e gerenciamento de recursos para cada contêiner em execução no espaço do usuário. Se o kernel estiver comprometido, o mesmo acontece com todos os contêineres que compartilham esse kernel.

O design fundamental de contêineres de servidores Linux e Windows troca segurança por flexibilidade. Os contêineres do Windows Server e Linux são criados sobre os componentes primitivos fornecidos pelo sistema operacional. Isso fornece a flexibilidade para compartilhar recursos e namespaces entre contêineres, mas adiciona complexidade adicional que abre a porta para a exploração. Em termos gerais, não consideramos que o núcleo (kernel) seja um limite de segurança suficiente para ambientes de múltiplos inquilinos hostis.

Isolamento do kernel com contentores isolados por hipervisor

Os contêineres isolados do hipervisor fornecem um grau mais alto de isolamento do que os contêineres do Windows Server ou Linux isolados por processo e são considerados limites de segurança robustos. Os contêineres isolados do hipervisor consistem em um contêiner do Windows Server encapsulado em uma VM ultraleve e, em seguida, executado ao lado do sistema operacional host por meio do hipervisor da Microsoft. O hipervisor fornece isolamento no nível de hardware que inclui um limite de segurança altamente robusto entre o host e outros contêineres. Mesmo que um exploit conseguisse escapar do contentor do Windows Server, ele estaria contido na máquina virtual (VM) isolada pelo hipervisor.

Nem os contêineres do Windows Server nem os contêineres do Linux fornecem o que a Microsoft considera um limite de segurança robusto e não devem ser usados em cenários multilocatários hostis. Um contêiner deve ser confinado a uma VM dedicada para impedir que um processo de contêiner não autorizado interaja com o host ou outros locatários. O isolamento do hipervisor permite esse grau de separação, ao mesmo tempo em que oferece vários ganhos de desempenho em relação às VMs tradicionais. Portanto, é altamente recomendável que, em cenários multilocatários hostis, os contêineres isolados do hipervisor sejam o contêiner de escolha.

Critérios de manutenção da segurança do contentor

A Microsoft está comprometida em corrigir todas as explorações e escapes que quebram o limite de isolamento estabelecido de qualquer tipo de contêiner do Windows. No entanto, apenas explorações que quebram um limite de segurança são atendidas por meio do processo do Microsoft Security Response Center (MSRC). Somente contêineres isolados por hipervisor fornecem um limite de segurança, e contêineres isolados por processo não. A única maneira de gerar um bug para um escape de contêiner isolado por processo é se um processo não administrativo puder obter acesso ao host. Se uma exploração usar um processo de administração para escapar do contêiner, a Microsoft considerará que é um bug não relacionado à segurança e o corrigirá de acordo com o processo de manutenção normal. Se uma exploração usar um processo não administrativo para executar uma ação que viole um limite de segurança, a Microsoft a investigará de acordo com os critérios de serviço de segurança estabelecidos .

O que torna uma carga de trabalho multilocatário hostil?

Existem ambientes multilocatários quando várias cargas de trabalho estão operando em recursos e infraestrutura compartilhados. Se uma ou mais cargas de trabalho em execução em uma infraestrutura não puderem ser confiáveis, o ambiente multilocatário será considerado hostil. Os contêineres do Windows Server e do Linux compartilham o kernel do host, portanto, qualquer exploração executada em um único contêiner pode afetar todas as outras cargas de trabalho em execução na infraestrutura compartilhada.

Você pode tomar medidas para reduzir a probabilidade de um exploit ocorrer, por exemplo, usando políticas de segurança de pods, AppArmor e controle de acesso baseado em funções (RBAC), mas elas não fornecem proteção garantida contra um invasor. Recomendamos que você siga nossas práticas recomendadas para isolamento de cluster para qualquer cenário multilocatário.

Quando usar as contas de usuário ContainerAdmin e ContainerUser

Os contêineres do Windows Server oferecem duas contas de usuário padrão, ContainerUser e ContainerAdministrator, cada uma com sua própria finalidade específica. A conta ContainerAdministrator permite que você use o contêiner para fins administrativos: instalar serviços e software (como habilitar o IIS dentro de um contêiner), fazer alterações de configuração e criar novas contas. Essas tarefas são importantes para vários cenários de TI que podem estar sendo executados em ambientes de implantação locais personalizados.

A conta ContainerUser existe para todos os outros cenários em que os privilégios de administrador no Windows não são necessários. Por exemplo, no Kubernetes, se o usuário for ContainerAdministrator e os volumes de host tiverem permissão para serem montados no pod, o usuário poderá montar a pasta .ssh e adicionar uma chave pública. Como ContainerUser, este exemplo não seria possível. É uma conta de usuário restrita projetada exclusivamente para aplicativos que não precisam interagir com o host. É altamente recomendável que, ao implantar um contêiner de servidor Windows em qualquer ambiente multilocatário, seu aplicativo seja executado por meio da conta ContainerUser. Em um ambiente multilocatário, é sempre melhor seguir o princípio do menor privilégio porque, se um invasor comprometer sua carga de trabalho, o recurso compartilhado e as cargas de trabalho vizinhas também terão menor chance de serem afetados. A execução de contêineres com a conta ContainerUser reduz consideravelmente a chance de o ambiente ser comprometido como um todo. No entanto, isso ainda não fornece um limite de segurança robusto, portanto, quando a segurança é uma preocupação, você deve usar contêineres isolados do hipervisor.

Para alterar a conta de usuário, você pode usar a instrução USER em seu dockerfile:

USER ContainerUser

Como alternativa, você pode criar um novo usuário:

RUN net user username ‘<password>’ /ADD
USER username

Serviços do Windows

Os serviços do Microsoft Windows, anteriormente conhecidos como serviços NT, permitem que você crie aplicativos executáveis de longa execução que são executados em suas próprias sessões do Windows. Esses serviços podem ser iniciados automaticamente quando o sistema operacional é iniciado, podem ser pausados e reiniciados e não mostram nenhuma interface do usuário. Você também pode executar serviços no contexto de segurança de uma conta de usuário específica que é diferente do usuário conectado ou da conta de computador padrão.

Ao colocar em contêineres e proteger uma carga de trabalho que é executada como um serviço do Windows, há algumas considerações adicionais a serem observadas. Primeiro, o ENTRYPOINT do contêiner não será a carga de trabalho, uma vez que o serviço é executado como um processo em segundo plano, normalmente o ENTRYPOINT será uma ferramenta como monitor de serviço) ou monitor de log). Em segundo lugar, a conta de segurança na qual a carga de trabalho opera será configurada pelo serviço e não pela diretiva USER no dockerfile. Você pode verificar em qual conta o serviço será executado executando Get-WmiObject win32_service -filter "name='<servicename>'" | Format-List StartName.

Por exemplo, ao hospedar um aplicativo Web do IIS usando a imagem ASP.NET (Microsoft Artifact Registry), a ENTRYPOINT do contêiner é "C:\\ServiceMonitor.exe", "w3svc". Essa ferramenta pode ser usada para configurar o serviço IIS e, em seguida, monitora o serviço para garantir que ele permaneça em execução e saia, interrompendo assim o contêiner, se o serviço parar por qualquer motivo. Por padrão, o serviço IIS e, portanto, o aplicativo Web são executados sob uma conta de baixo privilégio dentro do contêiner, mas a ferramenta de monitor de serviço requer privilégios administrativos para configurar e monitorar o serviço.