Docker прошел долгий путь, последовательно стремится создать высокофункциональный, но безопасный продукт, демонстрируя лучшие практики и высоко реагируя на любую уязвимость или проблемы.
С момента своего создания Docker значительно увеличил число внедрений в годовом исчислении.
При настройке, Docker становится мощным активом.
Бремя обеспечения безопасности вашей контейнерной среды заключается не только в том, чтобы укрепить контейнеры или серверы, в которых они в конечном итоге работают, но и должны быть стратегическими, чтобы заботиться о каждом незначительном действии прямо из вытягивания изображения контейнера из реестра в момент нажатия на контейнер в мир производства.
Поскольку контейнеры обычно развертываются со скоростью DevOps как часть структуры CI / CD, необходимо автоматизировать больше задач, которые повышают эффективность, производительность, аудит / протоколирование и, следовательно, обработку проблем безопасности.
Ниже приводится обзор передовых методов, связанных с безопасностью, которые вы должны соблюдать при работе с Docker.
Аутентичный образ Docker
Много раз разработчики ставили использовать базовые изображения Docker, а не перестраивали с нуля.
Но загрузка этих образов из ненадежных источников может привести к уязвимости системы безопасности.
- Использование базового образа из надежных источников, таких как Docker Hub, который хранит образа, которые сканируются и просматриваются службой сканирования Docker.
- Использование базового изображения, подписанного цифровой подписью Docker Content Trust, которое защищает от подделки.
Авторизованный доступ
Во время работы в больших командах важно настроить управление доступом на основе ролей (RBAC) для вашего стека контейнеров Docker.
Крупная корпоративная организация использует решения каталогов, такие как Active Directory, для управления доступом и разрешениями для приложений по всей организации.
Крайне важно иметь хорошее решение для управления доступом к Docker, которое позволяет контейнерам работать с минимальными привилегиями и доступом, необходимыми для выполнения поставленной задачи, что, в свою очередь, снижает фактор риска.
Это помогает обеспечить масштабируемость с ростом числа пользователей.
Управление конфиденциальной информацией
Согласно сервису Docker Swarm, секреты являются чувствительной частью данных, которые не должны передаваться или храниться в незашифрованном виде в Dockerfile или исходном коде приложения.
Секреты представляют собой конфиденциальную информацию, такую как пароли, ключи SSH, токены, сертификаты TLS и т. д.
Секреты шифруются во время транзита в рое Docker.
Секрет доступен только для служб, которым был явно предоставлен доступ, и только когда эти службы запущены.
Необходимо убедиться, что секреты должны быть доступны только для соответствующих контейнеров и не должны подвергаться воздействию или храниться на уровне хоста.
Безопасность на уровне кода и приложений Runtime Security
Безопасность докеров начинается с уровня хоста, поэтому важно поддерживать обновление операционной системы хоста.
Кроме того, процессы, запущенные внутри контейнера, должны иметь самые последние обновления, включив в них лучшую практику кодирования, связанную с безопасностью.
Вы должны в основном убедиться, что контейнеры, которые установлены сторонними поставщиками, ничего не загружают и ничего не запускают во время выполнения.
Все контейнеры Docker должны быть объявлены и включены в образ статического контейнера.
Разрешения namespaces и cgroup должны быть оптимально применены для изоляции доступа и для контроля того, что каждый процесс может изменить.
Контейнеры соединяются друг с другом через кластер, что делает их связь ограничивающей видимость для брандмауэров и сетевых инструментов.
Использование наносегментации может быть находчивым для ограничения радиуса взрыва в случае атак.
Полное управление жизненным циклом
Безопасность контейнера заключается в том, как вы обрабатываете жизненный цикл контейнера, который включает в себя право на создание, обновление и удаление контейнеров.
Контейнеры должны рассматриваться как неизменные, а не изменять или обновлять запущенный контейнер с помощью обновлений, создавать новый образ и тщательно тестировать эти контейнеры на уязвимости и заменять существующие контейнеры.
Ограничение ресурсов
Docker – это легкие процессы, потому что вы можете запускать больше контейнеров, чем виртуальных машин.
Это полезно для оптимального использования ресурсов хоста.
Хотя это может вызвать угрозу уязвимостей, таких как отказ от обслуживания, которые могут быть устранены путем ограничения системных ресурсов, которые могут потреблять отдельные контейнеры через инфраструктуру контейнера, например, Swarm.
Мониторинг активности контейнеров
Как и в любой другой среде, важно постоянно следить за действиями пользователя вокруг вашей экосистемы контейнера, чтобы выявлять и устранять любые вредоносные или подозрительные действия.
Журналы аудита должны быть включены в приложение для записи событий, например, когда учетная запись была создана и активирована, с какой целью, когда последний пароль обновлен и аналогичные действия на уровне организации.
Внедрение таких контрольных маршрутов вокруг каждого контейнера, который вы создаете и развертываете для вашей организации, станет хорошей практикой для выявления вредоносного вторжения.
Вывод
Docke построен с учетом лучшей практики безопасности, поэтому безопасность не является проблемой в контейнерах.
Благодаря появлению новых обновлений и улучшений и внедрению этих функций, вы сможете создавать безопасные приложения.
Использование аспектов безопасности контейнера, таких как изображения контейнеров, права доступа, сегментация контейнеров, секреты и управление жизненным циклом в ИТ-практике, могут обеспечить оптимизированный процесс DevOps с минимальными проблемами безопасности.
