Безопасность Kubernetes: защита приложений от незакрытых уязвимостей

Установка исправлений для системы или решения помогает обеспечить безопасность и надежность. Но что, если производитель не выпускает патч для известной ошибки или уязвимости? Именно такая ситуация возникла с CVE-2020-8554, уязвимостью безопасности в Kubernetes. Уязвимость была обнаружена год назад и до сих пор не исправлена. Платформа Kubernetes широко популярна и быстро развивается, поэтому важно, чтобы подобные уязвимости были закрыты или, по крайней мере, каким-то образом смягчены, чтобы злоумышленники не могли нарушить работу вашей среды. Но это также поднимает более важный вопрос: что делать, если поставщик используемого вами продукта или решения по какой-либо причине не может исправить известные уязвимости.

Безопасность Kubernetes: помните об этой уязвимости

«В ноябре, — говорит Гади Наор, — в проекте Kubernetes была обнаружена уязвимость, о которой должен знать каждый администратор или пользователь Kubernetes». Гади является экспертом по безопасности во время выполнения приложений, нативных для Kubernetes, а также является техническим директором и соучредителем Alcide, ведущего поставщика решений для обеспечения безопасности Kubernetes. «Уязвимость, известная как CVE-2020-8554, — продолжает он, — связана с разрешениями по умолчанию, позволяющими пользователям создавать объекты, которые могут действовать как человек посередине (MiTM) и, следовательно, потенциально перехватывать конфиденциальные данные. Уязвимость работает путем перенаправления законного сетевого трафика жертвы через тайного злоумышленника в сети, где злоумышленник может подслушать или активно изменить данные жертвы, прежде чем отправить их по назначению».

Это что-то новое в Kubernetes? Затем я спросил об этом, и он ответил: «Большинство ранее обнаруженных атак MiTM использовали чрезмерно разрешительный способ, которым Kubernetes по умолчанию выделяет рабочие нагрузки/модули — в частности, разрешения CAP_NET_RAW. В отличие от предыдущих уязвимостей, эта уязвимость связана с дизайном и поведением API Kubernetes, и для нее не существует доступных исправлений или исправлений программного обеспечения. Злоумышленник, получивший разрешение на создание службы Kubernetes типа LoadBalancer или ClusterIP, может перехватить сетевой трафик, исходящий от других модулей в кластере. Например, кластеры Kubernetes с несколькими арендаторами позволят одному арендатору перехватывать сетевой трафик другого арендатора».

Я задался вопросом, может ли причина, по которой эта уязвимость еще не была исправлена, быть связана с быстрыми темпами разработки версий Kubernetes. Или могут быть другие причины, связанные с задержкой более чем на год с исправлением этой уязвимости. «Для этой проблемы нет патча, — говорит Гади, — и в настоящее время ее можно смягчить, только установив активное применение политики, которое идентифицирует и ограничивает пользователей, которым разрешено создавать Сервис, но которые пытаются использовать этот недостаток дизайна. Поскольку это ошибка в дизайне Kubernetes, для исправления потребуется кардинальное изменение».

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

Кривая обучения

«Это означает, что существует здоровая кривая обучения, которую практикующим специалистам необходимо будет пройти, усвоить, понять и постепенно внедрять в систему. Практику можно условно разделить на три области. Во-первых, конфигурация и состояние безопасности, связанные с непрерывным обеспечением соблюдения требований — они могут обеспечить большой поверхностный охват с точки зрения снижения рисков и потенциальных векторов угроз. Во-вторых, защита рабочей нагрузки во время выполнения, которая вращается вокруг сегментации сети, мониторинга процессов, обнаружения угроз и предотвращения. И в-третьих, мониторинг угроз инфраструктуры Kubernetes во время выполнения, который фиксирует анализ поведения пользователей и объектов с использованием как политик соответствия, так и машинного обучения для обнаружения аномалий и инцидентов, связанных с использованием инфраструктуры Kubernetes».

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

Возможное решение

Сосредоточившись на решении, я спросил его, как сканирование в реальном времени и машинное обучение могут защитить приложения Kubernetes от незакрытых уязвимостей, таких как CVE-2020-8554. «CVE-2020-8554 относится к тому классу уязвимостей безопасности, которые могут быть обнаружены с помощью относительно простого анализа конфигурации, тогда как предотвращение может быть реализовано с помощью механизма расширения механизма, специфичного для Kubernetes, называемого контроллерами доступа, который позволяет операторам Kubernetes использовать подключаемый модуль, который может использоваться для определения и применения мелкозернистой политики, специально предназначенной для этой неправильной конфигурации».

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