Docker: docker и iptables или файерволы

По умолчанию, docker daemon модифицирует iptables правила файервола без какого-либо уведомления или согласования с администратором. Для этого он используте к примеру цепочку с именем DOCKER и не только.

1
2
3
4
5
6
7
Chain FORWARD (policy DROP)
target     prot opt source               destination
DOCKER     all  --  0.0.0.0/0            0.0.0.0/0
...

Chain DOCKER (1 references)
target     prot opt source               destination

Более того, когда вы указываете docker открывать порт контейнера, он открывает его всему миру, нарушая ваши возможные правила iptables. Итак … если вы запускаете docker на хосте, на котором уже установлен брандмауэр на основе iptables, вам, вероятно, следует установить –iptables = false. Давайте возьмем пример. Вы хотите запустить nginx и связать containerPort 80 с hostPort 9090:

1
docker run --name some-nginx -d -p 9090:80 nginx

За сценой он добавляет правило iptables в цепочку фильтров DOCKER:

1
2
3
4
5
6
7
8
Chain FORWARD (policy DROP)
target     prot opt source               destination
DOCKER     all  --  0.0.0.0/0            0.0.0.0/0
...

Chain DOCKER (1 references)
target     prot opt source               destination
ACCEPT     tcp  --  0.0.0.0/0            172.17.0.2           tcp dpt:9090 <-- это было добавлено при запуске контейнера

Теперь порт 9090 доступен со всего мира. Потому что мы слушаем 9090 на любых IP-адресах (‘0.0.0.0)’из-за правил пересылки, которые динамически добавляются в цепочку фильтров DOCKER. Обратите внимание, что правила пересылки docker разрешают все внешние IP-адреса по умолчанию. Вы, вероятно, не хотите этого. Возможно, вы захотите публиковать порты только локально, а не в ‘0.0.0.0’, для внутреннего использования. Давайте прочитаем документацию по docker-run:

1
2
3
4
5
-p=[]      : Publish a container&#39;s port or a range of ports to the host
               format: ip:hostPort:containerPort | ip::containerPort | hostPort:containerPort | containerPort
               Both hostPort and containerPort can be specified as a range of ports.
               When specifying ranges for both, the number of container ports in the range must match the number of host ports in the range. (e.g., `-p 1234-1236:1234-1236/tcp`)
               (use &#39;docker port&#39; to see the actual mapping)

Как видите, вы можете привязать hostPort к IP.

1
docker run --name some-nginx -d -p 127.0.0.1:9090:80 nginx
1
2
3
4
5
6
# BEFORE
netstat -an | grep 9090
tcp6       0      0 :::9090                 :::*                    LISTEN
# AFTER
netstat -an | grep 9090
tcp        0      0 127.0.0.1:9090          0.0.0.0:*               LISTEN

Докер, хватит возиться с моими правилами iptables!

Допустим, вы используете докер на сервере, доступном в Интернете. У вас уже настроен межсетевой экран на основе iptables. Чтобы запретить docker вносить изменения в правила iptables вашей системы, вы должны установить –iptables=false при запуске демона. Для систем на основе sysvinit и upstart вы можете отредактировать /etc/default/docker. Для systemd вы можете сделать это – ‘systemd edit docker.service’ и добавить следующий код и перегрузить docker:

1
2
3
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock --iptables=false

Теперь перезагрузите брандмауэр и перезапустите демон Docker. Вы можете видеть, что цепочка с именем DOCKER и ссылки на нее в цепочке FORWARD исчезли.

1
2
3
4
5
[root@vms csf]# csf -ra | egrep '(ERR|WARN)'
*WARNING* RESTRICT_SYSLOG is disabled. See SECURITY WARNING in /etc/csf/csf.conf.
[root@vms csf]#
[root@vms csf]# iptables-save | egrep DOCK
[root@vms csf]#

Настройте iptables для работы с докером

Если вы все еще используете мост Ethernet, созданный docker и названный docker0, вы можете установить следующие правила для пересылки:

1
2
3
4
[root@vms csf]# iptables-save | egrep docker0
-A INPUT -i docker0 -j ACCEPT
-A OUTPUT -o docker0 -j ACCEPT
[root@vms csf]#

Теперь, если вы хотите открыть TCP-порт 10000 работающего контейнера для всего мира, этот контейнер должен предоставить порт любому IP-адресу (0.0.0.0) на стороне хоста:

1
2
3
4
docker run --name some-nginx -d -p 10000:80 nginx

netstat -an | grep 10000
tcp6       0      0 :::10000                :::*                    LISTEN

Затем вы можете добавить это правило брандмауэра, чтобы разрешить миру доступ к вашему контейнеру через правила пересылки:

1
-A INPUT -p tcp -m tcp --dport 10000 -j ACCEPT

Docker: systemd в docker контейнере

В одной из предыдущих статей я показал как собрать образ с нуля для контейнера на основе пакетной базы CentOS7. Однако все эти контейнеры на базе некоторого исполняемого кода, берушего на себя функции начального процесса с PID 1 далеки от какой-либо эмуляции “контейнерной” ОС. Для этого нужен полноценный init процесс, способный работать с сервисами в контейнере docker как в обычной полной виртуализации или на обычном сервере.

В “родных” контейнерах построенных на базе systemd-nspawn все это заложено изначально, и такие контейнеры сразу запуcкают полноценный процесс init – systemd. Но так ли сложно обойти костыли архитектуры docker и запустить systemd под его изрляцией? Давайте разбираться.

Углубившись слегка в понимание процесса загрузки ОС в которой ядро передает управление некоему процессу init, мы можем понять что любой такой процесс будет выполнять ряд логических процессов инициализации сервисов и среда из одной начальной точки до некторого целевого состояния. И совсем не факт что мы не можем пропустить большую часть этих действий по своему усмотрению.

В systemd все это крутится вокруг сущностей целей, сервисов и юнитов. Значит, передавая в докер контейнер systemd как начальную входную точку, мы можем попытаться определить его цель по умолчанию на основе специфики обоих платформ. Хотя по всему видно что они друг другу не друзья. И контейнеры на базе systemd-nspawn обладает не меньшей мощью и гибкостью.

Допустим, что как в предыдущей статье мы уже знаем как создать базовую сущность supermin5 только с одним пакетом – yum. Теперь попробуем создать это с двумя пакетами – systemd и yum:

“Docker: systemd в docker контейнере”Continue reading

Docker: создание собственного локального CentOS образа и контейнера с нуля.

Для создания образа будем использовать один из популярных инструментов старых админов – supermin.


supermin [-o OUTPUTDIR] – Имена СПИСОК PKGS …
supermin [-o OUTPUTDIR] Имена файлов PKG …
Supermin – это инструмент для создания программных “сущностей”.
Они крошечные и похожи на виртуальные машины, обычно около 100 КБ в размере, которые создаются полностью на лету за доли секунды когда нужно.
Начиная с версии 4 этот инструмент является независимым от дистрибутива и может создавать “супер-сущности” для нескольких популярных дистрибутивов Linux, а добавить поддержку других достаточно просто.

и пару слов о том как он работает ))


Есть два режима использования супермина:

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

Без –names supermin принимает список пакетов (т.е. имена файлов уже локально доступных пакетов). Этот пакет должен быть полным и в соответствии с отсутствием зависимостей вне набора пакетов, которые вы предоставляете. В этом режиме супермин не требует доступа к сети. Он видит файлы пакета сами.

Под «пакетом» мы понимаем пакет RPM, DEB и т. д.
Имя пакета может быть полным именем (например, “coreutils-8.22-24.el7.x86_64”) или некоторое сокращение (например, “coreutils”).
Точный формат имени и допустимые сокращения зависят от менеджера пакетов.

Файловая программная сущность supermin, которая создается supermin, состоит из двух файлов, называемых «hostfiles» и «base.img».
По умолчанию они записываются в текущий каталогm, но если укажем опцию -o OUTPUTDIR, то эти файлы будут записаны в этот каталог
(традиционно этот каталог называется «supermin.d», но вы можете называть его как хотите).

Во всех случаях supermin может создавать только файловые сущности, идентичные дистрибутиву, версии и архитектуре хосту. Он не делает кросс сборки.

Исходя из сказанного вышею для создание своего образа с нуля нам уже будет нужна целевая ОС с установленными пакетами.
Устанавливаем 5 версию и создаем рабочий каталог:

“Docker: создание собственного локального CentOS образа и контейнера с нуля.”Continue reading

Как восстановить пароли, хранящиеся в DBeaver

Для DBeaver 6.1.3+ пароли теперь хранятся в файле “json” с новым шифрованием.
Где найти файл хранящий сохраненные пароли, Вы можете узнать на страницах официальной документации.
А потом Вы можете использовать скрипт на питоне 2/3 для расшифровки и вывода результатов.

“Как восстановить пароли, хранящиеся в DBeaver”Continue reading

Идеально полная конфигурация Apache

Apache configuration file
Elements of this file is best used in /etc/http/conf/httpd.conf
On production servers functional of using mode with .htaccess should be disabled.

Конфигурационный файл Apache
Элементы этого файла лучше всего использовать в /etc/http/conf/httpd.conf
На производственных серверах должен быть отключен функционал использования режима с .htaccess.

v1.2 / 2019-03-01 / Andrei Volkov

“Идеально полная конфигурация Apache”Continue reading

Scroll to top