CoreOS объявляет rkt: \"Docker небезопасен\" и как с этим жить

На прошлой неделе CoreOS опубликовал пост, который в контейнерном сообществе восприняли примерно как бросок перчатки. Коротко: «Docker небезопасен по дизайну, мы сделаем правильно». И сразу анонс Rocket - container runtime без центрального daemon.

Мы внимательно работаем с Docker последние полгода. Смотрели на CoreOS как платформу - написали об этом отдельно. Сейчас самое время разобраться, насколько критика обоснована, и что это значит для наших задач.

В чём претензия

Суть претензии CoreOS не в том, что Docker «плохой». Суть - в конкретной архитектурной детали: docker daemon работает от root. Постоянно. На хосте.

Это означает следующее: клиентская CLI (docker run, docker build, всё остальное) общается с daemon через unix socket. Кто имеет доступ к этому socket - тот имеет полный root на хосте. Без пароля, без sudo, без аудита.

Практически это выглядит так: разработчик, добавленный в группу docker, может сделать docker run -v /:/host -it ubuntu bash и получить shell с примонтированной корневой файловой системой хоста. Это не баг - это намеренная архитектура. Docker так работает, потому что management containers требует привилегий ядра.

CoreOS называет это неприемлемым для production и предлагает rkt как альтернативу: никакого центрального daemon, контейнеры запускаются напрямую с root-привилегиями на момент запуска, управление привилегиями гранулярное.

Что реально в этой критике

Если честно - вопрос поставлен правильно. Docker daemon от root - это не паранойя безопасников, это реальный вектор.

Несколько сценариев, которые нас беспокоят:

• Общий сервер с несколькими командами. Если разработчики разных проектов могут запускать docker, они де-факто имеют root. CI-сервер с несколькими проектами и несколькими командами - классический пример. У нас такие есть.
• Компрометация контейнера. Если приложение в контейнере эксплуатируется через уязвимость и атакующий выходит наружу - он выходит в пространство docker daemon, который root. Это не escape из контейнера в обычном смысле, но последствия схожие.
• Audit trail. Действия через docker daemon сложнее аудировать, чем действия через sudo с логированием. Это важно для compliance.

Это не абстрактные угрозы. Это реальные ограничения, которые надо учитывать при проектировании.

Что такое rkt и чего в нём пока нет

Rocket (они уже начали писать rkt) - это CLI-инструмент без daemon. Запуск контейнера - это просто запуск бинаря с нужными параметрами. Привилегии нужны только на момент запуска, не постоянно.

Формат образов - не Docker Image Format, а App Container Image (ACI) - отдельная спецификация, которую CoreOS также анонсирует. Docker-образы rkt читать не умеет.

И вот здесь останавливаемся на секунду: rkt сегодня - это анонс и очень ранний код. Fig, который мы недавно внедрили, работает с Docker Image Format. Все наши образы - Docker-формат. Весь инструментарий вокруг - Docker. Переход на другой runtime с другим форматом образов - это не «просто заменить бинарь».

Что это значит для нас сейчас

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

Несколько вещей, которые мы пересматриваем:

• Кто в группе docker на production-хостах. Если список длиннее одного-двух человек - это уже повод задуматься. CI-агент тоже попадает под ревизию.
• Docker socket в CI. Прокидывать /var/run/docker.sock в CI-контейнеры - распространённая практика. Это означает, что job внутри CI-контейнера получает root на хосте. Нас это устраивало, пока не прочли явно сформулированную угрозу.
• Audit logging для docker daemon. Сейчас его нет. Кто и что запускал - восстановить по логам сложно. Надо думать.

Переходить на rkt сейчас - нет никаких оснований. Нет зрелости, нет совместимости с экосистемой, нет production-кейсов. Но аргументы CoreOS про архитектуру daemon мы считаем обоснованными и хотим понять, как Docker будет на это отвечать.

Следим за двумя вещами: развитием rkt как проекта и реакцией Docker Inc. на критику. Если появится нормальная поддержка user namespaces в Docker или что-то меняется в модели привилегий - это изменит картину. Пока - пишем внутренние правила по docker group и socket access.