The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Выпуск cистемы управления контейнерной виртуализацией Docker..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Выпуск cистемы управления контейнерной виртуализацией Docker..."  +/
Сообщение от opennews (??) on 12-Дек-14, 10:51 
Анонсирован (https://blog.docker.com/2014/12/advancing-docker-security-do.../) релиз инструментария для управления изолированными Linux-контейнерами Docker 1.4, предоставляющего высокоуровневый API для манипуляции контейнерами на уровне изоляции отдельных приложений. В частности,  Docker  позволяет не заботясь о формировании начинки контейнера запускать произвольные процессы в режиме изоляции и затем переносить и клонировать сформированные для данных процессов контейнеры на другие серверы, беря на себя всю работу по созданию, обслуживанию и сопровождению контейнеров. Код Docker написан на языке Go и распространяется (https://github.com/dotcloud/docker/) под лицензией Apache 2.0.

Инструментарий базируется на применении встроенных в ядро Linux штатных механизмов изоляции на основе пространств имён (namespaces) и групп управления (cgroups). Для создания контейнеров предлагается использовать libcontainer (обёртка над namespaces и cgroups), также возможно применение lxc (http://lxc.sourceforge.net/), libvirt, systemd-nspawn и других систем изоляции. Для формирования контейнера достаточно загрузить базовый образ окружения (docker pull base), после чего можно запускать в изолированных окружениях произвольные приложения (например, для запуска bash можно выполнить "docker run -i -t base /bin/bash").

Из добавленных в Docker 1.4 новшеств (https://github.com/docker/docker/blob/master/CHANGELOG.md) можно отметить:


-  Новый драйвер для организации хранилища поверх  многослойной файловой системы OverlayFS (http://www.opennet.dev/opennews/art.shtml?num=40947), код которой вошёл в состав ядра Linux 3.18 (http://www.opennet.dev/opennews/art.shtml?num=41210);
-  В управляющий демон добавлена опция "-label" для установки меток в форме "ключ=значение", выводимых при выполнении команды "docker info";
-  Поддержка установки переменных окружения через указание в Dockerfile опции "ENV name=value name2=value2...";
-  В вывод команды "docker info" добавлено отображение полей с идентификатором и именем;
-  Возможность фильтрации событий по имени события, контейнеру и образу окружения;
-  Команда "docker cp" расширена поддержкой копирования данных из разделов контейнера.

Одновременно доступен корректирующие выпуск  Docker  1.3.3, в котором устранены три уязвимости (https://groups.google.com/forum/#!msg/docker-user/nFAz-B-n4B...) (проблемы также исправлены в  Docker 1.4.0), которые были обнаружены в процессе аудита после выявления (http://www.opennet.dev/opennews/art.shtml?num=41124) в ноябре двух критических проблем с безопасностью. Уязвимости проявляются при использовании готовых образов или образов, собранных Dockerfile, загруженных из сторонних непроверенных источников. Как и прошлые уязвимости, новые проблемы позволяют выполнить код или получить доступ к внешней ФС в процессе запуска или обработки специально модифицированного образа контейнера.


-  CVE-2014-9356 - возможность записи во внешние части ФС и выхода за пределы контейнера через манипуляции с абсолютными символическими ссылками;
-  CVE-2014-9357 - повышение  привилегий (выполнение кода с правами root) в процессе декодирования специально оформленных архивов LZMA (.xz);
-  CVE-2014-9358 - проблемы с проверкой идентификатора образа контейнера, которые могут быть использованы для подмены загружаемого из репозитория образа или выхода за пределы допустимого файлового пути.


Дополнительно можно отметить публикацию (http://blog.docker.com/2014/12/announcing-docker-machine-swa.../) компанией Docker трёх новых инструментов:

-  Docker Machine (http://github.com/docker/machine) - система для быстрого развёртывание хостов в гостевых окружениях систем виртуализации, предназначенных для организации контейнерной виртуализации приложений на основе Docker. Осуществляет создание начинки сервера, установку на него Docker и настройку клиента для работы с данным сервером. Поддерживается создание серверов в виртуальных окружениях VirtualBox,  Digital Ocean и Microsoft Azure;


-  Docker Swarm (https://github.com/docker/swarm/) - средства кластеризации для упакованных в контейнеры приложений. Предоставляет управлять кластером из нескольких хостов Docker (например, созданных с использованием Docker Machine) в форме работы с одним виртуальным хостом. Так как Swarm использует штатный Docker API, он может применяться для управления и другими поддерживающими данный API инструментами, такими как  dokku, fig, krane, flynn, deis, docker-ui, shipyard, drone.io, Jenkins;

-  Docker Compose (https://github.com/docker/docker/issues/9459) - система поставки приложения с разделением на несколько контейнеров.


URL: https://blog.docker.com/2014/12/advancing-docker-security-do.../
Новость: http://www.opennet.dev/opennews/art.shtml?num=41251

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


2. "Выпуск cистемы управления контейнерной виртуализацией Docker..."  –8 +/
Сообщение от iZEN (ok) on 12-Дек-14, 11:51 
Подумываю над реализацией запуска X-приложений таких, как Xfce4 DE, Firefox и т.д. внутри FreeBSD Jail. В чём может быть принципиальная трудность этого? Способы решения? (Все необходимые приложения, библиотеки и xorg-server 1.12.4 уже есть внутри клетки. Клетка работает — консольные приложения запускаются.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Выпуск cистемы управления контейнерной виртуализацией Docker..."  –4 +/
Сообщение от Аноним (??) on 12-Дек-14, 11:57 
В LXC Х-приложения уже давно запускают, а ты жди своего docker.exe. Всё равно, кроме вантуза у тебя ничего больше не вращается.
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "Выпуск cистемы управления контейнерной виртуализацией Docker..."  +2 +/
Сообщение от Andrew Kolchoogin (ok) on 12-Дек-14, 12:11 
1. Мы хотим «ня» и прочие прозрачности/OpenGL.
Тогда контейнерная изоляция (любая на любой операционной системе) бессмысленна: отдача внутрь контейнера /dev/mem и /dev/dri/* — это смерть любой изоляции. По этой же причине бессмысленно внутри контейнера запускать X-сервер (ему это нужно обязательно).

2. Мы обойдёмся AIGLX (если он есть), или вообще на OpenGL нам наплевать.
Тогда export DISPLAY=host.machine.domain:0, и понеслась.
На основной системе только надо выгрести из флагов X-сервера «-nolisten tcp», и зашарить домашнюю директорию с контейнером (ну, или, хотя бы, .Xauthority из неё).

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

6. "Выпуск cистемы управления контейнерной виртуализацией Docker..."  +/
Сообщение от Ordu email(ok) on 12-Дек-14, 12:47 
> 1. Мы хотим «ня» и прочие прозрачности/OpenGL.
> 2. Мы обойдёмся AIGLX (если он есть), или вообще на OpenGL нам наплевать.

Эмм... А "ня" и "прочие прозрачности" как-то заметно страдают от AIGLX? Я просто не пользуюсь всей этой хренью; внутрь не заглядывал, как реализовано могу лишь догадываться, и по моим догадкам, на глаз заметить разницу между AIGLX и DRI не удастся на столь простой задаче как няшно отрисованные окошки. Крузис конечно будет тормозить, но на то он и крузис. Или мои догадки неверны? Чессово лень впиливать в систему что-нибудь композитное, только для того, чтобы посмотреть.

> отдача внутрь контейнера /dev/mem и /dev/dri/* — это смерть любой изоляции.

Смерть. Бесспорно. Но... а возможно ли отказаться от dri и как-то прокинуть /dev/shm в контейнер? Ну не будет direct render'а, но всё ж клиенту не придётся сериализовывать всякие там текстурки и прокидывать их через сокет серверу. Или это никак? Или это опять же кранты изоляции?

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

12. "Выпуск cистемы управления контейнерной виртуализацией Docker..."  +/
Сообщение от Stax (ok) on 12-Дек-14, 15:07 
> Эмм... А "ня" и "прочие прозрачности" как-то заметно страдают от AIGLX? Я
> просто не пользуюсь всей этой хренью; внутрь не заглядывал, как реализовано

Не страдают. Более того, раньше оно через него обычно и работало.

>> отдача внутрь контейнера /dev/mem и /dev/dri/* — это смерть любой изоляции.
> Смерть. Бесспорно. Но... а возможно ли отказаться от dri и как-то прокинуть
> /dev/shm в контейнер? Ну не будет direct render'а, но всё ж
> клиенту не придётся сериализовывать всякие там текстурки и прокидывать их через
> сокет серверу. Или это никак? Или это опять же кранты изоляции?

Да смотря какая у вас цель. Если вам 3D нужно, почему дать доступ к видеокарте это "кранты изоляции"? А если вам важна изоляция, из которой (кто-то другой, а не ваша конкретная прога) не выберется, зачем ей 3D? Десктопные приложения и полная изоляция вообще слабо совместимые вещи, через тот же браузер куча других векторов атаки (изолируете доступ к файликам на хост-системе, а у вас тем временем уведут куки от сайта, где хранятся данные кредитки типа paypal/google checkout/qiwi).

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

15. "Выпуск cистемы управления контейнерной виртуализацией Docker..."  +/
Сообщение от Andrew Kolchoogin (ok) on 12-Дек-14, 15:53 
>> Эмм... А "ня" и "прочие прозрачности" как-то заметно страдают от AIGLX? Я
>> просто не пользуюсь всей этой хренью; внутрь не заглядывал, как реализовано
> Не страдают. Более того, раньше оно через него обычно и работало.

«Вот ващще-ващще раньше» оно работало и до появления AIGLX в природе. :)

Через специальный X-сервер.

>>> отдача внутрь контейнера /dev/mem и /dev/dri/* — это смерть любой изоляции.
>> Смерть. Бесспорно. Но... а возможно ли отказаться от dri и как-то прокинуть
>> /dev/shm в контейнер? Ну не будет direct render'а, но всё ж
>> клиенту не придётся сериализовывать всякие там текстурки и прокидывать их через
>> сокет серверу. Или это никак? Или это опять же кранты изоляции?
> Да смотря какая у вас цель. Если вам 3D нужно, почему дать
> доступ к видеокарте это "кранты изоляции"?

Потому что «до первого бага».

Примерно, как PCI Pass-through в Xen'е, и без VT-d.
Можно?
Можно.
Секурно?
Нет.

> А если вам важна изоляция,
> из которой (кто-то другой, а не ваша конкретная прога) не выберется,
> зачем ей 3D? Десктопные приложения и полная изоляция вообще слабо совместимые
> вещи, через тот же браузер куча других векторов атаки (изолируете доступ
> к файликам на хост-системе, а у вас тем временем уведут куки
> от сайта, где хранятся данные кредитки типа paypal/google checkout/qiwi).

Вот это совершенно верно.

Но тут ведь, как обычно, надо понимать, что сама по себе изоляция не делает машину секурной, надо ещё и свои привычки поменять. :)

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

19. "Выпуск cистемы управления контейнерной виртуализацией Docker..."  +/
Сообщение от Ordu email(ok) on 13-Дек-14, 01:36 
> Но тут ведь, как обычно, надо понимать, что сама по себе изоляция не делает машину секурной, надо ещё и свои привычки поменять. :)

Это надо понимать. Но не стоит также забывать, что привычки тоже не панацея.

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

13. "Выпуск cистемы управления контейнерной виртуализацией Docker..."  +/
Сообщение от Andrew Kolchoogin (ok) on 12-Дек-14, 15:48 
> Эмм... А "ня" и "прочие прозрачности" как-то заметно страдают от AIGLX?

Это зависит от.

Скажем, для «ня» и «прочих прозрачностей» в KDE/KWM OpenGL вообще не нужен — KWM умеет их делать через XRender.
Однако, «классика жанра» — Compiz — уже требует OpenGL, причём каких-то «высоких версий», чуть ли не минимум 2.1.

> на глаз заметить разницу между AIGLX и DRI не удастся на столь простой задаче
> как няшно отрисованные окошки.

Да, но вот вряд ли удастся сделать так, чтобы в процессе поворота Desktop Cube прям на двух гранях было видно, как играет что-нибудь в YouTube. :)

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

11. "Выпуск cистемы управления контейнерной виртуализацией Docker..."  +/
Сообщение от Stax (ok) on 12-Дек-14, 15:02 
> Тогда контейнерная изоляция (любая на любой операционной системе) бессмысленна: отдача внутрь контейнера /dev/mem и /dev/dri/* — это смерть любой изоляции. По этой же причине бессмысленно внутри контейнера запускать X-сервер (ему это нужно обязательно).

Отставить панику - /dev/mem никому давать не нужно.
А отдача /dev/dri почему смерть, если цель именно в том, чтобы дать конкретному приложению 3D? Конечно, в таком контейнере нужно запускать одно приложение, а не грузить ОС

http://maci0.wordpress.com/2014/05/02/run-any-applications-o...

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

14. "Выпуск cистемы управления контейнерной виртуализацией Docker..."  –1 +/
Сообщение от Andrew Kolchoogin (ok) on 12-Дек-14, 15:50 
>> Тогда контейнерная изоляция (любая на любой операционной системе) бессмысленна:
>> отдача внутрь контейнера /dev/mem и /dev/dri/* — это смерть любой изоляции.
>> По этой же причине бессмысленно внутри контейнера запускать X-сервер (ему это нужно обязательно).
> Отставить панику - /dev/mem никому давать не нужно.

Да?

А вы проверьте: загрузите FreeBSD, скажите «sysctl kern.securelevel=2», чтобы закрыть /dev/mem, и стартаните Иксы.

> А отдача /dev/dri почему смерть, если цель именно в том, чтобы дать
> конкретному приложению 3D? Конечно, в таком контейнере нужно запускать одно приложение,
> а не грузить ОС

Потому, что DRM — это ещё и Generic DMA Engine.

Ну, то есть, это получится «изоляция до первого бага в драйвере».

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

17. "Выпуск cистемы управления контейнерной виртуализацией Docker..."  –1 +/
Сообщение от Stax (ok) on 12-Дек-14, 18:09 
> А вы проверьте: загрузите FreeBSD, скажите «sysctl kern.securelevel=2», чтобы закрыть /dev/mem, и стартаните Иксы.

Я говорил про линукс. Во фре вообще поддержку запуска иксов из под пользователя, без прав рута уже сделали?

> Ну, то есть, это получится «изоляция до первого бага в драйвере».

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

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

22. "Выпуск cистемы управления контейнерной виртуализацией Docker..."  –3 +/
Сообщение от iZEN (ok) on 13-Дек-14, 18:26 
>> А вы проверьте: загрузите FreeBSD, скажите «sysctl kern.securelevel=2», чтобы закрыть /dev/mem, и стартаните Иксы.
> Я говорил про линукс. Во фре вообще поддержку запуска иксов из под
> пользователя, без прав рута уже сделали?

Теоретически запуск xorg-server на FreeBSD из-под пользователя возможен: http://www.freshports.org/x11-servers/xorg-server/
— опцию сборки "SUID=on: Install the Xorg server with setuid bit set" можно перевести в "SUID=off" и собрать xorg-server без привелегированного запуска из-под пользователя. Но в таком режиме в X-ах может работать только root.

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

24. "Выпуск cистемы управления контейнерной виртуализацией Docker..."  +1 +/
Сообщение от Аноним (??) on 13-Дек-14, 21:32 
И как эта теория с практикой соотносится?
Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

21. "Выпуск cистемы управления контейнерной виртуализацией Docker..."  –1 +/
Сообщение от iZEN (ok) on 13-Дек-14, 18:19 
Упрощённо говоря, у нас есть некая машина, у которой извне доступен только SSH. Она не имеет ни графической карты, ни звуковой. Тем не менее, на ней установлено графическое окружение, включающее в себя десктопные X-приложения: Firefox, LibreOffice, Pluma, RSSOwl и т.д.. Возможно ли, имея этот набор ПО, воспользоваться удалённым запуском этих приложений с отрисовкой их окон на клиенте, у которого нормальная графическая карта, достаточно много ОЗУ, звуковая карта? Клиент должен по сути видеть окна, воспроизведение видео/звука и мог бы воздействовать на элементы управления удалённо запущенных программ. В каком направлении копать?
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

23. "Выпуск cистемы управления контейнерной виртуализацией Docker..."  +/
Сообщение от anonimouse on 13-Дек-14, 20:09 
Лет 15 назад на той машине нужно было бы настроить ремотный дисплей , а проуинуть х-сессию (возможно ч\з ssh) ... Как оно сейчас яхз., наверно надо ставить vnc ?
Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

25. "Выпуск cистемы управления контейнерной виртуализацией Docker..."  +/
Сообщение от Аноним (??) on 13-Дек-14, 21:34 
Можно просто ssh -X. У тебя на цигвине должно тоже работать.
Или Ubuntu LTSP

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

26. "Выпуск cистемы управления контейнерной виртуализацией Docker..."  –2 +/
Сообщение от iZEN (ok) on 13-Дек-14, 22:56 
> Можно просто ssh -X. У тебя на цигвине должно тоже работать.

Цигвина не имею в наличии. Мне, вообще, нужно сделать сначала на Unix без всяких Windows.

> Или Ubuntu LTSP

Ты, похоже, ничего кроме Ubuntu не знаешь и не хочешь знать, понимать. Печально это.

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

5. "Выпуск cистемы управления контейнерной виртуализацией Docker..."  +/
Сообщение от fidaj (ok) on 12-Дек-14, 12:35 
http://www.bsdstore.ru/ru/xorg_in_jail.html
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

7. "Выпуск cистемы управления контейнерной виртуализацией Docker..."  +/
Сообщение от пингвинус on 12-Дек-14, 13:01 
http://www.youtube.com/watch?v=YcfmRnxHRKY

Но как уже писал - это только для себя, поскольку несекьюрно.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

18. "Выпуск cистемы управления контейнерной виртуализацией Docker..."  +/
Сообщение от Typhoon (ok) on 12-Дек-14, 21:26 
Я тоже хочу в клетках запилить, но только приложения, кажтому приложению по клетке, Думаю нужен доступ к экрану и звуковым устройствам, Т.е к сокету Unix для X11, в /tmp/.X11-unix, + правильно настроить DISPLAY, xhost, итд, по поводу звуеа думаю, что достаточно будет прописать монтирование в клетку звуковых устройств. Пока ничего не пробовал, работы много. Кто может что-то посоветовать по делу - напишите комментарий.
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

20. "Выпуск cистемы управления контейнерной виртуализацией Docker..."  +/
Сообщение от Stax (ok) on 13-Дек-14, 02:05 
Для звука достаточно пробросить туда /run/user/${UID}/pulse
Вообще я выше ссылку давал про запуск скайпа в контейнере - systemd-nspawn'ом либо docker'ном. Никаких проблем нет так запускать любое.
Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

9. "Выпуск cистемы управления контейнерной виртуализацией Docker..."  +/
Сообщение от _йцукен (ok) on 12-Дек-14, 13:54 
переписан на го 1,4 ? =)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

27. "Выпуск cистемы управления контейнерной виртуализацией Docker..."  +/
Сообщение от бедный буратино (ok) on 16-Дек-14, 01:35 
хоть бы один коммент по docker :) ну, раз все прошли мимо - и я пройду :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру