Состоялся (https://kubernetes.io/blog/2018/12/03/kubernetes-1-13-releas.../) релиз платформы оркестровки контейнеров Kubernetes 1.13 (http://kubernetes.io/), позволяющей как единым целым управлять кластером Linux-контейнеров, созданных с использованием таких инструментариев как Docker и rkt. В новой версии устранена критическая уязвимость (https://github.com/kubernetes/kubernetes/issues/71411) (CVE-2018-1002105 (https://security-tracker.debian.org/tracker/CVE-2018-1002105)) в реализации API, которая позволяет (https://access.redhat.com/security/vulnerabilities/3716411) любому пользователю получить полный контроль за кластером изолированных контейнеров. Проблема также устранена (https://groups.google.com/forum/m/#!topic/kubernetes-announc...) в обновлениях 1.10.11, 1.11.5 и 1.12.3.
Для совершения атаки достаточно отправить через API специально оформленный запрос определения доступных бэкентов (discovery-запрос). Из-за ошибки данный тип запросов позволяет использовать сервер API (kube-apiserver) в качестве посредника для подсоединения к любому бэкенду и перенаправить на бэкенд любые запросы, используя соединение, установленное с сервером API. Соответственно, перенаправляемые через подобное соединения запросы будут обработаны бэкендом как внутренние запросы от сервера API с использование параметров аутентификации сервера API.
По умолчанию все аутентифицированные и неаутентифицированные пользователи Kubernetes имеют возможность отправки через API discovery-запросов, которых достаточно для совершения атаки. Таким образом, любой непривилегированный пользователь Kubernetes, имеющий доступ к API, может получить полный контроль за всей инфраструктурой, например, отправив запрос exec для выполнения своего кода на хосте. Кроме получения контроля за инфраструктурой Kubernetes уязвимость также может применяться для целевых атак на клиентов через манипуляцию размещёнными в облаке клиентскими сервисами.
Проблема проявляется во всех версиях Kubernetes, начиная с релиза 1.0. Всем администраторам Kubernetes рекомендуется срочно обновить свои системы до актуальных выпусков, а также провести аудит системных логов на предмет возможной вредоносной активности. В качестве обходного метода защиты от атак со стороны неавторизированных пользователей можно запретить анонимный доступ к API при помощи опции "--anonymous-auth=false" и отозвать права на выполнение операций exec/attach/portforward. Отдельно отмечается, что в логах Kubernetes атака с использованием неавторизированных запросов никак не фиксируется, поэтому определить была ли компрометация можно лишь по косвенным признакам.
Основные (https://coreos.com/blog/whats-new-kubernetes-113) новшества (https://github.com/kubernetes/kubernetes/blob/master/CHANGEL...) Kubernetes 1.13:- Стабилизирован интерфейс CSI (Container Storage Interface), позволяющий стандартизировать плагины для поддержки различных систем хранения. CSI предоставляет единый интерфейс для выделения места, прикрепления и монтирования хранилищ, дающий возможнсть поставлять плагины для интеграции с различными службами хранения без необходимости внесения изменений в кодовую базу Kubernetes;
- По умолчанию задействован DNS-сервер CoreDNS (https://www.opennet.me/opennews/art.shtml?num=47674), развиваемый под эгидой организации Linux Foundation. CoreDNS написан на языке Go и примечателен гибкой архитектурой на базе подключаемых плагинов. Например, через плагины реализованы такие специфичные функции, как обнаружение сервисов Kubernetes, накопление метрик для системы мониторинга Prometheus и интеграция с системой хранения конфигурации etcd;
- Стабилизирован kubeadm (https://kubernetes.io/docs/reference/setup-tools/kubeadm/kub.../), упрощённый интерфейс для управления кластером Kubernetes, позволяющий выполнять такие операции как создание и развёртывание кластера на имеющемся оборудовании, настройка базовых компонентов Kubernete, подключение и удаление узлов, выполнение операций обновления;- Экспериментальный интерфейс для создания плагинов для интеграции со сторонними системами мониторинга;- Стабилизирован сервис Kubelet Device Plugin Registration, предоставляющий средства для доступа к Kubelet из плагинов;
- Стабилизирован планировщик распределения контейнеров TAVS (Topology Aware Volume Scheduling), учитывающий топологию разделов Pod (учитывает ограничения, установленные для узлов и зон);
- Перешли на стадию бета-тестирвоания APIServer DryRun, команда Kubectl Diff и возможность использования локальных (raw) блочных устройств в качестве хранилищ постоянных данных (Persistent Volume Source).Напомним, что код Kubernetes написан на языке Go и распространяется (http://github.com/kubernetes/kubernetes) под лицензией Apache 2.0. Проект изначально был создан компанией Google, но затем переведён на независимую площадку, курируемую организацией Linux Foundation. Платформа позиционируется как развиваемое сообществом универсальное решение, не привязанное к отдельным системам и способное работать с любыми приложениями в любых облачных окружениях.
Предоставляются функции для развёртывания и управления инфраструктурой, такие как ведение базы DNS, балансировка нагрузки,
распределение контейнеров по узлам кластера (миграция контейнеров в зависимости от изменения нагрузки и потребностей в сервисах), проверка работоспособности на уровне приложений, управление аккаунтами, обновление и динамическое масштабирование работающего кластера, без его остановки.
Возможно развёртывание групп контейнеров с выполнением операций обновлений и отмены изменений сразу для всей группы, а также логическое разбиение кластера на части с разделением ресурсов. Имеется поддержка динамической миграции приложений, для хранения данных которых могут применяться как локальные хранилища, так и сетевые системы хранения.URL: https://www.redhat.com/en/blog/kubernetes-privilege-escalati...
Новость: https://www.opennet.me/opennews/art.shtml?num=49722
>KubernetesЧто-то про эту штуку пишут куда ни плюнь. Какие-то семинары, съезды, конференции. Баги теперь ещё.
Это какой-то злобный маркетинг?
С разморозкой, сношают мозги уже не первый год.
Нет, просто она затыкает целый набор потребностей, а все альтернативы сильно уступают. Вот прямо сильно-сильно. Поэтому в жизни по факту можно встретить только k8s и docker swarm, но последнее обычно поднимается исключительно от нежелания разбираться с k8s (а самый его большой недостаток - он сложный и требует много всего для нормальной эксплуатации! Ну и далеко не все реализовано, что хотелось бы).Так что использовать k8s приходится практически безальтернативно, при этом многие хитрые вещи и интеграции требуют немалых усилий - вот и вылезают "семинары, съезды, конференции".
Подскажите, как они в сравнении с hashicorp nomad?
> Подскажите, как они в сравнении с hashicorp nomad?Какой ужас ))
Без понятия. Почитайте https://www.reddit.com/r/devops/comments/6o4ryf/nomad_vs_kub.../ или https://dev-ops-notes.ru/cloud/c%D1%80%D0.../
Товарищи уже объяснили: Nomad взяли из-за нежелания разбираться с k8s, из-за простоты его настройки и тесной интеграции с consul и vault, которые уже и без номада использовались на проекте. Пока что результатом довольны. Лично мне понравилась возможность генерить конфиги, которые будут использоваться в контейнере, из шаблона, в котором данные (переменные) берутся напрямую из консула и/или из волта. Есть внятная веб-морда.
И да, Swarm всех этих плюшек не имеет.
Если авс то можно впихнуть ECS и вздохнуть хоть там.
Поддерживаю. Если у Вас 100+ контейнеров, то k8s маст хэв.
Если меньше, то можно в принципе не заморачиваться. Я для малых проектов вообще поднимаю простой докер с фланелью и деплою контейнеры через ansible.
100++, справляемся без дырок на дырках. :)
> 100++, справляемся без дырок на дырках. :)Чувак, то, что и без k8s можно справляться при большом количестве контейнеров -- я не спорю. Я говорю, что при таких объёмах использование k8s уже оправдано, и с ним всё-таки легче и удобнее.
Вообще-то альтернатива есть - Serverless!
> Что-то про эту штуку пишут куда ни плюнь. Какие-то семинары, съезды, конференции. Баги теперь ещё.
> Это какой-то злобный маркетинг?Ну надо же ее как-то продать. И желательно подороже. Поэтому ее чуть ли не с первых версий форсили, как готовую к продакшн. Хотя большинству эта штука нафиг не нужна.
Это такой себе клаудстэк контейнерной и микросервис-эры, который позволяет автоматизировать кластеризацию/фэйловер/конфигурацию контейнеров и служб, основанных на них.
У нас порядка 50 отдельных проектов. Можно на каждый с проект по отдельному серверу. Но обычно не требуется такие мощьностию А в kubernates кластер можно их все запихать и не морочиться с распределением по машинам.
Ещё есть прикольная штука- helm. это package manager для серверных приложение.
Судя по описанию проблемы и учитывая, что "проблема проявляется во всех версиях Kubernetes, начиная с релиза 1.0" - это не совсем обычная дыра безопасности от кривой реализации. Это проблема архитектуры, логики работы. Ее наличие красноречиво говорит о мозгах разработчиков. Потенциально опасный продукт."О сколько нам открытий чудных..."
> Напомним, что код Kubernetes написан на языке Go
перепишите на D))) тут почитал книжку по D и...... понял что это такая смесь си++,питон и ява( тут не оч уверен). странный замес.))) пишите на нем))
D - огонь! Пишу на нём. Не хватает разрабов.
А QMLный гуй из D использовать можно?
Наверное, имелось ввиду, что на типа безопасных языках тоже уязвимости случаются.
программы пишут люди. естественно накосячить могут все. и что самое главное ни в одной программе их может и не быть, но появись они вместе создадут глюк или дыру в системе. это же известный факт. и никакой язык не может быть абсолютно безопасным. через тот же питон вызови в шелл "rm -rf /" ))) ну это утрирую , но принцип понятен. и нет абсолютно плохих языков или хороших. есть кривые руки)) и не подходящее применение( не своя стезя).
>> Напомним, что код Kubernetes написан на языке GoНаписали бы на си, все было бы по другому.
В параллельной stable-вселенной они и написаны на Си. А у нас testing-вселенная, так что, живём как живём... :(
> Проблема проявляется во всех версиях Kubernetes, начиная с релиза 1.0т.е. больше 3х лет
https://github.com/kubernetes/kubernetes/tags?after=v0.21.3очень ынтерпрайзно
Так не выставляй api и dash задницей на мороз и будет нормально, как будто в другом софте таких багов никогда не было
>уязвимость, позволяющая поднять свои привилегииНу так свои же :) Расходимся.
не поешь и поднять не сможешь))) брысь за редактор код писать)))
Что можно такого пихать в эти контейнеры, чего нельзя размещать под хостом, а раз уж необходимо, почему оно не может работать под нормальным KVM ?
[сообщение отредактировано модератором]
> Что можно такого пихать в эти контейнеры, чего нельзя размещать под хостом,
> а раз уж необходимо, почему оно не может работать под нормальным
> KVM ?Дык набирают хипстеров-разработчиков, и дальше оказывается, что они не готовы тратить время на то, чтобы обеспечить запуск их компонента в чем-либо, кроме последней убунте, в которой они его пишут. И не имеют желания разбираться с чем-то еще, потому что сложно, непонятно, не те версии и тд и тп.
И у администратора и других разработчиков тоже нет времени и желания обеспечивать, чтобы эти компоненты работали под чем-то еще. В какой-то момент приходится признать, что выгонять разработчиков не вариант, научить делать нормально нереально, а дяденьки, который за них приведет код в состояние, в котором этим можно будет как-то управляемо менеджить нет.
И приходится дать каждому разработчику свою песочницу, которую он уже сам себе делает для каждого компонента как ему нравится - с вкривь и вкось мешаниной из распаковки тарболлов / make install, pip и npm и прочим, с условияем, что за это отвечает сам разработчик. Потому что иначе он не умеет и учиться нормально не собирается, а стороннему человеку поддерживать эту кашу невозможно.
К счастью, можно заставить разработчика описать всю эту кашу разок в Dockerfile к каждому проекту и под угрозой увольнения заставить поддерживать хотя бы свои Dockerfile'ы к своим проектам. А дальше встает вопрос, как с этим жить. Виртуалки не вариант, потому что во-первых слишком тяжеловесные для такого применения, во-вторых нормально не скриптуются на таком уровне (не vagrant же брать, гвоздями приколоченному к virtualbox, у которого 50% функциональности отлетает при использовании libvirt плагина? И cloud-init тут тоже не спасает). Поэтому - от полного развала всего и вся спасает только docker. А дальше встают вопросы - как этот ворох контейнеров менеджить, раскидывать по машинкам с точки зрения оптимизации ресурсов, поднимать упавшие, масштабировать нужное число копий, устанавливать сетевые и прочие взаимодействия. Ну и приходим к kubernetes. Каким образом KVM-то поможет?
А kubernetes узлы можно при желании запускать в KVM, а не на голом железе. Правда, кроме как для dev или тестирования в этом смысла не очень много.
спасибо за коммент. Мне многое стало понятно про хипстеров и зачем нужны контейнеры. Спасибо!
Предлагаю описать как не используя динамическую инфраструктуру поднять новый тестовый стенд из сотни разных сервисов.
Потом сделать то же самое, но с каким-нибудь openstack. А когда через полгода надоест пытаться это сделать - подумать что может дать докер для этого.
> ПредлагаюСпасибо, что подыграли. Выше так и написали, что те, кто сами решать возникающие проблемы не хотят, просто переваливают всё на докер.
А если серьёзно, то конкретно в вашей ситуации докер, может, и нужен. Но в 99% интернет-блогов докер используется именно так, как описал аноним выше: чтобы пользователь вместо установки какой-то софтины просто брал контейнер, куда запрятана целая операционка.
И я опускаю вопрос о том, ЗАЧЕМ вам тестовый стенд из сотни серверов, и почему на тех задачах, которые вы с его использованием решаете, вы не можете заработать сумму, достаточную для более грамотной организацию процесса.
> Спасибо, что подыграли. Выше так и написали, что те, кто сами решать возникающие проблемы не хотят, просто переваливают всё на докер.Ну так дело, в целом, не в решении проблем и не в переваливании на докер.
Докер просто замечательный инструмент, чтобы делегировать ответственность за окружение приложения от админа к разработчику. Потому что даже если все не настолько ужасно, как я написал в примере выше, проблема того, что разработчик хочет чего-то, а у админа нет времени / желания разбираться / объяснять, что так глобально нельзя, а можно максимум в небольшой песочнице - возникает. И докер это хороший способ убрать эту проблему. Убрали - и больше разработчику не нужно чуть что, ходить на поклон к админу и согласовывать окружение. Это офигенно ускоряет процесс от разработки до выкатывания. Опять же, это возможность иметь CI, где разработчик может без каких-либо проблем менять продакшен окружение (правкой Dockerfile) в любой момент, когда это требуется.
Ну а использование докера в продакшене очень быстро приводит к внедрению k8s. Ибо если не он, то что?
> ...а у админа нет времени / желания разбираться / объяснять, что так
> глобально нельзя, а можно максимум в небольшой песочнице - возникает.Голые cgroups -- это _не_ песочница; так, авоська для удобствия.
> И докер это хороший способ убрать эту проблему. Убрали - и больше
> разработчику не нужно чуть что ходить на поклон к админу
> и согласовывать окружение....и не только разработчику ;-]
>чтобы делегировать ответственность за окружение приложения от админа к разработчикуА не сильно жирно разрабам решать на чём прод будет крутиться?
Если в конторе прод на CentOS/RHEL, то тестовое окружение должно быть на Центосе. На десктопе пусть себе абанту ставит. И зачем в данной схеме докер?
Вообще, проблема совместимости сильно раздута, для сишников это может и актуально, а всяким жаберам, питонщикам да JSникам плюс минус пара версий ни роялит.
Вот простой пример из реальной жизни: у разработчиков Федора,
на продакшене CentOS. Баги у первых не воспроизводятся, но присутствуют на центосе из-за разных версий зависимостей (версии системных либ, и, вы будете удивлены, проект на питоне, но проблема всё же во внешних непитоновых зависимостях).Как тут девелопить и дебажить? Юзать центос на десктопе как-то никто не хочет, да и админы, ответственные за рабочие станции, говорят что это плохая идея. Поднимать целую VM не вижу смысла, тем более, это неудобно даже с тем же "упрощающим разработку" Vagrant – не ясно как синхронизировать рабочий каталог в две стороны, да так, чтобы файлы оставались доступными из хоста когда VM остановлена.
Доцкер эту проблему успешно решает. Во время разработки каталог с кодом монтируется волюмом в контейнер и позволяет делать то что нам нужно (бесшовная двусторонняя синхронизация без задержек, т.к. по сути это mount в пределах локальной ФС). Во время сбокри имиджа волюм не используется, а производится чистый git clone всего из репы, куда выкладывается уже готовый код. Имидж собираем сами из того же центоса. А коль уж у нас есть самособранный имидж, куда мы самостоятельно прописали зависимости, и он по максимуму воспроизводит окружение, которое уже есть на проде (который пока ещё без всяких контейнеров), то почему бы эти имиджи не выкатывать сразу на прод вместо ручной установки и настройки всего? Ведь это и так приходится делать во время разработки, почему бы не использовать уже однажды настроенное. Само собой, это позволит оттестировать на машине разработчика не только обновление нашего приложения, а и системного окружения.
Из приятных бонусов это даёт возможность развернуть несколько инстансов для разных нужд (один исполняет только внутренние задачи, другой обслуживает клиентов по http, третий тоже и т.д.) одинаково легко хоть на одной машине, хоть на разных, благо отдельно стоящая БД это позволяет. Так можно было и раньше используя несколько обычных машинок (физических или VM) и какой-нибудь Ansible, но тут профит в том, что контейнер стартует моментально после скачивания имиджа, и не надо ждать пока yum всё поставит. Если машин много, то надо ждать установки и переконфигурации каждой, а в случае с контейнерами достаточно дождаться скачивания имиджа и пересоздания контейнера на нём. При использовании инкрементальных обновлений (т.е. слоёв, базирующихся на предыдущем выкаченном имидже) это происходит очень быстро.
Насчёт оверхеда – его мало в плане цпу и памяти, ведь не используется виртуализация и своё ядро (и да, в плане изоляции это минус). В плане дискового оверхеда – если грамотно собирать имиджи (правильно формировать слои), то он получается небольшой благодаря переиспользованию нижележащих слоёв (если есть три имиджа, которые базируются на четвёртом, то на диске окажется лишь один экземпляр четвёртого).
> Во время сбокри имиджа волюм не используетсяИмеется в виду "во время сборки для CI или продакшена", т.е. не во время разработки.
>у разработчиков Федора,на продакшене CentOS.
>Баги у первых не воспроизводятся, но присутствуют
>на центосе из-за разных версий зависимостейЯ так и не понял. В каких-то центосовых либах якобы баги, а в федоре нет (что уже звучит фантастично). Девки ваши соберут свою прожку с либами от федоры и выкатят в прод? Ну в пень, это не решение проблемы.
А если докер им нужен только для "более удобного дебага с центосовыми либами, сидя в федоре", то спрашивается, а зачем потом тащить этот ваш доцкер дальше машины девы?
То что доцкер решает какие-то проблемы никто не спорит, плохо то, что он привносит другие проблемы плюс оверхед _в разработку_. У меня есть на виду один фанатик. Иногда на банальных вещах стопорится на день. Чего-то там пересобирает, ковыряет, перенастраивает.
И в целом, от докерофилов много блабла про удобство работы и плюшки и тд, а по факту, из официальной yum репы софт обновляется как часы, а докерный софт дева висит месяцами протухший. Ну работает же.
Я бы по-другому сказал - докер - это способ разделить софт на компоненты с явно указанными зависимостями. Нужен какой-то порт открытый - пропиши, нужен доступ куда-то на диск - пропиши, и так далее. В общем, естественное следствие массового увеличения сложности софта и способ борьбы с ней.То есть не "у кого-то нет желания разбираться", а совершенно закономерное повышение уровня, которое началось с того, что нумерованным ячейкам памяти стали присваивать имена, а инструкции писать символьными обозначениями.
> Ну а использование докера в продакшене очень быстро приводит к внедрению k8s.
> Ибо если не он, то что?Соглашусь. Докер, конечно классный инструмент, но заставляет очень быстро деградировать. Причем, как админов, так и разработчиков.
Пример его полезности с точки зрения админа - мне недавно надо было поднять несколько кибан разных версий, для разных кластеров эластики. И один общий контейнер для эласталерта. Докер - отлично подошел. Городить это на виртуалках я бы задолбался, к тому же это лишние сущности.
Пример полезности с точки зрения разработчика - дев окружения, но крайней мере в веб разработке. Запушили, проект оттестировался, собрался и можно легко посмотреть результат.
Пример вреда докера - разработчики и новоиспеченные девопсы пытаются абсолютно все завернуть в докер. Файлшаринг(20Гб) для мелкого проекта на виртулке - это больше не по девопсовски, завернем его еще и контейнер, а хранилку маунтом прокинем. Дикость? Я считаю да. Наш новоявленный девопс считает, что только так и надо устанавливать по.Я кстати так и не понял, как использование докера связано с k8s? На мой взгляд, возможности kubernetes для большинства задач избыточны, swarm'а хватит.
Вообще-то в Докер-контейнере нет ОС! Потому-то они и такие маленькие... и это их основное преимущество перед КВМ и пр.
Переводя на общепонятный русский, необходимость в контейнерной изоляции вызвана к жизни единственно низким уровнем квалификации молодой поросли эм… клавиатурных работников?
Истинно так.
> Переводя на общепонятный русский, необходимость в контейнерной изоляции вызвана к жизни
> единственно низким уровнем квалификации молодой поросли эм… клавиатурных работников?Нет. Причина в фрагментации линукса. Васяны, делающие свои дистры почему то надеются, что под них тут же начнут все подстраиваться.
Есть формальная логика, есть женская -- но вот по продемонстрированной выше "васяны, делающие свои дистры" вдруг сцементировались и выкатили контейнеры.Мне одному кажется, что эта логика не тянет даже на такое название?
Нет. Вернее, не только.
Ещё точнее: если бы k8s возник _только_ по вышеуказаной причине, то его бы никто не продал, будь этим кем-то сам гугл.
На разработчиков проще всего свалить все проблемы. Это слишком близоруко.
> На разработчиков проще всего свалить все проблемы. Это слишком близоруко.Прости, если сможешь, Леннарт. Я был политически и морально близорук.
Молодец! Осталось поработать над ошибками.
Нет. Причина, как и всегда - в усложнении массово применяемого софта (включая условия его использования) и необходимости сохранять при этом хоть как-то разумные бюджеты на его написание и поддержку.
Не только и не столько...
Суть в модульности и масштабируемости. И, как побочный эффект, - упрощение системы.
> В какой-то момент приходится признать... что лучше закрыться, а не корчить из себя эффективного менеджера целой компании ...
(это по итогам: что выгонять разработчиков не вариант, научить делать нормально нереально, а дяденьки, который за них приведет код в состояние, в котором этим можно будет как-то управляемо менеджить нет)
>а дяденьки, который за них приведет код в состояние, в котором этим можно будет как-то управляемо менеджить нет.Здравствуйте, я тот самый дяденька, который заставляет их приводить код в состояние, в котором его можно хоть как-то управляемо менеджить. Спрашивайте свои вопросы.
https://gitlab.freedesktop.org/polkit/polkit/issues/74PolicyKit: Users with UID greater than INT_MAX can execute any systemctl command
Девопсненько.