Russian Fedora

cообщество русскоязычных участников
международного проекта Fedora

Content (98 страница со старыми записями)

Новости CoreOS

Это архивная статья

Отличные новости на этой неделе от наших друзей из CoreOS! Для начала они собрали вместе Kubernetes (помните, мы рассказывали о нем) и свой CoreOS и предлагают завершенное коммерческое решение на его основе - Tectonic. Это, наверное, будет флагманский коммерческий продукт от CoreOS.

В официальном анонсе от CoreOS есть и другая важная новость. Основным инвестором проекта стал Google, который внес дополнительно 12 миллионов долларов, и который выглядит серьезно настроенным по поводу связки CoreOS + systemd + etcd + rkt + fleet + flannel + Kubernetes. Возникает вопрос, а как же же Docker? А что Docker? Мы в который раз повторимся, что его популярность обусловлена не техническими причинами, а тем, что он, помимо основной задачи запуска контейнеров, решал недостатки основной платформы, на которой разрабатывался, и где были его early adopters. Red Hat, конечно, вынуждена работать и с ним, из-за сильного запроса снизу от вчерашних пользователей той платформы, постепенно доросших до управления большими системами, но на самом деле его архитектурные недостатки видны невооруженным глазом. Сейчас полюбили цитировать высказывания Alex Polvi о безопасности Docker (например, тут и тут), и хотя, как вы уже знаете, его безопасность постоянно улучшается нашими коллегами, в целом он выглядит очень нерационально спроектированным, неюниксвэйно.

http://i.juick.com/p/2775930.png

Docker в продакшене порой выглядит вот так

Опять же, повторимся, для быстрого развертывания чего-либо Docker все также прекрасно подходит. Многие наши коллеги регулярно его используют, например для регулярного пересоздания тестовой платформы для Unit-тестов, и вполне довольны. Но дело в том, что для кластера он [STRIKEOUT:не нужен] избыточен. Контейнеры на локальной машинке можно запускать чем угодно, тем же systemd или CRIU, а вот распределение задач в кластере решается совсем на другом уровне - Docker тут вносит лишь проблемы, решая задачи, давно решенные в современных системах, и добавляя хрупкости в конечный результат.

Касаемо Kubernetes - планы по его поддержке есть и у других вендоров, в т.ч. и Red Hat, и Mirantis. Тут CoreOS вступает в опасное единоборство с сильными домами. Ведь пока у него есть лишь дюжина разработчиков, и столько же миллионов долларов, а он пытается предложить то, что предлагают большие компании. Вообще, удивительно, что масштаб инвестиций таков. Тут, порой, за какой-нибудь хипстер-стартап с фотографиями и айфонами выкладывают чуть-ли не миллиарды, а тут парням, которые серьезный инфраструктурный проект делают, отсыпали на апгрейд компьютеров и стулья в офисе. Причем, это тенденция. Те же Mesosphere недавно получили лишь 36 миллионов долларов.

36, это, конечно, побольше, чем 12, но и не колоссально-то много. Для сравнения, в РФ собираются инвестировать 60 миллионов долларов в некое импортозамещение, под которым угадывается то ли Kolab, то ли Alfresсo, то ли вообще LibreOffice.

PayPal отказывается от VMware в пользу OpenStack (теперь уже всерьез)

Это архивная статья

Помните слух двухлетней давности, что PayPal переводит инфраструктуру с решений VMware на открытую платформу OpenStack? Тогда VMware заколодило, и им волей-неволей пришлось прыгнуть в разработку OpenStack.

VMware, конечно, не жалеет, что занялись OpenStack - так или иначе, люди выбирают это решение, и т.к. они в теме, то и они на нем зарабатывают.

По итогам 2014 года отдел по OpenStack показал лучшую динамику, чем другие. Аналитики Mirantis даже допускают, что VMware может серьезно покусать Red Hat (и еще в очередной раз напомним о предсказаниях Boris Renski на 2015 год).

Но тут есть нюанс. На самом деле, у некоторых наших коллег складывается впечатление, что продукты VMware остались в начале 2000х, и любое большое решение будет проще и выгоднее делать без их участия. Нет, гибридные облака, все дела, тут понятно - legacy-решения будут их греть еще долго, но вот что насчет новых инсталляций? И тут такой удар. PayPal действительно переводит все с VMware на OpenStack.

В этот раз пост на эту тему в Forbes быстро вызвал протесты от VMware. Оно и понятно - в прошлый раз такой анонс обошелся VMware в два миллиарда долларов капитализации, так что будьте уверены, что теперь там день начинают с изучения тематической прессы. Но Ben Kepes решил добить тему и следом опубликовал интервью с представителем PayPal.

Там все и было сказано максимально недвусмысленно. Да, уходят от VMware.

Увы, но проприетарное решение радикально сдерживает инновационность.

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

Очередной финансовый отчет от Red Hat

Это архивная статья

Опубликован очередной финансовый отчет от Red Hat, за 4й квартал 2014 года. Ничего нового - прибыль стабильно растет вслед за оборотом, если сравнивать с аналогичным периодом 2013 года.

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

image0

HP отказывается от публичных облаков

Это архивная статья

Вот это поворот! После всего шума и агрессивного маркетинга (употребляем без негативной коннотации) почти незаметной прошла новость, что HP передумала предоставлять услуги публичных облаков.

Обещают, что компания полностью сконцентрируется на частных облаках.

Решение для всех нас очень неожиданное, за исключением Jan Wildeboer, который не очень удивился.

Особенно странной эта новость воспринимается после щедрых трат HP на OpenStack Summit в Париже, когда побывавшие на их фуршете коллеги потом размахивали руками, как рыбаки, рассказывая про обилие всего. Так или иначе, будем надеяться, что HP не снизят уровень своей вовлеченности в проект, и не бросят Debian, которым начали потихоньку управлять. Вообще, теперь интересно снова перечитать предсказания Boris Renski на 2015 год.

Одновременно с плановым отступлением HP на заранее подготовленные позиции, пришла новость о том, что Nebula уходит из бизнеса. Новость была первого апреля, и мы специально выжидали, чтоб понять, не шутка ли? Нет, не шутка. Одни из OpenStack-создателей не осилили конкуренции. Надеемся, что на нашем коллеге, Matthew Garrett, пару лет назад перешедшем работать в Nebula, это сильно не скажется. Интересно, к кому уйдут клиенты Nebula за техобслуживанием развернутых облаков?

Очередной meetup от DevOps Moscow - про Ansible

Это архивная статья

В этот раз он будет посвящен Ansible. Состоится он в офисе Badoo на Цветном бульваре.

Митап про Ansible Thursday, April 16, 2015, 6:00 PM `офис Badoo, БЦ "Легенды Цветного", сразу напротив метро Трубная.

System Message: WARNING/2 (<string>, line 11); backlink

Inline interpreted text or phrase reference start-string without end-string.

Цветной бульвар, 2, стр. 1, Moscow <https://www.google.com/maps?f=q&hl=en&q=Цветной+бульвар,+2,+стр.+1,+Moscow,+ru>`__.

Детали мероприятия тут.

Будет три доклада, два уже сформированы - от Саши Чистякова и Вани Евтуховича, один еще в согласовании.

Видео докладов будет, если будет очень много желающих и все не влезут, то будет и видео-трансляция.

Вход будет строго по регистрации, каждому выдадут бейджик, так что регистрация обязательна!


Мы придем!

Безопасность Docker - будущее

Это архивная статья

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

Вообще, впечатление от технологии очень двойственно. Изначально Docker родился в среде пользователей Ubuntu, что отчасти перенацелило его на проблемы коммьюнити и обусловило mindset разработчиков. Плохой пакетный менеджер, неряшливый подход к версиям ПО, мусорка из неизвестно чьих PPA, нефункциональный init-демон, слабое знакомство с глубинными вещами - все эти вещи до сих пор угадываются в общей архитектуре приложения. Например, очень странное решение проектировать Docker с активным использованием AuFS, технологии, которая была признана устаревшей даже в Ubuntu (хорошо, что Red Hat протянул тут руку помощи). В системах, спроектированных правильно, этих проблем (почти) нет, и ряд фич Docker просто не востребован. Недаром тот же CoreOS отказывается от Docker в пользу своего Rocket из-за функциональной перегруженности первого. С другой стороны, Docker со всеми его минусами очень хорошо вписывается в концепцию Agile (см. "тяп-ляп и готово"), т.к. в современном мире быстро полученный результат ценится гораздо больше архитектурно правильного, но запоздавшего решения.

Наши коллеги неоднократно говорили, что Docker не только решает задачи, но и вновь поднимает ряд уже решенных вопросов. Мифическая "проблема с зависимостями" (напомним, малофункциональный пакетный менеджер) переносится им на следующий уровень иерархии, где ее решить уже гораздо сложнее. Автор этих строк в беседе с представителем Docker на одном из мероприятий в Москве с удивлением обнаружил, что "отсутствие зависимостей" до сих пор в их коммьюнити считается достижением, проблематика этой задачи ими просто не воспринимается, а мэйнтейнеры рассматриваются ими, как чинители препятствий, а не помощники. Из проблем с зависимостями, и привычек дуалбутчиков, составляющих заметную часть early adopters, вытекает следующая - большая часть приложений собраны неизвестно кем, никак не подписаны, и непонятно, что там внутри.

Наши коллеги грустно замечают, что пора бы не удовлетворять пользовательские хотелки, а говорить им "нет" (инвестировать время в обучение хорошим манерам).

Само по себе фактическое отсутствие цифровых подписей у образов Docker, после неудачной попытки их реализовать это не хорошо и не плохо - это дизайнерское решение такое. Исправить изначальное отсутствие подписей, это непростая задача, но иногда и не требующаяся. Например, Arch Linux долгое время раздавал никак не подписанные пакеты, и ничего не произошло. Никто же не будет использовать ненадежное решение в продакшене, ведь так? А вот помноженное на изначальную ставку на дистрибутив для начинающих (где, например, в принципе нет SELinux), пропагандируемое, как решение для production, и продвигаемое явочным порядком снизу, это уже гораздо хуже.

Небезопасность Docker была понята уже давным давно. Пока он используется frontend-разработчиками для создания сайтов-визиток и для тестов, повторимся, никаких проблем у вас это не вызовет (скорее всего не вызовет - просто используйте системы, где есть SELinux, и не выключайте его). Но для backend-разработчиков лучше сразу полагаться на более надежные решения. Ну, максимум, развернуть прототип, но продакшен вам все равно лучше бы деплоить без его использования. В Docker Inc это тоже поняли, и занялись улучшением ситуации, наняв недавно несколько специалистов.

К сожалению, зашли не с той стороны, пригласив специалистов с опытом проектирования и разработки распределенных систем, а не Base OS. Повторимся, слепым пятном коммьюнити Docker было и остается видение архитектуры Linux, связанное с изначальным Agile-решением ориентации на дистрибутив для начинающих, где специалистов в Base OS заметно меньше, чем в других сообществах.

Так или иначе, но, Docker набрал популярность, как и множество других неоптимальных решений, и нужно как то с этим жить. В отличие от головной компании-разработчика, мы выступаем за другой подход - безопасность Docker не сверху, а снизу, от пакетного менеджера, используемого при сборке образов, и SELinux при работе, до распространения сертифицированных образов через HTTPS.

И наш коллега Dan Walsh в очередной раз написал статью о той работе, которую они ведут по повышению надежности Docker-систем:

Безопасность Docker - будущее

image0

Я начал этот цикл статей о безопасности Docker с "контейнеры не ограничивают".

Одна из основных задач как в Red Hat, так и в Docker, это сделать это утверждение менее справедливым. Моя команда в Red Hat продолжает использовать другие механизмы безопасности, чтобы сделать контейнеры более безопасными. Далее перечислю некоторые фичи, над которыми мы сейчас работаем, и как они могут в будущем изменить Docker и контейнеры в целом.

User namespaces Пространство имен пользователей (user namespace), это еще один namespace в ядре, который должен позволить нам добиться более полного разделения между хостом и контейнером.

Идея в том, что вы можете задать интервал UID-ов (например, 60,000-61,000), которые вы можете транслировать в интервал 0-1000.

Тоже самое можно сделать с GID-ами. UID 0 внутри контейнера, ядро будет транслировать и обращаться как UID 60,000 снаружи контейнера. Любой другой UID файла или процесса, который не попадает в этот интервал, будет транслироваться в UID=-1 и не будет доступен в контейнере. Это относится и к базовому образу системы. Если вы хотите использовать образ с user namespace, тогда вам нужно сменить все UID внутри образа на новый UID, в т.ч. и суперпользователя. Еще одна проблема с user namespace, это то, что разделы, смонтированные в контейнер с файлами, владельцем которого является суперпользователь (UID 0), будут недоступны внутри контейнера. Вам следует поменять владельцев на весь контент, который вы будете использовать в контейнере:

chown -R 60000:60000 /var/lib/content

Другая проблема с user namespaces, это то, что если вы хотите использовать их для разделения между контейнерами, то вам понадобится свой интервал UID-ов для каждого контейнера. Если у вас сотни контейнеров, то вам будут нужны сотни диапазонов. Это же создаст еще одну проблему с разделением хранилища между хостовыми машинами.

Одна из прикольных штук с user namespace, это то, что их можно использовать вместе с capabilities.

Если вы запустите контейнер внутри user namespace, то он больше не будет нуждаться в capabilities реальной системы. Это значит, что мы можем подправить код, чтобы отказаться от системных capabilities, когда контейнер запускает user namespace. Это же позволяет нам отказаться от capabilities в метках SELinux.

Типичные сценарии использования Я могу представить как минимум три разных варианта использования user namespaces.

  • Улучшить разграничение между контейнерами до такой степени, что мы можем отключить все capabilities снаружи контейнера. Если это сделать, то мы улучшим и безопасность системы от контейнеров, но, ко сожалению, необязательно безопасность между контейнерами. В этом режиме, как я представляю себе, мы бы могли выбрать один общий UID для DOCKERROOT, затем настроить все контейнеры на его использование.

    Например, если DOCKERROOT будет UID=2, я бы настроил трансляцию для UID0=2 и GID0=2, а затем транслировал бы все UID-ы больше двух в самих же себя. Например, 3-MAX_UID=3-MAX_UID, и тоже самое для GID. Сделав это мы бы исключили возможность атаковать суперпользователя из контейнера. Это и проще реализовать при монтировании разделов.

    Я предложил, что может быть лучше попробовать просто использовать трансляцию user namespace по умолчанию, сопоставляя UID с 0-65000 этим же UID с 0-65000. Тогда, если вы смонтируете в контейнер файл, принадлежащий суперпользователю, как обычный раздел, то это сработает, но процессы снаружи контейнера не получат никаких capabilities.

    Так мы сможем более-менее разумно экспериментировать с user namespaces.

  • Метод OpenShift: все файлы внутри контейнера получают одну и ту же пару UID/GID. Каждый пользователь в системе получает уникальный UID. Это случай, когда пользовательский контейнер требует от процессов запускаться с kernel capability. Иначе, толку от этого мало.

  • Каждый контейнер получает отдельный диапазон UID от каждого другого контейнера. Это позволит запустить огромное число контейнеров с разделением UID-ов. Однако, сложность такого решения просто колоссальна. Монтирование разделов будет большой головной болью. Чтобы это заработало, я бы порекомендовал нам добавить что-то типа -v /SRC/DEST:U, которое бы сменило UID:GID /SRC во время монтирования на UID по умолчанию для контейнера.

Тем не менее, я не предполагаю, что эти три сценария могут использоваться одновременно. Я видел предложения от разработчиков ядра позволить "remapping of UIDs" в пределах точки монтирования, когда ее присоединяют к контейнеру, возможно даже для "bind mounts", но я оставлю обсуждение возможности реализации этого функционала разработчикам ядра, и я бы послушал безопасников насчет того, хорошая ли это идея вообще? Сейчас "user namespace" реализовано и включено в libcontainer, и готовятся патчи для Docker.

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

Ядро Linux для архитектуры x86_64 предоставляет более чем 600 системных вызовов, и ошибка в любом из них может вызвать эскалацию привилегий. Некоторые из этих сисколлов вызываются крайне редко, и их стоит исключить из списка доступных для контейнера.

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

Мой коллега, Paul Moore, решил упростить использование seccomp с помощью разработки библиотеки для легкого управления деревом системных вызовов. Теперь libseccomp используется в таких проектах, как qemu, systemd, lxc tools и т.д.. Мы также разработали биндинги к libseccomp для языка Go, чтобы включить в libcontainer для удаления сисколлов из контейнеров.

Мы предлагаем отказаться от следующих системных вызовов для контейнеров: kexec_load, open_by_handle_at, init_module, finit_module, delete_module, iopl, ioperm, swapon, swapoff, sysfs, sysctl, adjtimex, clock_adjtime, lookup_dcookie, perf_event_open, fanotify_init, and kcmp.

Мы также ждем от вас предожений о том, какие еще системные вызовы стоит сделать по умолчанию недоступными для контейнеров. А также мы обдумываем удалить все устаревшие сетевые стандарты в Linux: Amateur Radio X.25 (3), IPX (4), Appletalk (5), Netrom (6), Bridge (7), ATM VPC (8), X.25 (9), Amateur Radio X.25 PLP (11), DECNet (12), NetBEUI (13), Security (14), PF_KEY key management API (15), и все вызовы socket больше, чем than AF_NETLINK (16).

Еще одно последствие от создания фильтра запрещенных сисколлов, это то, что он будет блокировать вызовы к другой архитектуре.

Например, по умолчанию в контейнере с включенным seccomp будет запрещено вызывать сисколлы для архитектуры i386. Мы бы хотели сделать это поведение умолчальным.

С удалением сисколлов мы сокращаем поверхность атаки атаки вдвое.

Настройка Seccomp Мы также разрабатываем возможность передавать в Docker с помощью аргументов командной строки список системных вызовов, которые надо игнорировать, аналогично функционалу из capabilities и меткам SELinux. Например, эта команда запретит контейнеру получать его текущую рабочую директорию:

docker run -d --security-opt seccomp:deny:getcwd /bin/sh

Наоборот, эта команда вернет обработку вызова в контейнер:

docker run -d --security-opt seccomp:allow:clock_adjtime ntpd

Инженер Red Hat, Matt Heon, сделал презентацию этого функционала (вы также можете скачать видео в формате OGV):

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

docker run -d --security-opt seccomp:deny:all --security-opt seccomp:allow:getcwd /bin/sh

В реальности же вам, конечно, понадобится разрешить гораздо больше сисколлов, чтобы этот пример заработал. Сообщения о запретах системных вызовов начнут появляться в /var/log/audit/audit.log, также, как сейчас появляются ошибки SELinux, ну или в /var/log/messages, если audit не запущен.

Будущее Docker Мы продолжим изучение других security-фич, которые можно добавить.

Если новые фичи появятся в Linux, или улучшатся старые, то нам хотелось бы быть готовыми к использованию их в контейнерах.

Еще одна задача, которую мы начали изучать, это администрирование контейнеров. Сейчас, если вы можете открывать на чтение и/или запись порт Docker, то вы можете делать все, что хотите. Увы, но вы таким образом можете легко нарушить безопасность системы, и вот почему мы ограничили права доступа к /run/docker.socket всем непривилегированным пользователям. Мы работаем над добавлением авторизации, чтобы администратор контейнеров должен быть доказать, что он - некий конкретный пользователь. Мы также работаем над добавлением соответствующего журналирования событий, чтобы мы могли записывать в Journal/syslog кто запускает контейнеры. И наконец, мы хотим добавить управление доступом на основе ролей (Role Based Access Control, RBAC), чтобы суперпользователь мог контролировать что могут делать другие пользователи. Например:

  • Администратору №1 позволено лишь запускать/останавливать указанные контейнеры.
  • Администратору №2 разрешено создавать непривилегированные контейнеры, использующие указанный образ(ы).
  • Администратор №3 может запускать привилегированные контейнеры.

Выводы Когда весь этот функционал будет полностью реализован, то контейнеры Docker будут еще более лучше имунны к опасностям на хостовой системе. Цель одна - постоянно повышать возможность контейнеров ограничивать (игра слов - "ability for containers to contain").

Из других Docker-новостей - мы начали экспериментировать с gcc-go для его сборки вместо Golang от Google. Если кто не следит за апстримом, то работы там было много.

Учебный курс "Внутреннее устройство ядра Linux"

Это архивная статья

Инженер Parallels, Pavel Emelyanov, в своей ленте Google+ сообщает, что на Intuit наконец-то появился курс по ядру Linux, который он читает судентам МФТИ.

Школьникам старших классов укажем, что для того, чтобы получить доступ к лекциям Павла бесплатно и без регистрации, нужно лишь поступить в МФТИ.

Кроме этого курса на Физтехе вас научат много чему еще. Имейте в виду, абитуриенты.

Перезапуск squid удаляет все файлы в RHEL 6.7

Это архивная статья

Народ жалуется, что в RHEL 6.7 нельзя перезапускать squid, который при перезапуске сотрет все файлы. Баг открыт уже неделю.

Ну бывает, что. И вообще, незачем так привязываться к файлам на компьютере. Bumblebee-момент был и у Steam, например, и ничего.

Qemu 2.3

Скоро выходит Qemu 2.3. Список изменений все специфичнее и специфичнее, что показывает надежность продукта - новые процессоры, новые устройства, и прочие улучшения. Из интересного для разработчиков, это запуск Qemu c KVM под Valgrind. Это наверняка понравится разработчикам ядра и/или системного ПО низкого уровня.

Из удаляемых фич - встроенное шифрование Qcow2-дисков. Пока будет предупреждение, но в версии 2.4 фичу отключат навсегда. Используйте встроенные средства шифрования Linux.

Из других новостей о виртуализации - участники проекта Genode опубликовали обзорную статью о виртуализации на ARM, а Vasily A. Sartakov (ksys labs) поделился своими впечатлениями от FOSDEM 2015.