Охота за ошибками в Kubernetes официально открыта

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.
Прим. перев.: Две недели назад стартовала программа Bug Bounty у Kubernetes — долгожданный и важный шаг для столь масштабного Open Source-проекта. В рамках этой инициативы любой энтузиаст, обнаруживший проблему в безопасности K8s, может получить награду в объёме от 100 USD (минимальная критичность) до 10 000 USD (наивысшая критичность для компонента из ядра Kubernetes). Анонс программы был сделан сотрудниками Google, занимающимися безопасностью K8s — его перевод представлен ниже.



14 января Комитет по безопасности продукта Kubernetes (Kubernetes Product Security Committee) запустил новую программу bug bounty, в рамках которой исследователи будут получать вознаграждение за обнаруженные уязвимости в Kubernetes. Спонсором программы выступает CNCF.

Описание программы


Мы старались сформулировать правила этой программы максимально прозрачно, чему способствовали изначальное предложение, предварительная оценка поставщиков соответствующих услуг и рабочий план с перечислением изучаемых компонентов. Как только мы определись с платформой — HackerOne, — эти документы были доработаны на основе замечаний и предложений, внесенных HackerOne, а также информации, полученной по итогам недавнего аудита безопасности Kubernetes.

Программа bug bounty в течение нескольких месяцев велась в закрытом формате: приглашенные специалисты сообщали об ошибках и помогали нам тестировать процесс фильтрации. И вот спустя почти два года после изначального предложения программа, наконец, готова и приветствует всех, кто спешит помочь нам в борьбе с ошибками!

Особо волнителен тот факт, что программы bug bounty крайне редко проводятся для инфраструктурных Open Source-проектов. Некоторые программы по поиску ошибок в Open Source хорошо известны — например, Internet Bug Bounty. Однако они преимущественно концентрируются на базовых компонентах, которые последовательно развертываются в разных средах. Большинство же программ bug bounty проводятся для веб-приложений.

На самом деле, с учетом того, что сейчас насчитывается более 100 сертифицированных дистрибутивов Kubernetes (по ссылке перечислены не продукты, а поставщики услуг [KCSP] — самих же дистрибутивов на сегодняшний день несколько меньше — прим. перев.), программа bug bounty должна быть применена к коду Kubernetes, который лежит в основе их всех.

Пока что самой трудоемкой задачей было убедиться, что поставщик платформы (HackerOne) и его специалисты, выполняющие предварительную сортировку, имеют достаточное представление о Kubernetes и способны подтвердить наличие бага, о котором поступил отчет. В рамках подготовительного этапа команда HackerOne сдала экзамен на сертифицированных администраторов Kubernetes (Certified Kubernetes Administrator, CKA).

Что входит в программу?


Bug bounty охватывает код основных компонентов экосистемы Kubernetes на GitHub, а также артефакты непрерывной интеграции, релизов и документации. По сути, в программе участвует бóльшая часть контента, включенного в https://github.com/kubernetes, — того, которое будете ассоциировать с «ядром» Kubernetes. Нам особенно интересны атаки на кластер, такие как эскалация привилегий, ошибки аутентификации и удаленное выполнение кода в kubelet или на API-сервере.

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

Следует отметить, что программа не покрывает инструментарий для взаимодействия с сообществом — например, списки рассылок Kubernetes или канал в Slack. Выходы из контейнеров, атаки на ядро Linux или другие зависимости (вроде etcd) также выходят за рамки нашего интереса (их следует направлять соответствующим сторонам). При этом мы будем признательны, если вы приватно сообщите Комитету по безопасности продуктов Kubernetes о найденных уязвимостях, связанных с Kubernetes, даже если они выходят за рамки bug bounty.

С полным списком тем и направлений в рамках bug bounty можно ознакомиться на странице программы.

Порядок работы с уязвимостями и раскрытие информации


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

В нашем случае платформа HackerOne занимается организацией программы, первичной сортировкой и базовой оценкой. Благодаря этому наши эксперты по безопасности Kubernetes могут сконцентрироваться на действительно значимых ошибках. Все остальное остается прежним: Комитет по безопасности продолжит заниматься разработкой исправлений, собирать закрытые патчи и координировать специальные релизы. Выход новых релизов с исправлениями безопасности будет анонсироваться в канале kubernetes-security-announce@googlegroups.com.

Желающие сообщить об ошибке могут сделать это и классическим способом (в обход программы bug bounty). Для этого пришлите свой отчет на security@kubernetes.io.

С чего начать?


Так же, как многие организации поддерживают ПО с открытым исходным кодом, нанимая разработчиков, выплата вознаграждений в рамках bug bounty позволяет поддержать исследователей в области безопасности. Эта программа является критическим шагом для Kubernetes, позволяя укрепить собственное сообщество специалистов по безопасности и вознаградить их за тяжелую работу.

Если вы специалист по безопасности, малознакомый с Kubernetes, обратите внимание на следующие ресурсы. Они помогут начать охоту за ошибками:

  • Руководства по безопасности:
    • Kubernetes.io.
  • Фреймворки:
    • CIS benchmarks;
    • NIST 800-190.
  • Выступления:
    • The Devil in the Details: Kubernetes’ First Security Assessment (KubeCon NA 2019);
    • Crafty Requests: Deep Dive into Kubernetes CVE-2018-1002105 (KubeCon EU 2019);
    • A Hacker’s Guide to Kubernetes and the Cloud (KubeCon EU 2018);
    • Shipping in pirate-infested waters (KubeCon NA 2017);
    • Hacking and Hardening Kubernetes clusters by example (KubeCon NA 2017).

Если вы обнаружили уязвимость, пожалуйста, сообщите о ней в программу Kubernetes bug bounty по адресу https://hackerone.com/kubernetes.

P.S. от переводчика


Читайте также в нашем блоге:

  • «Helm 3 прошёл независимый аудит безопасности»;
  • «33+ инструмента для безопасности Kubernetes»;
  • «Docker и Kubernetes в требовательных к безопасности окружениях»;
  • «9 лучших практик по обеспечению безопасности в Kubernetes».
Источник: https://habr.com/ru/company/flant/blog/485838/


Интересные статьи

Интересные статьи

Статья о том, как упорядочить найм1. Информируем о вакансии2. Ведём до найма3. Автоматизируем скучное4. Оформляем и выводим на работу5. Отчитываемся по итогам6. Помогаем с адаптацией...
Те, кто собираются открывать интернет-магазин, предварительно начитавшись в интернете о важности уникального контента, о фильтрах, накладываемых поисковиками за копирование материалов с других ресурсо...
Есть статьи о недостатках Битрикса, которые написаны программистами. Недостатки, описанные в них рядовому пользователю безразличны, ведь он не собирается ничего программировать.
В интернет-магазинах, в том числе сделанных на готовых решениях 1C-Битрикс, часто неправильно реализован функционал быстрого заказа «Купить в 1 клик».
Если Вы используете в своих проектах инфоблоки 2.0 и таблицы InnoDB, то есть шанс в один прекрасный момент столкнуться с ошибкой MySQL «SQL Error (1118): Row size too large. The maximum row si...