Состоялся (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.ru/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.ru/opennews/art.shtml?num=49722
