Безопасность в контейнерах
Опубликовано 22.10.2015 14:59 пользователем Peter Lemenkov
Red Hat запартнерилась с Black Duck Software (это те, кто сейчас владеет OpenHUB.net), чтобы улучшить безопасность контейнеров.
Как вы знаете, контейнер, это просто обычный процесс (или совокупность процессов), к которым присоединено некоторое количество меток (namespaces, cgroups, capabilities, SELinux, и прочие возможные метки), по которым операционная система определяет то, что из ресурсов доступно процессу. Понятно, что безопасность такой вещи гораздо ниже, чем у виртуалки, и наши коллеги, например, Dan Walsh, об это регулярно рассказывают. К сожалению, из-за начальной ориентации контейнеров, как "замена виртуалки, только быстрее", народ не обращает внимание на это. Вторая проблема, это то, что контейнеры рекламируются, как "средство от зависимостей". Мы уже обладаем неким аппаратом проверки того, что в пакетах, и того, как их распространять, а вот с контейнерами все гораздо хуже. Т.к. контейнеры постепенно реализовывают функционал пакетных менеджеров, то теперь возникла потребность в проверке содержимого. Вот ради этого Red Hat и объединяет усилия с Black Duck. Напомним наше предсказание - скоро в контейнеры добавят зависимости.
Откуда вообще в Docker такое количество архитектурных проблем? Ну, мы уже отвечали - из-за того, что его разрабатывали для недалеких и нетребовательных пользователей Ubuntu, где и пакетный менеджер малофункциональный, и с безопасностью плохо. Недавно наш коллега, инженер Rackspace, Major Hayden, которого вы можете уже знать, как человека с самым прекрасным в мире резюме, решил разобраться, а как в Ubuntu с промышленно принятыми стандартами безопасности? Ну, понятно, что SELinux там нет, т.е. дистрибутив отстает лет на 10 от нас, а что с остальным? Оказалось, что все очень плохо, и с т.з. безопасности лучше даже Arch. Вероятно именно поэтому, из-за отсутствия хоть какого то бы ни было соответствия промышленным стандартам, те большие разработчики OpenStack, базирующиеся на Ubuntu (или даже Debian), проигрывают контракт за контрактом в пользу решений на базе RHEL. Ну что сказать, свою голову не приставишь - подолбятся еще в стену и начнут задумываться. К счастью, HP уже взял под свою опеку Debian, и вполне вероятно, что мы увидим улучшения в нем, связанные с безопасностью. А оттуда они перейдут в Ubuntu, где вообще уже ничего своего не делается.
Matthew Garrett, благополучно эвакуировавшийся из закрывшейся Nebula в CoreOS, продолжает работать над безопасностью (в свободное от радикального феминизма время). В CoreOS делают все правильно, и там за основной компонент безопасности взяли SELinux и функционал ядра. Конечно, народ осознает, что есть большой массив задач безопасности, который просто не решить с SELinux, и там предлагают уже известное и применяющееся в том же Google решение - контейнеры запускать в виртуалках. Это отчасти работает, конечно, но хочется-то на baremetal-машинах.
Напомню, что у нас есть видение того, какие есть проблемы с безопасностью в контейнерах, и то, как их надо решать. Это не значит, конечно, что решения у нас уже есть, а лишь то, что мы понимаем проблематику. Интересно, что постепенно разными организациями и компаниями поднимается одна важная проблема - управление пользователями (и трансляцией пользовательских числовых идентификаторов) в контейнерах. Т.к. UID 1001 в контейнере далеко не обязательно будет тождественнен UID 1001 на хостовой машине, или в другом контейнере, а еще он на хостовой машине выглядеть будет, как какой-нибудь UID 49512, тонужен пропатченный OpenLDAP необходима новая система для трансляции. Тут нужен старый-добрый OpenLDAP с парой патчей совершенно новый, современный механизм AAA. VMware разработала и открыла новый фреймворк - Lightwave, а вот ребята из CoreOS похоже не до конца поняли, какое сокровище у них в руках, когда анонсировали dex, OpenID провайдер. Представляете, как может быть инновационно - контейнеры с авторизацией в Twitter, Facebook, и Google+.
Как вы знаете, контейнер, это просто обычный процесс (или совокупность процессов), к которым присоединено некоторое количество меток (namespaces, cgroups, capabilities, SELinux, и прочие возможные метки), по которым операционная система определяет то, что из ресурсов доступно процессу. Понятно, что безопасность такой вещи гораздо ниже, чем у виртуалки, и наши коллеги, например, Dan Walsh, об это регулярно рассказывают. К сожалению, из-за начальной ориентации контейнеров, как "замена виртуалки, только быстрее", народ не обращает внимание на это. Вторая проблема, это то, что контейнеры рекламируются, как "средство от зависимостей". Мы уже обладаем неким аппаратом проверки того, что в пакетах, и того, как их распространять, а вот с контейнерами все гораздо хуже. Т.к. контейнеры постепенно реализовывают функционал пакетных менеджеров, то теперь возникла потребность в проверке содержимого. Вот ради этого Red Hat и объединяет усилия с Black Duck. Напомним наше предсказание - скоро в контейнеры добавят зависимости.
Откуда вообще в Docker такое количество архитектурных проблем? Ну, мы уже отвечали - из-за того, что его разрабатывали для недалеких и нетребовательных пользователей Ubuntu, где и пакетный менеджер малофункциональный, и с безопасностью плохо. Недавно наш коллега, инженер Rackspace, Major Hayden, которого вы можете уже знать, как человека с самым прекрасным в мире резюме, решил разобраться, а как в Ubuntu с промышленно принятыми стандартами безопасности? Ну, понятно, что SELinux там нет, т.е. дистрибутив отстает лет на 10 от нас, а что с остальным? Оказалось, что все очень плохо, и с т.з. безопасности лучше даже Arch. Вероятно именно поэтому, из-за отсутствия хоть какого то бы ни было соответствия промышленным стандартам, те большие разработчики OpenStack, базирующиеся на Ubuntu (или даже Debian), проигрывают контракт за контрактом в пользу решений на базе RHEL. Ну что сказать, свою голову не приставишь - подолбятся еще в стену и начнут задумываться. К счастью, HP уже взял под свою опеку Debian, и вполне вероятно, что мы увидим улучшения в нем, связанные с безопасностью. А оттуда они перейдут в Ubuntu, где вообще уже ничего своего не делается.
Matthew Garrett, благополучно эвакуировавшийся из закрывшейся Nebula в CoreOS, продолжает работать над безопасностью (в свободное от радикального феминизма время). В CoreOS делают все правильно, и там за основной компонент безопасности взяли SELinux и функционал ядра. Конечно, народ осознает, что есть большой массив задач безопасности, который просто не решить с SELinux, и там предлагают уже известное и применяющееся в том же Google решение - контейнеры запускать в виртуалках. Это отчасти работает, конечно, но хочется-то на baremetal-машинах.
Напомню, что у нас есть видение того, какие есть проблемы с безопасностью в контейнерах, и то, как их надо решать. Это не значит, конечно, что решения у нас уже есть, а лишь то, что мы понимаем проблематику. Интересно, что постепенно разными организациями и компаниями поднимается одна важная проблема - управление пользователями (и трансляцией пользовательских числовых идентификаторов) в контейнерах. Т.к. UID 1001 в контейнере далеко не обязательно будет тождественнен UID 1001 на хостовой машине, или в другом контейнере, а еще он на хостовой машине выглядеть будет, как какой-нибудь UID 49512, то