Chrome в Docker: CAP_SYS_ADMIN vs privileged?

docker
1

Я запускаю chromedriver + chrome внутри Docker в своей тестовой среде.

Все работало нормально до последнего обновления CoreOS.

Это версии, которые, похоже, работают:

VERSION=1185.5.0VERSION_ID=1185.5.0BUILD_ID=2016-12-07-0937

И это более новая версия, которая заставляет chrome выполнять coredump:

VERSION=1235.4.0VERSION_ID=1235.4.0BUILD_ID=2017-01-04-0450

Глядя на изменения, кажется, что docker был обновлен с 1.11.x до 1.12.x, что сломало setns() вызов внутри контейнера. setns() используется Chrome для создания пространств имен.

Это пример выходных данных:

jsosic-coreos-test-20161207 ~ # docker --versionDocker version 1.11.2, build bac3bae

Из одного контейнера на этой коробке:

[root@2939f21ecfaa /]# /opt/google/chrome/google-chrome[57:57:0107/015130:ERROR:browser_main_loop.cc(261)] Gtk: cannot open display:

Вот как новая версия сломала его:

jsosic-coreos-test-2017-01-04 ~ # docker --versionDocker version 1.12.3, build 34a2ead[root@13ab34c36c82 /]# /opt/google/chrome/chromeFailed to move to new namespace: PID namespaces supported,  Network namespace supported,  but failed: errno = Operation not permittedAborted (core dumped)

Что я выяснил, так это то, что если я начну контейнер с любого --cap-add=SYS_ADMIN или --privileged - Chrome работает так, как ожидалось.

В чем разница между этими двумя переключателями? Какие возможности доступны с помощью --privileged?

И могу ли я позволить setns() внутри контейнера без ущерба для безопасности?

2

AFAICS, документация предполагает предоставление возможностей, необходимых для контейнера, вместо использования --privileged переключатель. Запуск в привилегированном режиме кажется, предоставляет контейнер со всеми возможностями (что именно это такое, указано в первом URL-адресе, при условии, что документы обновлены).

Короче говоря, я бы сказал, что --cap-add=SYS_ADMIN предоставляет меньшее подмножество возможностей контейнеру по сравнению с --privileged переключатель. Событие примеры в документации Docker (первый URL), похоже, предпочитают просто добавлять SYS_ADMIN или NET_ADMIN возможности там, где это необходимо.

3

Одно из отличий заключается в том, что --privileged монтирует /dev и /sys как RW, где as SYS_ADMIN монтирует их как RO.Это означает, что привилегированный контейнер имеет полный доступ к устройствам в системе. SYS_ADMIN не дает вам этого.

4

Спасибо за это. Я создал проблему, используя много ваших материалов: Allow setns() in container, or add flag to allow it specifically · Issue #496 · docker/for-linux · GitHub Я думаю, что это должно быть исправлено

5

Я опоздал почти на 2 года, но в приведенном выше билете есть гораздо лучшее и безопасное решение, если вы все еще заинтересованы.

6

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