В современном мире контейнеров Docker стал популярным решением для развертывания и управления приложениями.
Одним из распространенных вариантов использования является перенаправление сетевого трафика с определенного порта на хост-машине на порт внутри контейнера Docker. Читать
В последние годы искусственный интеллект стал неотъемлемой частью многих сфер жизни. Одним из наиболее захватывающих достижений в этой области стал ChatGPT от OpenAI. Эта мощная модель обученного искусственного интеллекта способна создавать удивительные диалоги и решать различные задачи. В этой статье мы расскажем, как запустить ChatGPT на операционной системе CentOS, предоставляя пошаговую инструкцию. Читать
Нужно было быстренько настроить бэкап mysql базы в docker контейнере. Оказывается, это сделать очень просто. Поделюсь с вами информацией и себе на память сохраню.
Перевод статьи «Say Goodbye to Docker Volumes».
Вы когда-нибудь пытались использовать тома Docker для горячей замены (hot-reloading) в своем веб-приложении? Если вы получили такой же ужасный опыт, как и я, вам понравится новейшая функция, которую только что выпустил Docker: docker-compose watch!
В этой статье я расскажу, как обновить существующий проект, чтобы получить настройку среды разработки в Docker, которая точно понравится вашей команде. Читать
С учетом того, что сегодня число интернет-пользователей поражает воображение, а сами веб-приложения выполняют больше задач, чем когда-либо в прошлом, масштабирование, поддержка и разработка крупных веб-приложений стали серьезной проблемой для команд DevOps.
Теперь, когда приложения масштабируются в нескольких публичных облаках с использованием различных технологических стеков, для их поддержки и развертывания требуются современные решения.
Итак, мы продолжаем статью 🦊 Современное состояние безопасности CI/CD и как предотвратить распространенные ошибки
Среди них популярны контейнерные приложения, обычно использующие такие технологии, как Docker.
Дальнейшее масштабирование стало возможным с появлением таких технологий, как Kubernetes.
Контейнерные приложения позволяют DevOps-командам поддерживать контейнеры с определенными конфигурациями и версиями приложений.
Эта практика также позволяет командам DevOps реплицировать их столько раз, сколько необходимо, и все это в автоматическом режиме.
Сочетание таких технологий, как Kubernetes (которая сделала развертывание, масштабирование и обслуживание контейнерных приложений очень простым) и Docker, зарекомендовало себя как решение для удовлетворения требований современных приложений, что привело к значительному росту их популярности в последнее время.
Однако внедрение новых технологий всегда чревато новыми ошибками и уязвимостями.
Поэтому такой риск требует такого же внимания, как и ручное развертывание, чтобы избежать наплыва уязвимостей, проникающих в ваше контейнерное и автоматизированное развертывание.
Наиболее распространенным источником уязвимостей в таких технологиях, как Docker, Kubernetes и других технологиях автоматизации, таких как SaltStack, Ansible и Puppet, являются устаревшие версии программного обеспечения, а также отсутствие процедур усиления безопасности и надлежащего анализа конфигурации.
Одна из самых основных форм неправильной конфигурации в Docker связана с повышением прав пользователя.
В таких случаях контейнеры Docker, запускаемые от имени root, представляют гораздо более серьезную угрозу безопасности, чем контейнеры, запускаемые не от имени root.
🐳 Почему процессы в контейнерах Docker не должны запускаться от имени Root
Если контейнер запускается под пользователем root и существуют уязвимости безопасности для данной версии Docker, то, например, в прошлом существовали уязвимости, которые позволяли злоумышленникам проникнуть на хост через уязвимое или неправильно сконфигурированное программное обеспечение, запущенное в самом контейнере.
🐳 Что такое Docker без root (rootless)?
Такое уязвимое программное обеспечение также позволяло злоумышленникам выйти из контейнера и проникнуть на хост-сервер, на котором запущен контейнер.
Именно поэтому настоятельно рекомендуется запускать контейнеры под управлением пользователей с нужным количеством разрешений и доступа.
Docker поддерживает работу в режиме пользователя rootless/non-root, что позволяет значительно повысить уровень безопасности, конфигурацию которого можно увидеть в официальном руководстве по Docker.
Место хранения данных – важный момент при работе с контейнерами, такими как Docker, как и знание того, что хранение данных внутри контейнеров часто имеет больше недостатков, чем преимуществ.
Настоятельно рекомендуется хранить любые пользовательские данные вне контейнера; в случае обнаружения уязвимостей контейнер можно уничтожить, обновить и развернуть из чистого состояния.
Это позволяет автоматизировать работу с CVE, поскольку данные не находятся внутри контейнера.
Хранение учетных данных – еще одна частая ошибка конфигурации.
Как и в случае с хранением данных, рекомендуется избегать хранения учетных данных внутри самого контейнера, чтобы в случае возникновения уязвимости контейнер можно было легко обновить и снова запустить без утечки учетных данных.
Монтирование данных вне контейнера легко выполняется с помощью Docker.
Рассмотрим следующую команду Docker run:
В этом примере данные хранятся вне контейнера по пути /etc/todos – таким образом, контейнер работает независимо, позволяя создавать, уничтожать или перемещать контейнер, сохраняя данные как есть и в отдельном пути.
Такие технологии, как Ansible, SaltStack и Puppet, используются для автоматизации задач, которые необходимо выполнять на большом количестве серверов.
Эти технологии используют файлы конфигурации, называемые “плейбуки”, которые содержат информацию о том, что и где должно быть выполнено.
Для работы этих плейбуков необходим доступ к серверам через SSH или аналогичный доступ на уровне консоли.
Однако выполнение этих задачот имени root и/или хранение паролей root в открытом виде в этих конфигурациях может привести к инцидентам, связанным с безопасностью, в случае утечки конфигураций.
Рассмотрим следующий пример.
Чтобы установить MySQL с помощью Ansible:
- hosts: webservers
user: vagrant
sudo: true
vars_files:
- vars.yml
tasks:
- name: Install MySQL
action: apt pkg=$item state=installed
with_items:
- mysql-server-core-5.5
- mysql-client-core-5.5
- libmysqlclient-dev
- python-mysqldb
- mysql-server
- mysql-client
- name: Start the MySQL service
action: service name=mysql state=started
- name: Remove the test database
mysql_db: name=test state=absent
- name: Create deploy user for mysql
mysql_user: user="deploy" host="%" password={{mysql_root_password}} priv=*.*:ALL,GRANT
- name: Ensure anonymous users are not in the database
mysql_user: user='' host=$item state=absent
with_items:
- 127.0.0.1
- ::1
- localhost
- name: Copy .my.cnf file with root password credentials
template: src=templates/.my.cnf dest=/etc/mysql/my.cnf owner=root mode=0600
- name: Update mysql root password for all root accounts
mysql_user: name=root host={{item}} password={{mysql_root_password}}
with_items:
- 127.0.0.1
- ::1
- localhost
Как показано выше, мы можем использовать Ansible для установки определенной версии MySQL (5.5), запуска службы, удаления всех тестовых баз данных, добавления пользователя, удаления всех анонимных пользователей, копирования существующего файла my.cnf и обновления пароля root.
Поскольку пароль root MySQL, различная другая конфиденциальная информация (например, версия MySQL) и имя развернутого пользователя MySQL хранятся прямо в конфигурационном файле, безопасность становится насущной проблемой.
Конфигурация/файлы Docker могут быть идеальной демонстрацией такого рода неправильной конфигурации.
Давайте рассмотрим пример базового официального файла Docker compose (docker-compose.yml), используемого для установки WordPress с MySQL:
version: "3.9"
services:
db:
image: mysql:5.7
volumes:
- db_data:/var/lib/mysql
restart: always
environment:
MYSQL_ROOT_PASSWORD: somewordpress
MYSQL_DATABASE: wordpress
MYSQL_USER: wordpress
MYSQL_PASSWORD: wordpress
wordpress:
depends_on:
- db
image: wordpress:latest
volumes:
- wordpress_data:/var/www/html
ports:
- "8000:80"
restart: always
environment:
WORDPRESS_DB_HOST: db
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: wordpress
WORDPRESS_DB_NAME: wordpress
volumes:
db_data: {}
wordpress_data: {}
Здесь мы видим, что MySQL 5.7 установлен из последнего образа WordPress, доступного на Docker Hub, а также пароль корня MySQL, имя базы данных, имя пользователя и пароль пользователя.
Поскольку конфигурация контейнера Docker перечисляется в виде обычного/человекочитаемого текста, включая пароли к базе данных, пути к данным и файлам, необходимо убедиться не только в надежности хранения файлов, но и в том, что любая часть автоматизированных процессов развертывания обеззараживается при использовании для развертывания контейнеров.
Обнаружение подобных проблем с конфигурацией позволяет blue team предотвратить утечку конфиденциальных данных, которые впоследствии могут быть использованы для осуществления более сложных атак на облачную инфраструктуру.
Rancher – это мультикластерная платформа оркестровки с открытым исходным кодом, которая позволяет операционным командам развертывать, управлять и обеспечивать безопасность корпоративных Kubernetes.
Это программное обеспечение для оркестрации часто становится жертвой неправильной конфигурации; например, учетные данные администратора по умолчанию часто полностью раскрываются, что, в свою очередь, используется злоумышленниками.
Консоль Kubernetes (или дашборд) является важной частью настройки Kubernetes.
Она позволяет получить полный обзор всех контейнеров, управляемых кластером Kubernetes, включая их состояние, использование памяти, других ресурсов, а также различные функции управления.
Раскрытие этой консоли может привести к различным типам атак.
В прошлом открытые консоли использовались для организации майнинга криптовалюты, что может привести к финансовым потерям и замедлению работы приложений из-за потребления ресурсов процессами майнинга криптовалюты.
Инструмент Kubernetes Kustomization используется для настройки объектов Kubernetes с помощью файла “Kustomization”.
Со страницы проектов Kustomize позволяет настраивать необработанные, свободные от шаблонов YAML-файлы для различных целей, оставляя исходный YAML нетронутым и пригодным для использования как есть.
В свою очередь, такая возможность настройки конфигураций делает новые файлы Kustomization довольно мощными, позволяя объединять различные существующие файлы конфигурации Kubernetes.
Однако доступ к этим файлам может привести к утечке большого количества конфиденциальных данных из вашей организации, поэтому очень важно обеспечить постоянную безопасность и дезинфекцию этих файлов.
Правильная настройка этих инструментов необходима для обеспечения безопасности развертывания контейнерных приложений.
В конце концов, недостатки безопасности в этих инструментах могут быть как простыми, например, приборная панель позволяет обходить аутентификацию, так и сложными, например, приборная панель имеет уязвимости безопасности, позволяющие проводить инъекционные атаки shell.
Учитывая уязвимость CVE-2020-16846, затрагивающую SaltStack Salt, программное обеспечение для управления инфраструктурой и оркестровки контейнеров, CVE позволяла осуществлять атаки shell injection при отправке определенных веб-запросов к API SaltStack.
Проще говоря, поскольку уязвимости возможны в стеке управления вашей контейнерной инфраструктурой, безопасность всего вашего контейнерного приложения, вероятно, также находится под угрозой.
Наряду с неизбежным переходом на контейнерные приложения, используемые в организациях для обеспечения более простого управления, быстрого развертывания и эффективного масштабирования веб-приложений, возникают определенные критические проблемы безопасности, которые часто упускаются из виду при рассмотрении различных преимуществ (а иногда и сложностей) управления этими кластерами контейнеров.
Хотя контейнеры доказали, что они помогают обеспечить согласованность, сократить время развертывания и другие проблемы, связанные с версиями и конфигурациями программного обеспечения для разработчиков и производственных инстансов, они также создают извечную проблему обеспечения правильной и безопасной конфигурации.
Это особенно актуально для конфигурационных файлов, содержащих детали, касающиеся каждого аспекта развертываемого программного обеспечения: пути к данным, пароли баз данных и другие учетные данные доступа.
Процессы в контейнере Docker не должны запускаться от имени root.
Безопаснее запускать приложения от имени пользователя, не являющегося root, которое вы указываете в Dockerfile или при использовании docker run.
Это минимизирует риск, так как уменьшает поверхность атаки для любых угроз в вашем контейнере.
В этой статье вы узнаете об опасностях, связанных с запуском контейнерных приложений от имени root.
Вы также увидите, как создать пользователя, не являющегося root, и настроить namespacing в ситуациях, когда это невозможно.
По умолчанию контейнеры запускаются от имени root.
Демон Docker запускается от имени root на вашем хосте, и запущенные контейнеры также будут запускаться от имени root.
Хотя может показаться, что root внутри контейнера является независимым пользователем, на самом деле это то же самое, что и учетная запись root на вашем хосте.
Разделение обеспечивается только механизмами изоляции контейнеров Docker.
Нет прочной физической границы; ваш контейнер – это еще один процесс, запущенный пользователем root на ядре вашего хоста.
Это означает, что уязвимость в вашем приложении, среде выполнения Docker или ядре Linux может позволить злоумышленникам выйти из контейнера и выполнить операции с правами root на вашей машине.
Существуют некоторые встроенные средства защиты, которые снижают риск возникновения такой ситуации.
Root внутри контейнера является непривилегированным и имеет ограниченные возможности. Это не позволяет контейнеру использовать команды системного администрирования, если вы вручную не добавите возможности или не используете привилегированный режим при запуске контейнеров.
Несмотря на эти меры, разрешение запуска приложений от имени root остается опасным.
Так же, как вы ограничиваете использование root в традиционной среде, неразумно без необходимости использовать его в контейнерах.
Вы создаете слишком привилегированную среду, которая дает злоумышленникам больше возможностей в случае взлома.
Наилучшей практикой для контейнерных приложений является запуск от имени обычного пользователя.
Большинству программ не нужен root-доступ, поэтому смена пользователя обеспечивает немедленный уровень защиты от взлома контейнера.
Вы должны создать новую учетную запись пользователя как один из последних этапов в вашем Dockerfile.
Этого можно добиться с помощью инструкции USER:
FROM base-image:latest RUN apt install demo-package USER demo-user:demo-group ENTRYPOINT ["demo-binary"]
Контейнеры, запущенные с этого образа, будут работать под именем demo-user.
Пользователь будет членом группы demo-group.
Вы можете опустить имя группы, если вам не нужно, чтобы пользователь состоял в группе:
USER demo-user
Вместо имен можно указать идентификатор пользователя (UID) и идентификатор группы (GID):
USER 950:950
Выделение известных UID и GID обычно является самым безопасным способом.
Это предотвращает сопоставление пользователя в контейнере с чрезмерно привилегированной учетной записью хоста.
USER часто указывается как предпоследняя ступень в Dockerfile.
Это означает, что вы все еще можете выполнять операции, требующие root, на более ранних этапах сборки образа.
Инструкция apt install в приведенном выше примере имеет законную потребность в root.
Если бы инструкция USER была размещена выше, apt был бы запущен от имени demo-user, который не имел бы необходимых прав.
Поскольку инструкции Dockerfile относятся только к сборкам образов, а не к запущенным контейнерам, безопасно оставить изменение пользователя на более поздний период в Dockerfile.
Изменение пользователя, под которым запускается контейнер, может потребовать обновления разрешений на файлы и папки, к которым он обращается.
Установите права на все пути, которые будут использоваться вашим приложением:
COPY initial-config.yaml /data/config.yaml USER demo-user:demo-group RUN chown demo-user:demo-group /data
В этом примере каталог /data должен принадлежать demo-user, чтобы приложение могло вносить изменения в свой конфигурационный файл.
Предыдущий оператор COPY скопирует файл от имени root.
Можно воспользоваться сокращенным вариантом, используя флаг –chown вместе с copy:
COPY --chown=demo-user:demo-group initial-config.yaml /data/config.yaml
В этом примере каталог /data должен принадлежать demo-user, чтобы приложение могло вносить изменения в свой конфигурационный файл.
Предыдущий оператор COPY скопирует файл от имени root.
Можно воспользоваться сокращенным вариантом, используя флаг –chown вместе с copy:
$ docker run -d --user demo-user:demo-group demo-image:latest $ docker run -d --user demo-user demo-image:latest $ docker run -d --user 950:950 demo-image:latest
FROM image-that-runs-as-root:latest USER demo-user
$ docker build . -t image-that-now-runs-as-non-root:latest
Изменение пользователя стороннего образа может вызвать проблемы: если контейнер ожидает запуска от имени root или нуждается в доступе к путям файловой системы, принадлежащим root, вы увидите ошибки при использовании приложения.
Вы можете попробовать вручную изменить права на пути, вызывающие проблемы.
Кроме того, проверьте, есть ли у поставщика поддерживаемый метод запуска приложения с непривилегированной учетной записью пользователя.
Разделение имен пользователей – это техника работы с приложениями, которым нужны некоторые привилегии root.
Она позволяет сопоставить root внутри контейнера с пользователем, не являющимся root, на вашем хосте.
Имитированный root в контейнере имеет необходимые привилегии, но вынос не даст root-доступа на хост.
Ремаппинг пространства имен активируется путем добавления поля userns-remap в файл /etc/docker/daemon.json:
{
"userns-remap": "default"
}
{
"userns-remap": "demo-user"
}
Перезапустите демон Docker после применения изменений:
Если вы используете nsuser-remap: default, пользователь dockremap теперь должен существовать на вашем хосте:
Пользователь также должен появиться в файлах идентификаторов /etc/subuid и /etc/subgid:
$ dockremap:231500:65535
Пользователю выделен диапазон из 65 535 подчиненных идентификаторов, начиная с 231500.
В пространстве имен пользователей идентификатор 231500 сопоставлен с 0, что делает его корневым пользователем в ваших контейнерах.
Будучи UID с высоким номером, 231500 не имеет привилегий на хосте, поэтому атаки на взлом контейнеров не смогут нанести такой большой ущерб.
Все запущенные вами контейнеры будут работать с измененным пространством имен пользователей, если вы не откажетесь от этого с помощью docker run –userns=host.
Механизм работает путем создания каталогов с разнесенными именами внутри /var/lib/docker, которые принадлежат подчиненным UID и GID пользователя с разнесенными именами:
$ sudo ls -l /var/lib/docker/231500.231500 total 14 drwx------ 5 231500 231500 13 Jul 22 19:00 aufs drwx------ 3 231500 231500 13 Jul 22 19:00 containers ...
Сопоставление имен пользователей – это эффективный способ повысить изоляцию контейнеров, избежать выходов из них и сохранить совместимость с приложениями, которым требуются привилегии root.
Однако есть некоторые недостатки: эта функция лучше всего работает на свежем экземпляре Docker, тома, смонтированные с хоста, должны иметь настроенные разрешения, а некоторые драйверы внешних хранилищ вообще не поддерживают сопоставление пользователей.
Перед использованием этой опции следует изучить документацию.
Запуск контейнерных приложений от имени root представляет собой риск для безопасности.
Хотя это легко упустить из виду, изоляция, обеспечиваемая контейнерами, недостаточно сильна, чтобы полностью отделить пользователей ядра от пользователей контейнера.
Root в контейнере – это тот же root, что и root на вашем хосте, поэтому успешная компрометация может обеспечить контроль над вашей машиной.
Как автор образа, вы должны включить инструкцию USER в свой Dockerfile, чтобы ваше приложение запускалось без root.
Пользователи образа могут отменить эту инструкцию с помощью docker run –user, чтобы назначить определенные UID и GID. Это поможет смягчить ситуацию, когда образ обычно использует root.
Вы можете еще больше усилить безопасность, удалив все возможности из контейнера с помощью –cap-drop=ALL, а затем включив в белый список те, которые необходимы, с помощью флагов –cap-add.
Сочетание этих методов позволит запустить ваше приложение от имени пользователя, не являющегося root, с минимальным набором необходимых привилегий, что повысит уровень безопасности.
см. также: