Обнаружен первый недостаток безопасности Kubernetes

kubernetes-логотип

Kubernetes стал самой популярной облачной контейнерной системой. Так что на самом деле обнаружение его первой серьезной бреши в системе безопасности было лишь вопросом времени.

Так и было, потому что недавно Первый серьезный недостаток безопасности в Kubernetes был выпущен под CVE-2018-1002105., также известный как сбой повышения привилегий.

Этот серьезный недостаток в Kubernetes является проблемой, поскольку это критическая дыра в безопасности CVSS 9.8. В случае первой серьезной уязвимости в безопасности Kubernetes.

Подробная информация об ошибке

Благодаря специально разработанной сети запросов любой пользователь может установить соединение через с сервера интерфейса прикладного программирования (API) Kubernetes на бэкэнд-сервер.

После создания злоумышленник может отправлять произвольные запросы через сетевое соединение непосредственно на этот сервер. в котором всегда целью является этот сервер.

Эти запросы аутентифицируются с использованием учетных данных TLS. (Transport Layer Security) с сервера Kubernetes API.

Что еще хуже, в конфигурации по умолчанию все пользователи (аутентифицированные или нет) могут запускать вызовы обнаружения API, которые позволяют злоумышленнику повысить привилегии.

Тогда любой, кто знает эту дыру, может воспользоваться возможностью взять под свой контроль свой кластер Kubernetes.

На данный момент нет простого способа определить, использовалась ли эта уязвимость ранее.

Поскольку неавторизованные запросы выполняются через установленное соединение, они не отображаются в журналах аудита сервера Kubernetes API или журнале сервера.

Kubernetes_Security

Запросы появляются в сводных журналах сервера API или kubelet., но они отличаются от правильно авторизованных и прокси-запросов через сервер Kubernetes API.

Злоупотреблять эта новая уязвимость в Kubernetes это не оставит очевидных следов в журналах, поэтому теперь, когда ошибка Kubernetes обнаружена, ее использование - лишь вопрос времени.

Другими словами, Red Hat сказал:

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

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

Любая программа, в том числе Kubernetes, уязвима. Дистрибьюторы Kubernetes уже выпускают исправления.

Red Hat сообщает, что затронуты все ее продукты и услуги на основе Kubernetes, включая Red Hat OpenShift Container Platform, Red Hat OpenShift Online и Red Hat OpenShift Dedicated.

Red Hat начала предоставлять затронутым пользователям исправления и обновления служб.

Насколько известно, пока никто не использовал брешь в системе безопасности для атаки. Даррен Шепард, главный архитектор и соучредитель лаборатории Rancher, обнаружил ошибку и сообщил о ней, используя процесс сообщения об уязвимостях Kubernetes.

Как исправить эту неисправность?

К счастью, исправление этой ошибки уже выпущено.. В котором только попросили выполнить обновление Kubernetes поэтому они могут выбрать некоторые из исправленных версий Kubernetes v1.10.11, v1.11.5, v1.12.3 и v1.13.0-RC.1.

Поэтому, если вы все еще используете какую-либо из версий Kubernetes v1.0.x-1.9.x, рекомендуется выполнить обновление до фиксированной версии.

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

Вам следует прекратить использование API агрегатов сервера или удалить разрешения pod exec / attach / portforward для пользователей, которые не должны иметь полный доступ к API kubelet.

Джордан Лиггитт, инженер-программист Google, исправивший ошибку, сказал, что эти меры, вероятно, будут пагубными.

Таким образом, единственное реальное решение против этой уязвимости в безопасности - это выполнить соответствующее обновление Kubernetes.


Будьте первым, чтобы комментировать

Оставьте свой комментарий

Ваш электронный адрес не будет опубликован. Обязательные для заполнения поля помечены *

*

*

  1. Ответственный за данные: AB Internet Networks 2008 SL
  2. Назначение данных: контроль спама, управление комментариями.
  3. Легитимация: ваше согласие
  4. Передача данных: данные не будут переданы третьим лицам, кроме как по закону.
  5. Хранение данных: база данных, размещенная в Occentus Networks (ЕС)
  6. Права: в любое время вы можете ограничить, восстановить и удалить свою информацию.