​​Для автоматической проверки Docker образов на уязвимости (CVE) есть хороший open source инструмент Trivy. Год назад я делал по нему пару заметок с обзором и автоматическим исправлением уязвимостей. Потом всё это в небольшую статью оформил.

Этот продукт хорошо дополняет open source утилита Dockle. Она тоже проверяет контейнеры на уязвимости, но помимо этого проверяет образ на соответствие best-practice Dockerfile и рекомендации CIS Docker Benchmarks (#cis).

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

# docker run --rm goodwithtech/dockle:v0.4.14 [YOUR_IMAGE_NAME]

Пример отчёта можно посмотреть на тестовом образе, для которого есть замечания:

# docker run --rm goodwithtech/dockle:v0.4.14 goodwithtech/dockle-test:v2

С помощью ключа -f json вывод можно сохранить в json файле. Dockle легко интегрировать в пайплайн. В репозитории есть примеры (gitlab).

⇨ Исходники

#docker #devops #cicd #security

​​Если вам нужно продебажить какой-то контейнер, в котором нет никаких инструментов для диагностики (а это почти всегда так), то для этого можно воспользоваться специально собранным для этих целей контейнером - Network-Multitool. Его ещё любят в кубернетисе запускать для отладки. Известная штука.

Работает он примерно так. Запускаем контейнер, внутри которого ничего нет, кроме nginx:

# docker run --name nginx -d -p 8080:80 nginx
# docker exec -it nginx bash
# ps axf
bash: ps: command not found

Подключаем к нему network-multitool:

# docker run --rm -it \
--network=container:nginx \
--pid container:nginx \
wbitt/network-multitool:alpine-extra bash

# ps axf
  PID TTY   STAT  TIME COMMAND
   47 pts/0  Ss   0:00 bash
   60 pts/0  R+   0:00 \_ ps axf
   1 ?    Ss   0:00 nginx: master process nginx -g daemon off;
   29 ?    S   0:00 nginx: worker process
   31 ?    S   0:00 nginx: worker process
   30 ?    S   0:00 nginx: worker process
   32 ?    S   0:00 nginx: worker process

Дальше всё остальное можно запускать: ping, dig, tcpdump и т.д.

Я тут выбрал самую жирную сборку alpine-extra, где максимальный набор инструментов, в том числе tshark, ApacheBench, mysql & postgresql client, git и т.д. Если всё это не надо, то используйте alpine-minimal. Описание сборок в репозитории.

Похожую функциональность имеет cdebug. У него принцип работы такой же, только он для удобства собран в бинарник. А подключается он к контейнерам точно так же.

Кстати, с помощью network-multitool можно и хост дебажить, если не хочется его засорять различными утилитами. Запускаем его в сети хоста и пользуемся:

# docker run --rm -it --network=host wbitt/network-multitool:alpine-extra bash
# tcpdump

На хост ничего ставить не надо. Полезная штука, берите на вооружение.

#docker #devops

​​К обоим заметкам на тему дебага Docker контейнеров, когда мы к ним цепляемся и запускаем различные утилиты, были комментарии на тему того, что можно просто подключиться к пространству имён (namespace) контейнера с хоста и запустить всё, что нужно. Вот мои прошлые заметки по этой теме:

- Network-Multitool
- Cdebug

Мне лично идея со специальными контейнерами кажется более удобной, потому что там все инструменты уже собраны и на сам хост ничего ставить не надо. Но для полноты картины расскажу и про способ с namespaces. Там всё очень просто.

Узнаём PID процесса в контейнере nginx:

# docker inspect -f '{{ .State.Pid }}' nginx
1009

Запускаем нужную нам утилиту в пространстве контейнера:

# nsenter -n -t 1009 netstat -tulnp

Соответственно, видим процесс nginx, слушающий 80-й порт. Так можно любую утилиту с хоста запустить. Вот вариант в одну строку:

# nsenter -n -t $(docker inspect -f '{{ .State.Pid }}' nginx) ip a

Сразу увидели ip адрес контейнера. Это то же самое, что:

# docker inspect -f '{{ .NetworkSettings.Networks.bridge.IPAddress }}' nginx

Какую команду проще и быстрее запомнить, судить не берусь. Правда, конкретно с IP я смотрю вот так:

# docker inspect nginx | grep IP

Сразу видно адрес. Думаю, идею поняли. Вот ещё пример. Надо посмотреть, как и через какой dns контейнер резолвит домены:

# nsenter -n -t $(docker inspect -f '{{ .State.Pid }}' nginx) dig ya.ru MX

Вообще, про nsenter и в целом про namespaces имеет смысл отдельную заметку написать. Думаю, сделаю это в ближайшее время.

#docker

​​В пятницу рассказывал про ролик, где показан запуск системы Windows через Docker контейнер. Меня заинтересовала эта штука, так что решил сразу попробовать, как это работает. А работает неплохо, мне понравилось.

Есть репозиторий, где всё подробно описано:

⇨ https://github.com/dockur/windows

Я решил попробовать работу этого проекта на обычной виртуальной машине Proxmox, где включена вложенная виртуализация. Для виртуалки тип процессора установил host. Больше никаких особенных настроек не делал.

Скопировал себе репозиторий и запустил дефолтный docker compose:

# git clone https://github.com/dockur/windows
# cd windows
# docker compose up

Был создан и запущен контейнер с Windows 11. Ничего не заработало, так как контейнер не смог загрузить образ системы, о чём сообщил в консоли. Там же была информация о том, что с моего IP нельзя выполнить загрузку. Судя по всему это работает блокировка Microsoft. Можно скачать образ вручную и подсунуть его контейнеру. Мне не захотелось заморачиваться.

Я просто изменил систему на Windows 10, добавив в окружение переменную, как показано в репозитории.

version: "3"
services:
 windows:
.................................
  environment:
   VERSION: "win10"
.................................

И запустил ещё раз. На удивление, всё прошло успешно. Стартовал контейнер, загрузил образ системы, развернул его, выполнив стандартную установку. За процессом можно наблюдать через веб интерфейс, зайдя по ip адресу сервера, указав порт 8006. Участие не требуется, всё выполняется автоматически. Никаких ключей вводить не надо. На выходе будет неактивированная, полностью легальная система.

Длилось всё это минут 30. На хосте должно быть достаточно свободного места и ресурсов системы. По умолчанию контейнеру выделяется 2 CPU, 4 GB памяти и 64 GB диска. Эти настройки можно изменить через environment.

У меня первый раз не хватило места на диске, второй раз память закончилась. Тогда я всё же сходил в репозиторий и уточнил информацию по ресурсам, которые требуются.

После запуска системы, с ней можно работать через браузер, либо по RDP. Специально ничего настраивать не надо. По RDP можно подключиться, указать пользователя docker, пароль пустой.

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

Работает всё это на базе KVM. От Docker тут только автоматизация запуска и управления.

#windows #docker

​​Западные блокировки в интернете добавляют лишнюю суету в повседневную работу. Я вам покажу очень простой и быстрый способ, как их обходить на примере загрузки и запуска продуктов elastic. Как известно, с территории РФ их скачать невозможно, как и воспользоваться репозиторием docker образов.

Для этого нам понадобится любая VPS и доступ к ней по SSH. Главное, чтобы с неё ничего не блокировалось. Ставим туда локальную прокси privoxy:

# apt install privoxy

Больше можно ничего не настраивать. Нам подойдут настройки по умолчанию. Прокси сама запустится на локальном интерфейсе 127.0.0.1:8118. Можно тут её оставить на постоянную работу.

Теперь идём на сервер, куда мы хотим установить elasticsearch. Если мы просто попытаемся скачать пакет, у нас ничего не выйдет:

# wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-8.13.2-amd64.deb
HTTP request sent, awaiting response... 403 Forbidden

Доступ заблокирован. Подключимся по SSH к серверу с privoxy и пробросим её порт 8118 локально на машину на порт 3128:

# ssh -L 3128:localhost:8118 root@1.2.3.4

Проверяем, что порт проброшен:

# ss -tulnp | grep 3128
tcp  LISTEN 0   128    127.0.0.1:3128    0.0.0.0:*  users:(("ssh",pid=1350,fd=5))

Теперь сделаем так, чтобы wget работал через прокси. Для этого рисуем конфиг ~/.wgetrc:

use_proxy=yes
http_proxy=127.0.0.1:3128
https_proxy=127.0.0.1:3128

И снова скачиваем пакет. Теперь он успешно загрузится, можно устанавливать.

Если хочется запустить elasticsearch в докере из официального образа, то подключаем прокси докеру. Для этого передаём ему переменные через systemd. Все возможные варианты настройки прокси в докере описаны в документации.

# mkdir -p /etc/systemd/system/docker.service.d
# mcedit /etc/systemd/system/docker.service.d/http-proxy.conf

[Service]
Environment="HTTP_PROXY=http://127.0.0.1:3128"
Environment="HTTPS_PROXY=http://127.0.0.1:3128"

 # systemctl daemon-reload
 # systemctl restart docker

Обращаю внимание, что в качестве HTTPS_PROXY я передаю http подключение. Это важно. Privoxy не настроен на работу по https, а Docker хочет именно по https забирать образы. Проверим, что переменные объявлены:

# systemctl show --property=Environment docker
Environment=HTTP_PROXY=http://127.0.0.1:3128 HTTPS_PROXY=http://127.0.0.1:3128

Теперь можно забрать образ последней версии и запустить его:

# docker pull docker.elastic.co/elasticsearch/elasticsearch:8.13.2
# docker run -d -e "discovery.type=single-node" \
  -p 9200:9200 \
  -p 9300:9300 \
   docker.elastic.co/elasticsearch/elasticsearch:8.13.2

После того, как всё скачано и запущено, настройки прокси можно отключить.

Такой простой и быстрый метод с использованием своего прокси. Не надо искать сторонние репозитории или настраивать свои. Не надо подключать VPN и что-то ставить дополнительно на исходный сервер. Забрали всё с репозитория разработчиков, сделав минимум движений на сервере, куда всё устанавливали.

#elk #ssh #docker

​​Подбиваю старые полезные публикации, которых накопилось очень много за несколько лет. В этот раз решил сделать подборку на тему Docker. Сначала список наиболее часто используемых команд на основе личного опыта. А в конце ссылки на другие публикации по этой теме.

🟡 Установка Docker:

curl -o - https://get.docker.com | bash -

🟡 Запуск контейнера в режиме службы на конкретном порту с автоматическим запуском при загрузке сервера:

docker run -d -p 80:80 --restart always --name nginx-proxy nginx

🟡 Просмотр списка запущенных и всех контейнеров:

docker ps
docker ps -a

🟡 Удаление остановленного или работающего контейнера:

docker rm nginx-proxy
docker rm -f nginx-proxy

🟡 Остановить и удалить все контейнеры:

docker stop $(docker ps -a -q)
docker rm $(docker ps -a -q)

🟡 Просмотр образов, удаление одного или сразу всех:

docker images
docker rmi nginx
docker rmi $(docker images -a -q)

🟡 Вход в консоль контейнера:

docker exec -it nginx-proxy bash

🟡 Просмотр всех логов контейнера, 100 последних строк или следить за ними:

docker logs nginx-proxy
docker logs -n 100 nginx-proxy
docker logs -f nginx-proxy

🟡 Статистика потребляемых ресурсов контейнера или группы контейнеров:

docker stats nginx-proxy
docker stats prometheus exporter
docker stats prometheus --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}"

🟡 Просмотр запущенных процессов в контейнере:

docker top nginx-proxy

🟡 Информация о контейнере и пример выборки из неё разными способами:

docker inspect nginx-proxy
docker inspect -f '{{ .NetworkSettings.Networks.bridge.IPAddress }}' nginx-proxy
docker inspect --format '{{json .Mounts}}' grafana | jq .

🟡 Проверить занимаемое место докером:

docker system df

🟡 Очистить неиспользуемые данные:

docker system prune

🟡 Скопировать файл с контейнера на хост и наоборот:

docker cp nginx-proxy:/etc/nginx/nginx.conf ~/nginx
docker cp ~/nginx/nginx.conf nginx-proxy:/etc/nginx

🟡 Экспорт файловой системы контейнера:

docker export nginx-proxy -o ~/nginx-proxy.tar.gz

📌 Заметки по теме:

🔥 Portainer - веб панель для Docker
▪️ Локальный репозиторий docker образов - Nexus
▪️ Работа Docker daemon через http proxy
▪️ Дебаг контейнеров с помощью Network-Multitool
▪️ Диагностика работы контейнеров с помощью cdebug
▪️ Доступ к Docker daemon socket извне
▪️ Посмотреть, с какими параметрами был запущен контейнер
▪️ Линтер для Dockerfile - Hadolint
▪️ Sinker - синхронизации образов Docker из одного репозитория в другой
▪️ Дамп mysql базы из докер контейнера

📊 Мониторинг одиночного хоста с Docker
📊 Сtop - top для контейнеров
📊 Мониторинг Docker с помощью Zabbix

🛡 Рекомендации CIS по настройке Docker
🛡 Автоматическое исправление уязвимостей с помощью Copacetic
🛡 Проверка образов на уязвимости с помощью Trivy
🛡 Проверка образов с помощью Dockle
🛡 Заблокировать на файрволе доступ к контейнерам извне

🎓 Основы Docker. Большой практический выпуск для новичков
🎓 Бесплатный тренажёр для изучения Docker
🎓 Отличия Docker от LXC

🗃️ Бэкап вольюмов с помощью Docker-volume-backup
🤔 Docker Desktop for Windows

#docker #подборка

​​Если вдруг вам хочется чего-нибудь странного, то могу вам кое-что предложить. Например, запустить контейнеры Docker в LXC контейнере Proxmox. Я изначально думал, что это так просто не сработает. Всегда запускаю контейнеры в виртуалках. Тут решил попробовать в LXC, сразу заработало.

Создаёте обычный LXC контейнер с нужными ресурсами. В параметрах через веб интерфейс необходимо установить nesting=1. Далее запускаете его и устанавливаете Docker:

# apt install curl
# curl https://get.docker.com | bash -
# docker run --rm hello-world

Hello from Docker!
This message shows that your installation appears to be working correctly.

Всё работает. Никаких дополнительных настроек делать не пришлось. Проверял на Proxmox VE 8.2.2. В принципе, удобно. Получается можно спокойно в LXC изолировать контейнеры и запускать их. Мне казалось, что раньше это так не работало.

#proxmox #docker

​​Недавно посмотрел видео про Diun (Docker Image Update Notifier). Это маленькая консольная утилита, которая делает одно простое действие - проверяет наличие обновлений для образов запущенных контейнеров на хосте. Если обновление есть, уведомляет через email, telegram, gotify, slack и другие каналы. Больше ничего не делает, не качает обновление, не применяет, не перезапускает образ.

Diun состоит из одного бинарника. Запустить можно как на хосте, создав службу systemd, так и в контейнере, прокинув туда docker.sock. Процесс описан в документации:

# docker run -d --name diun \
 -e "TZ=Europe/Moscow" \
 -e "DIUN_WATCH_WORKERS=20" \
 -e "DIUN_WATCH_SCHEDULE=0 */6 * * *" \
 -e "DIUN_WATCH_JITTER=30s" \
 -e "DIUN_PROVIDERS_DOCKER=true" \
 -e "DIUN_NOTIF_TELEGRAM_TOKEN=1493678911:AAHtETAKqxUH8ZpyC28R-wxKfvH8WR6-vdNw" \
 -e "DIUN_NOTIF_TELEGRAM_CHATIDS=211805263" \
 -v "$PWD/data:/data" \
 -v "/var/run/docker.sock:/var/run/docker.sock" \
 -l "diun.enable=true" \
 crazymax/diun:latest

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

Diun умеет следить за актуальностью образов запущенных Docker контейнеров, образов подов в Kubernetes, Swarm, Nomad. Также можно настроить наблюдение за образами, используемыми в определённых Dockerfiles или конфигурационных файлах yaml, где указаны образы.

Простая, маленькая, удобная утилита. Описание установки, настройки, работы:
▶️ Diun - это вам не watchtower

⇨ Сайт / Исходники

#docker #devops

​​Вчера свершилось знаменательное событие - заблокировали доступ к hub.docker.com с IP адресов в России. Теперь без лишних телодвижений не скачать образы из этого репозитория. Не очень понятно, зачем это сделали, почему только сейчас и в чём тут смысл, если обойти эту блокировку, как и многие другие, не представляет каких-то проблем.

Расскажу несколько простых разных способов обхода этой блокировки.

1️⃣ Самый простой - переключиться на какое-то зеркало. Их сейчас много появится и встанет вопрос доверия к ним. Пока можно гугловское зеркало использовать, но его скорее всего тоже рано или поздно для нас заблокируют. Для этого достаточно создать конфиг /etc/docker/daemon.json, если у вас его нет, следующего содержания:

{ "registry-mirrors": ["https://mirror.gcr.io"] }

Перезапускаем службу и пользуемся, как раньше.

# systemctl restart docker

Больше ничего менять не надо.

2️⃣ Использовать локально подключение докера к своему реджистри через прокси. Недавно я об этом рассказывал и там многие написали, типа зачем всё это, доступ не заблокирован. Потому что не будет вашего итальянского сыра ХАХАХАХА. Сегодня этот реджистри, завтра все остальные. Прокси тоже относительно просто решает вопрос для единичного хоста.

3️⃣ Можно глобально на общем шлюзе настроить VPN подключение к серверу за пределами РФ, маркировать весь трафик, что блокируется и отправлять его через VPN соединение. Я так делаю дома для себя и своих тестовых стендов. Рассказывал про эту настройку на примере Mikrotik.

4️⃣ Поднять собственный прокси для докера, который будет иметь доступ к hub.docker.com. Не важно, как это будет сделано у него: через VPN он будет подключаться, или сразу поднят на VPS за пределами РФ. Вы со своей стороны будете подключаться к этому прокси, а он будет по вашим запросам загружать образы.

Проще всего подобный прокси поднять с помощью Nexus repository. Показываю, как это сделать. Я сразу взял VPS за пределами РФ и развернул там:

# docker volume create --name nexus-data
# docker run -d -p 8081:8081 -p 8082:8082 --name nexus \
-v nexus-data:/nexus-data sonatype/nexus3

В файле /var/lib/docker/volumes/nexus-data/_data/admin.password смотрим пароль от пользователя admin. Идём в веб интерфейс Nexus по IP адресу сервера на порт 8081.

Переходим в раздел управления и добавляем новый репозиторий. Тип выбираем docker (proxy). Если вы сами к прокси будете подключаться через VPN или проксировать к нему запросы через ещё какой-то прокси, типа Nginx или HAproxy, то можно в свойствах репозитория выбрать только HTTP и порт 8082. Это упростит настройку. Рекомендую идти именно по этому пути, чтобы ограничить тем или иным способом доступ к этому репозиторию. Вы же не будете его открывать в общий доступ для всех. В таком случае можно будет установить флаг Allow anonymous docker pull. Не нужно будет на всех хостах аутентификацию проходить.

В качестве Remote Storage можно указать https://registry-1.docker.io. Это докеровский репозиторий. Остальные настройки можно оставить по умолчанию, либо изменить в зависимости от ваших предпочтений.

Также зайдите в раздел Security ⇨ Realms и добавьте Docker Bearer Token Realm. Без него аутентификация в реджистри не будет работать.

После создания репозитория, можно его открыть. Там будет показан его url в зависимости от ваших настроек порта, http и адреса самого Nexus. Теперь его можно использовать в настройках /etc/docker/daemon.json:

{
    "insecure-registries": ["10.105.10.105:8082"],
    "registry-mirrors": ["http://10.105.10.105:8082"]
}

Перезапускайте службу Docker и пробуйте. Можно аутентифицироваться в своём реджистри и что-то загрузить:

# docker login 10.105.10.105:8082
# docker pull nginx

Идём в веб интерфейс Nexus, смотрим обзор репозитория и видим там скачанный образ Nginx.

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

#devops #docker

​​Я некоторое время назад сделал подборку основных команд, которые использую при работе с Docker. За последнее время в комментариях увидел несколько команд для Docker Compose, которые сам не знал, но они полезны. Решил сделать такую же подборку и для Docker Compose. Сам их все не помню и либо лезу в свою шпаргалку, либо начинаю гуглить. Я тут не привожу самые очевидные команды, типа start, stop, restart с разными ключами и т.д.

📌 Запустить часть контейнеров:

# docker compose up ct1 ct2

📌 Проверить файл конфигурации. Не знал об этой команде и всегда использовал внешние линтеры. Встроенный намного удобнее.

# docker compose config

📌 Запустить новый контейнер и выполнить в нём команду:

# docker compose run ct1 /scripts/start.js

📌 Запустить команду в работающем контейнере:

# docker compose exec ct1 bash

Поясню, в чём тут разница. На первый взгляд команды похожи. Run удобно использовать для выполнения какой-то команды из контейнера, который постоянно не запущен. Например, там какой-то один бинарник или скрипт, который запускается, отрабатывает и больше он не нужен. Удобно запустить его через run. Новый контейнер запустится, отработает и завершит работу. А exec удобно использовать, когда надо что-то запустить в работающем контейнере. Это аналог docker exec.

📌 Посмотреть все логи или логи контейнера:

# docker compose logs
# docker compose logs ct1

📌 Скопировать файлы из/в контейнер:

# docker compose cp prometheus:/etc/prometheus/prometheus.yml ~/
# docker compose cp ~/prometheus/prometheus.yml prometheus:/etc/prometheus/

Последняя команда скопирует файл только если он лежит в директории с docker-compose.yml, который запущен.

📌 Приостановить и запустить контейнеры:

# docker compose pause
# docker compose unpause

Для приостановки контейнеров используется механизм cgroups freezer. Процессам отправляется команда SIGSTOP для заморозки и SIGCONT для продолжения работы.

📌 Посмотреть список запущенных контейнеров:

# docker compose top

📌 Посмотреть графическую схему всего docker-compose. Используется экспериментальная возможность экспорта содержимого композа в формат программы graphviz:

# docker compose alpha viz --networks --ports --image

Копируем полученный текст и вставляем в любой публичный онлайн редактор graphviz, например этот. Получаем наглядную схему связей контейнеров вместе с сетями и проброшенными портами. Удобно посмотреть на большой конфиг. Например, от mailcow.

📌Выполнить тестовую отработку команды без реальных действий:

# docker compose cp prometheus:/etc/prometheus/prometheus.yml ~/ --dry-run

Можно добавлять --dry-run к любой команде. Актуально для копирования файлов, так как там легко ошибиться с путём или файлом.

Полный набор всех команд и возможностей Docker Compose можно посмотреть в документации:

⇨ https://docs.docker.com/compose/reference

#docker

​​Я в своё время, когда познакомился с CIS — Center for Internet Security, изучил некоторые их документы по настройке софта, с которым работаю. Вот список заметок:

▪️ Nginx
▪️ MySQL 5.7
▪️ Apache 2.4
▪️ Debian 11
▪️ Docker
▪️ Ubuntu 22.04 LTS
▪️ PostgreSQL 16

На основе документа CIS Docker Benchmark v1.6.0 (доступ только через VPN) создан open source продукт, который проверяет Docker контейнеры и настройки самой службы - Docker Bench for Security. Покажу, как им пользоваться.

Можно просто запустить скрипт на хосте и посмотреть его замечания и рекомендации:

# git clone https://github.com/docker/docker-bench-security.git
# cd docker-bench-security
# sh docker-bench-security.sh

Вот несколько замечаний, которые я получил на тестовом сервере. Это не всё, что там было, показываю просто для примера:

[WARN] 1.1.1 - Ensure a separate partition for containers has been created
[WARN] 1.1.3 - Ensure auditing is configured for the Docker daemon
[WARN] 2.2 - Ensure network traffic is restricted between containers on the default bridge
[WARN] 2.13 - Ensure centralized and remote logging is configured
[WARN] 4.5 - Ensure Content trust for Docker is Enabled

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

Похожую проверку можно запустить через Docker. Это тот же скрипт, но упакованный в контейнер, который тут же будет собран:

# docker-compose run --rm docker-bench-security

Проверки можно разделить и не делать сразу все. К примеру, запускаем только проверки образов и runtime:

# sh docker-bench-security.sh -c container_images,container_runtime

Для проверки конкретного образа, достаточно его указать при запуске скрипта. Образ должен быть скачан. Будут выполнены все проверки, в том числе хоста. При проверке образа это скорее всего не нужно. Имеет смысл сразу указать, что нас интересует только 4-й раздел проверок, относящихся к образам:

# docker image pull nginx
# sh docker-bench-security.sh -i nginx -c container_images

Напомню, что есть похожий инструмент Dockle, писал про него. Он делает примерно то же самое, но только для образов. Саму систему и службу docker не проверяет. Конкретно для образов он удобнее и информативнее, чем Docker Bench for Security, потому что проверяет не только по CIS, но и некоторым другим рекомендациям. Увидеть разницу проверок можно на тестовом образе от Dockle:

# docker run --rm goodwithtech/dockle:latest goodwithtech/dockle-test:v2
# sh docker-bench-security.sh -i dockle-test -c container_images

У Dockle вывод более подробный с большим числом замечаний. Эти проверки имеет смысл использовать в тандеме. Docker Bench for Security для хоста и службы, Docker для образов.

#cis #docker #devops

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

Решение такое. Образ надо скачать, создать контейнер, но не запускать его.

# docker pull nginx:latest
# docker create --name nginx nginx:latest

Теперь можно забрать нужный файл:

# docker cp nginx:/docker-entrypoint.d/30-tune-worker-processes.sh ~/

Либо выгрузить всё содержимое образа:

# docker export nginx -o ~/nginx-docker.tar.gz

Заодно расскажу про один полезный инструмент, который рекомендую сохранить тем, кто работает с Docker. Dive - небольшая утилита на Go, которая позволяет просматривать слои образов и видеть, в каком слое что добавилось. У утилиты простой и наглядный tui интерфейс.

Можно скачать бинарник dive из репозитория или запустить сразу в докере и посмотреть нужный тебе образ:

# docker run -ti --rm -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive nginx:latest

Увидите структуру файловой системы с подсветкой цветом разных слоёв. Если постоянно работаете на своей машине с образами, сделайте alias:

alias dive="docker run -ti --rm -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive"

Теперь можно просматривать образы так:

# dive nginx:latest

Удобная штука. Помимо отображения слоёв, она умеет проверять, не раздут ли размер образа из-за неправильных инструкций для сборки. Для этого можно собрать образ с помощью dive и сразу же получить результат анализа. То есть вместо docker build делаем dive build и получаем оценку. Подобную проверку можно встроить в CI систему и выполнять автоматически. В репозитории приведены примеры.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#docker #devops