Безопасные контейнеры Windows

Область применения: Windows Server 2025, Windows Server 2022, Windows Server 2019, Windows Server 2016

Контейнеры обязаны уменьшенному размеру образа тому, что они могут полагаться на хост для предоставления ограниченного доступа к различным ресурсам. Если контейнер знает, что хост сможет предоставить функциональные возможности, необходимые для выполнения определенного набора действий, контейнеру не нужно включать соответствующее программное обеспечение в базовый образ. Однако степень общего доступа к ресурсам, которая возникает, может оказать значительное влияние на производительность и безопасность контейнера. Если слишком много ресурсов используется совместно, то приложение может с таким же успехом выполняться как процесс на хосте. Если ресурсы используются слишком мало, контейнер становится неотличимым от виртуальной машины. Обе конфигурации применимы ко многим сценариям, но большинство пользователей, использующих контейнеры, обычно выбирают что-то в середине.

Безопасность контейнера Windows зависит от степени совместного использования с его хостом. Граница безопасности контейнера состоит из механизмов изоляции, которые отделяют контейнер от хоста. Самое главное, эти механизмы изоляции определяют, какие процессы в контейнере могут взаимодействовать с хостом. Если конструкция контейнера позволяет процессу с повышенными привилегиями (администратору) взаимодействовать с хостом, Microsoft не рассматривает такой контейнер как имеющий надежную границу безопасности.

Контейнеры Windows Server и контейнеры Linux

Контейнеры Windows Server с изоляцией процессов и контейнеры Linux обладают схожими степенями изоляции. Для обоих типов контейнеров разработчик должен предположить, что любая атака, которую можно выполнить с помощью процесса с повышенными привилегиями на узле, также может выполняться с помощью процесса с повышенными привилегиями в контейнере. Оба работают с помощью базовых возможностей, предлагаемых соответствующими хост-ядрами. Образы контейнеров создаются, содержащие двоичные файлы в пользовательском режиме, использующие API, предоставляемые ядром узла. Ядро узла предоставляет одинаковые возможности изоляции ресурсов и управления для каждого контейнера, работающего в пользовательском пространстве. Если ядро скомпрометировано, то каждый контейнер, использующий это ядро, также будет скомпрометирован.

Основная конструкция контейнеров Linux и Windows Server жертвует безопасностью ради гибкости. Контейнеры Windows Server и Linux основаны на примитивных компонентах, предоставляемых ОС. Это обеспечивает гибкость совместного использования ресурсов и пространств имен между контейнерами, но добавляет дополнительную сложность, которая открывает дверь для эксплуатации. В общем, мы не считаем ядро достаточным барьером безопасности для враждебных многопользовательских нагрузок.

Изоляция ядра с изолированными от гипервизора контейнерами

Контейнеры, изолированные от гипервизора, обеспечивают более высокую степень изоляции, чем изолированные от процесса контейнеры Windows Server или Linux и считаются надежными границами безопасности. Контейнеры, изолированные гипервизором, состоят из контейнера Windows Server, упакованного в ультралегкую виртуальную машину, а затем запускаются вместе с операционной системой узла через гипервизор Майкрософт. Гипервизор обеспечивает изоляцию на уровне оборудования, которая включает в себя надежную границу безопасности между узлом и другими контейнерами. Даже если эксплойт прорвется из контейнера Windows Server, он будет содержаться в виртуальной машине, изолированной гипервизором.

Ни контейнеры Windows Server, ни контейнеры Linux не предоставляют то, что корпорация Майкрософт считает надежной границей безопасности и не должна использоваться в враждебных сценариях с несколькими клиентами. Контейнер должен быть ограничен выделенной виртуальной машиной, чтобы предотвратить взаимодействие нераспознанного процесса контейнера с узлом или другими арендаторами. Изоляция гипервизора обеспечивает эту степень разделения, а также обеспечивает несколько повышений производительности по сравнению с традиционными виртуальными машинами. Поэтому настоятельно рекомендуется, чтобы в враждебных мультитенантных сценариях контейнеры, изолированные гипервизором, должны быть предпочтительным выбором.

Критерии обслуживания безопасности контейнеров

Microsoft привержена исправлению всех эксплойтов и пробоев, которые нарушают установленную границу изоляции любого типа контейнера Windows. Однако только эксплойты, которые нарушают границу безопасности, обслуживаются через процесс Центра реагирования майкрософт (MSRC). Только гипервизор-изолированные контейнеры обеспечивают границу безопасности, а процесс-изолированные контейнеры её не обеспечивают. Единственный способ создать ошибку для выхода из контейнера с изоляцией процесса заключается в том, если не административный процесс имеет возможность получить доступ к хосту. Если эксплойт использует процесс администратора для обхода контейнера, корпорация Майкрософт считает, что это ошибка, не связанная с безопасностью, и исправит ее на обычный процесс обслуживания. Если эксплойт использует неадминистрируемый процесс для выполнения действия, которое нарушает границу безопасности, корпорация Майкрософт будет исследовать его в установленных критериях обслуживания безопасности.

Что делает рабочую нагрузку с несколькими клиентами враждебной?

Многопользовательские среды существуют, когда несколько рабочих нагрузок выполняются на общей инфраструктуре и ресурсах. Если одна или несколько рабочих задач, выполняемых в инфраструктуре, не могут считаться надежными, то многоарендная среда считается небезопасной. Контейнеры Windows Server и Linux совместно используют ядро узла, поэтому любой эксплойт, выполняемый в одном контейнере, может повлиять на все остальные рабочие нагрузки, выполняемые в общей инфраструктуре.

Вы можете предпринять шаги, чтобы снизить вероятность возникновения эксплойтов, например с помощью политик безопасности pod, AppArmor и управления доступом на основе ролей (RBAC), но они не обеспечивают гарантированную защиту от злоумышленника. Мы рекомендуем следовать нашим рекомендациям по изоляции кластера для любого сценария с несколькими клиентами.

Когда использовать учетные записи пользователей ContainerAdmin и ContainerUser

Контейнеры Windows Server предлагают две учетные записи пользователей по умолчанию, ContainerUser и ContainerAdministrator, каждый из которых имеет определенную цель. Учетная запись ContainerAdministrator позволяет использовать контейнер для административных целей: установку служб и программного обеспечения (например, включение IIS в контейнере), внесение изменений в конфигурацию и создание новых учетных записей. Эти задачи важны для ряда ИТ-сценариев, которые могут выполняться в пользовательских локальных средах развертывания.

Учетная запись ContainerUser существует для всех других сценариев, в которых права администратора в Windows не требуются. Например, в Kubernetes, если пользователь является ContainerAdministrator и разрешено монтировать hostvolumes в pod, то пользователь может подключить папку .ssh и добавить открытый ключ. Будучи ContainerUser, этот пример был бы невозможен. Это ограниченная учетная запись пользователя, предназначенная исключительно для приложений, которые не должны взаимодействовать с узлом. Настоятельно рекомендуется, чтобы при развертывании контейнера сервера Windows в любой мультитенантной среде ваше приложение выполнялось через учетную запись ContainerUser. В мультитенантной среде всегда лучше следовать принципу наименьших привилегий, поскольку если злоумышленник взламывает вашу рабочую нагрузку, то общий ресурс и соседние рабочие нагрузки имеют меньше шансов подвергнуться воздействию. Использование контейнеров с учетной записью ContainerUser значительно снижает вероятность компрометации компьютерной среды в целом. Однако это по-прежнему не обеспечивает надежную границу безопасности, поэтому если безопасность является проблемой, следует использовать изолированные от гипервизора контейнеры.

Чтобы изменить учетную запись пользователя, можно использовать инструкцию USER в dockerfile:

USER ContainerUser

Кроме того, можно создать нового пользователя:

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

Службы Windows

Службы Microsoft Windows, ранее известные как службы NT, позволяют создавать длительные исполняемые приложения, работающие в собственных сеансах Windows. Эти службы можно запускать автоматически при запуске операционной системы, можно приостановить и перезапустить, а также не отображать пользовательский интерфейс. Вы также можете запускать службы в контексте безопасности определенной учетной записи пользователя, отличной от пользователя, вошедшего в систему, или учетной записи компьютера по умолчанию.

При контейнеризации и защите рабочей нагрузки, работающей в качестве службы Windows, следует учитывать несколько дополнительных аспектов. Во-первых, ENTRYPOINT контейнера не будет рабочей нагрузкой, так как служба выполняется в качестве фонового процесса, обычно ENTRYPOINT будет инструментом, например монитором служб) или монитором журналов). Во-вторых, учетная запись безопасности, в которой работает рабочая нагрузка, будет настроена службой, а не директивой USER в dockerfile. Вы можете проверить, под какой учетной записью служба будет выполняться, выполнив Get-WmiObject win32_service -filter "name='<servicename>'" | Format-List StartName.

Например, при размещении веб-приложения IIS, использующего образ ASP.NET (Реестра артефактов Майкрософт), ENTRYPOINT контейнера "C:\\ServiceMonitor.exe", "w3svc". Эту утилиту можно использовать для настройки службы IIS, а затем для мониторинга службы, чтобы убедиться, что она продолжает работать. Если по какой-либо причине служба прекращает работу, контейнер останавливается. По умолчанию служба IIS и, таким образом, веб-приложение выполняются под учетной записью с низким уровнем привилегий в контейнере, но средство мониторинга служб требует прав администратора для настройки и мониторинга службы.