Devsecops — Как Повысить Осведомленность Об Угрозе Безопасности, Связанной С Запуском Docker?

  • Автор темы RedDeath
  • Обновлено
  • 21, Oct 2024
  • #1

Я готовлю курс Docker для студентов, практически не знакомых с контейнерами, лежащими в их основе механизмами ОС и их подразумеваемыми ограничениями.

Во многих руководствах по Docker вопросы безопасности часто не упоминаются. И легко предположить, что при запуске контейнерного приложения в системе общего назначения не возникает особых проблем с безопасностью.

Со своей стороны, я хотел бы повысить осведомленность студентов об этих проблемах на раннем этапе моего курса. Речь не обязательно идет об обучении их тому, как смягчить эти проблемы. Но на самом деле стоит развеять это заблуждение: Docker по умолчанию безопасен. К сожалению, я не мог себе позволить тратить много времени на изучение этих аспектов.

Итак, я ищу инструменты и/или примеры, которые мои ученики могли бы легко запустить и понять, чтобы они получили представление о возможных последствиях использования Docker для безопасности. Что бы вы предложили?


Чего бы это ни стоило, я сначала подумал о:

#докер #devsecops

RedDeath


Рег
13 Apr, 2006

Тем
82

Постов
180

Баллов
610
  • 25, Oct 2024
  • #2

Вы также можете запустить сканирование на наличие уязвимостей безопасности некоторых примеров базовых изображений, чтобы ваши учащиеся получили представление о том, как изменение базы может повлиять на безопасность вашего образа. Например, сравнение альпийского образа с полноценным образом Ubuntu (особенно с некоторыми старыми образами Ubuntu).

Clair — достойный сканер, который можно настроить довольно легко в докер-контейнерах. Это еще и сканер Использование GitLab для сканера контейнеров если вы используете их платформу CI/CD.

 

-Greg-


Рег
07 Oct, 2006

Тем
60

Постов
186

Баллов
536
  • 25, Oct 2024
  • #3

Инструмент, который, по моему мнению, недостаточно признан с2и. Основная идея заключается в том, что вы не помещаете Dockerfile в репозиторий исходного кода, определяя используемую среду выполнения, вы сохраняете код вашего приложения чистым (только код). Решение о том, какой образ s2i с исправлениями безопасности компилировать и использовать для запуска кода, является отдельным вопросом, который независим и может управляться централизованно.

В мире OKD это используется так: «BuildConfig» извлекает ваш код из git для создания образа приложения и запускается либо веб-книгой git, либо отправкой реестра Docker, которая обновляет образ s2i исправлением безопасности.

В нашем случае у нас есть много приложений Node и PHP. Для исправления безопасности во время выполнения мы помещаем последний образ s2i в наш реестр докеров OKD, что приводит к воссозданию и повторному развертыванию всех образов наших приложений.

Я думаю, что это интересно, так это то, что в нем, по сути, говорится, что не следует смешивать код и то, как он выполняется с точки зрения безопасности контейнера. Это две проблемы, которые не находятся в одной и той же каденции. Уязвимость с высоким уровнем воздействия должна быть исправлена ​​​​в основной тестовой среде немедленно и не зависеть от переговоров с несколькими командами Scrum о внесении изменений в файл Dockerfile в репозиторий git каждой команды.

Если у вас много приложений или много небольших команд разработчиков, разделение контейнеров для «исправления безопасности на основе политик» может быть очень полезным. Вы можете запустить s2i на своем рабочем столе или с помощью инструмента SaaS ci на основе контейнера, такого как кружочки. Было бы несложно запустить его, скажем, в Дженкинсе. Это означает, что вы можете иметь, скажем, десятки микросервисов Jenkins, которые развертывают задания, запускаемые веб-книгой git, которые запускают s2i и отправляют окончательный образ. Затем вы можете управлять версией образа s2i, который вы используете во всех заданиях Jenkins, в одном месте. Затем вы можете создать сценарий обновления безопасности, которое обновляет URL-адрес докера s2i до последнего исправления безопасности и запускает все задания выпуска Jenkins для применения исправленного s2i ко всем микросервисам. Никакой код или конфигурацию не нужно менять ни в одном репозитории git.

Хотя я упоминаю OKD по умолчанию, он не позволяет запускать образ контейнера с uid 0 (root). Он использует случайный uid и gid 0. Это сделано для безопасности на случай, если процесс выйдет из тюрьмы и попытается изменить хост. Большинство общедоступных образов Docker просто ожидают, что вы запустите его от имени пользователя root, а права доступа к файлу не позволяют запускать приложение в образе как произвольный идентификатор пользователя, как /etc/passwd . You have to bake an image that gives gid 0 the file permissions to run the app. The s2i images all work under these circumstances.

Если вам нужны приложения в Docker для поиска сведений об использовании в /etc/passwd when running as a random uid the you can fake that. Здесь это скрипт, который запускает git в докере как случайный uid, где git хочет найти текущий в /etc/passwd so the script fakes it.

Урок здесь, ИМХО, заключается в том, что, хотя теоретически докер обеспечивает идеальную изоляцию, на практике весь код подвержен недостаткам безопасности. Теоретически многие небольшие команды разработчиков будут обновлять все файлы Dockerfile немедленно или очень часто, но на практике команды разработчиков сосредоточены на функциях, а не на долгосрочных исправлениях безопасности. (Я работаю с одной платформой микросервисов, которая в настоящее время имеет более 200 репозиториев git и команды разработчиков на трех континентах, поэтому координация чего-либо является сложной задачей.) Поэтому безопасность должна быть «глубокоэшелонированной защитой» и предпринимать конкретные шаги для централизованного исправления образов контейнеров, а не запускайте контейнеры от имени пользователя root и используйте случайный идентификатор, которого нет на хосте docker —user ${rand_uid}:0 so cannot read or write outside of its jail.

 

KexUnmandamum21


Рег
25 Oct, 2024

Тем
71

Постов
172

Баллов
537
  • 25, Oct 2024
  • #4

По моему опыту, «повышение осведомленности о безопасности» (для людей с техническим складом ума) означает просто показать им проблему в действии.

Выясните, какие конкретные, практические проблемы существуют на самом деле, и просто покажите их (показав на деле или заставив их выяснить это самостоятельно).

Все проблемы безопасности докеров, с которыми я столкнулся, были совершенно очевидными и очевидными, если оглянуться назад. За исключением одной проблемы (до 1.0), когда изначально был черный список для вызовов ядра вместо белых списков, большинство других проблем можно легко показать с помощью конфигурации, изображений в стиле hello world или острого размышления («действительно ли мы хотим использовать образ IAmNotEvil/SpecialUbuntuDistribution из dockerhub вместо официального, и как мы узнаем, что официальный образ хороший?").

Да, и для более полного обсуждения не забудьте показать им, в каких аспектах работает Docker. более безопасный (или более безопасный), чем простой сервер...

 

Vlad_kondor


Рег
16 Feb, 2012

Тем
74

Постов
203

Баллов
593
Похожие темы Дата
Тем
403,760
Комментарии
400,028
Опыт
2,418,908

Интересно