Proteger contêineres do Windows

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

Os contêineres emprestam seu tamanho de imagem reduzido ao fato de que eles podem contar com o host para fornecer acesso limitado a vários recursos. Se o contêiner souber que o host poderá 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 poderá 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 optam 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, 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 (administrador) interaja com o host, a Microsoft não considerará 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 por meio dos recursos primitivos oferecidos por seus respectivos kernels de host. As imagens de contêiner são criadas contendo binários de modo de usuário 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, todos os contêineres compartilharão esse kernel.

O design fundamental dos contêineres do Linux e do Windows Server troca a segurança pela flexibilidade. Os contêineres do Windows Server e do Linux são criados com base nos 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 exploração. Amplamente declarado, não consideramos o kernel um limite de segurança suficiente para cargas de trabalho multilocatário hostis.

Isolamento de kernel com contêineres isolados por hipervisor

Os contêineres isolados por hipervisor fornecem um grau de isolamento maior do que os contêineres do Windows Server ou linux isolados pelo processo e são considerados um limite de segurança robusto. Os contêineres isolados do hipervisor consistem em um contêiner do Windows Server encapsulado em uma VM ultraleve e, em seguida, são executados junto com o 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 uma exploração escapasse do contêiner do Windows Server, ela estaria contida na VM isolada do hipervisor.

Nem contêineres do Windows Server nem 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 hostis de vários locatários. Um contêiner deve ser confinado a uma VM dedicada para impedir que um processo de contêiner invasor 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 VMs tradicionais. Portanto, é altamente recomendável que, em cenários hostis de vários locatários, contêineres isolados por hipervisor sejam o contêiner de sua escolha.

Critérios de manutenção de segurança de contêiner

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, somente as explorações que quebram um limite de segurança são atendidas por meio do processo do MSRC (Centro de Resposta de Segurança da Microsoft). 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 uma fuga de contêiner isolada por processo é se um processo não administrador pode obter acesso ao host. Se uma exploração usar um processo de administrador para escapar do contêiner, a Microsoft o considerará um bug que não é de segurança e o corrigirá de acordo com o processo normal de manutenção. Se uma exploração usar um processo de não administrador para executar uma ação que viole um limite de segurança, a Microsoft a investigará de acordo com os critérios de manutençã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 infraestrutura e recursos 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 chance de que uma exploração ocorra, por exemplo, usando políticas de segurança de pod, AppArmor e RBAC (controle de acesso baseado em função), 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 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 em 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 em execução 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 hostvolumes 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 puramente para aplicativos que não precisam interagir com o host. É altamente recomendável que, ao implantar um contêiner do Windows Server em qualquer ambiente multilocatário executado pelo aplicativo por meio da conta containerUser. Em um ambiente multilocatário, é sempre melhor seguir o princípio do privilégio mínimo, pois se um invasor comprometer sua carga de trabalho, o recurso compartilhado e as cargas de trabalho vizinhas também terão uma 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 por hipervisor.

Para alterar a conta de usuário, você pode usar a instrução USER no 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 criar aplicativos executáveis de execução longa 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 diferente do usuário conectado ou da conta de computador padrão.

Ao colocar em contêiner e proteger uma carga de trabalho que é executada como um serviço Windows, há algumas considerações adicionais a serem consideradas. Primeiro, o ENTRYPOINT contêiner não será a carga de trabalho, pois o serviço é executado como um processo em segundo plano, normalmente será ENTRYPOINT uma ferramenta como monitor de serviço) ou monitor de log). Em segundo lugar, a conta de segurança em que 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 (Registro de Artefatos da Microsoft) do ENTRYPOINT contêiner é ."C:\\ServiceMonitor.exe", "w3svc" Essa ferramenta pode ser usada para configurar o serviço do 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 algum motivo. Por padrão, o serviço IIS e, portanto, o aplicativo Web são executados em 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.