Безопасное развёртывание контейнерных приложений

При развёртывании контейнерных приложений в облаке можно столкнуться с рядом проблем, которые повлекут за собой появление уязвимостей. Уязвимости могут возникать на нескольких уровнях:

• В вашем коде, коде библиотек или из-за случайной загрузки секрета в репозиторий при разработке.

• В утилитах или компонентах контейнера, таких как операционная система, а также из‑за небезопасной конфигурации Dockerfile.

• Внутри кластера Kubernetes. Например, из-за небезопасной доставки секретов или избыточных прав.

• На ноде Kubernetes. Например, при её неправильной конфигурации.

Рассмотрим каждую из этих проблем более подробно.

Как избежать уязвимостей кода и компонентов в Docker-образеКак избежать уязвимостей кода и компонентов в Docker-образе

С первой проблемой можно столкнуться ещё на этапе разработки. Даже если наш собственный код не содержит уязвимостей, они могут быть в библиотеках и инструментах. Например, в нашем проекте может использоваться bash старой версии, имеющий серию уязвимостей Shellshock, которая позволяет злоумышленнику получить неправомерный доступ и выполнять произвольные команды.

При развёртывании продукта в Yandex Managed Service for Kubernetes^® на этапе сборки Docker-образа и его загрузки в Container Registry мы рекомендуем использовать сканер уязвимостей для того, чтобы выявить проблемы и снизить риски безопасности. Проверка уязвимостей осуществляется по базе данных Vulners и позволяет подсветить обнаруженные проблемы в пакетах используемого образа. Устранить большую часть уязвимостей на данном этапе поможет использование базовых образов Docker от доверенных паблишеров или их проверка на уязвимости в закрытом реестре. Это позволит избежать использования устаревших образов или образов с намеренно оставленными уязвимостями. Нужно не забывать и про обновление пакетов.

Как создать безопасную конфигурацию образаКак создать безопасную конфигурацию образа

Кроме уязвимостей в коде и компонентах, на этапе сборки образа к проблемам безопасности может привести неправильная конфигурация Dockerfile. Например, использование небезопасного базового образа с тегом latest, выдача избыточных прав пользователю или монтирование слишком большой директории при сборке. Чтобы понять, есть ли проблема, можно использовать статические проверки Dockerfile. Для этого нам пригодятся два инструмента: Open Policy Agent (OPA) — инструмент для создания политик, и Conftest — CLI для создания правил проверки политик. В официальном репозитории Conftest есть примеры проверок, которые можно запустить на собственных образах. Также можно самостоятельно создать правила, чтобы с их помощью найти потенциальные угрозы безопасности в конфигурации Docker-образа.

Как избежать проблем безопасности нодыКак избежать проблем безопасности ноды

После успешной сборки безопасной конфигурации Docker-образа и загрузки его в реестр можно столкнуться с ещё одной проблемой уже непосредственно при развёртывании проекта в Kubernetes. Это устаревшие версии пакетов и образов, использующиеся на ноде. Уязвимости здесь появляются так же, как и в случае с аналогичной проблемой внутри проекта, и решение будет похожим — нужно обновлять ноды. При использовании Yandex Managed Service for Kubernetes^® это легко сделать через интерфейс или консоль. Можно также настроить автоматическое обновление, благодаря которому нода самостоятельно обновится в удобное для клиента время, когда появится новая версия.

Зачем шифровать secretsЗачем шифровать secrets

В Kubernetes secrets (секреты) — это внутренние объекты, которые хранят в себе конфиденциальную информацию, такую как ключи, пароли, API-токены. Доступ к этим данным должен быть ограничен. Но при развёртывании приложения в Kubernetes мы сталкиваемся с проблемой: по умолчанию секреты хранятся в формате Base64, что не позволяет организовать безопасную передачу этих данных внутрь Kubernetes, например в YAML-манифесте.

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

Secret Manager — это целый класс продуктов. У ряда публичных облачных сервисов есть свои версии, есть также очень известный продукт HashiCorp Vault, который мы используем с Key Management Service. У него много плюсов, но есть несколько особенностей, которые нужно учитывать. HashiCorp Vault использует Agent Sidecar Injector для интеграции c Kubernetes, что подразумевает создание дополнительного контейнера к уже существующему и, соответственно, дополнительную настройку. Кроме того, у него нет возможности выгрузки данных аудита, а для дешифрования данных обычно требуется вручную получать мастер-ключ. В Yandex Cloud создали Docker-образ, интегрированный с Key Management Service, в котором реализована функция Auto Unseal, позволяющая автоматически получать мастер-ключ при включении или перезагрузке сервера.

Помимо этого, в Yandex Cloud разработали собственный Secret Manager — Lockbox. Он поддерживает шифрование секретов с помощью ключей Key Management Service, разграничение доступа и централизованное хранение. Для интеграции Lockbox и Kubernetes использован open-source продукт External Secrets. Секреты, хранящиеся в Lockbox, передаются в нужные namespace с помощью External Secrets Operator, при этом аудит событий выгружается в сервис Audit Trails.

Использование Secret Manager позволяет снизить риск утечки секретов в незашифрованном виде.

Существует ещё одна проблема, связанная с отсутствием шифрования секретов. Непосредственно внутри кластера Kubernetes секреты хранятся в открытом виде в key-value базе данных под названием ETCD. Это позволяет злоумышленнику, например, при получении незашифрованного бэкапа увидеть все имеющиеся в данном кластере секреты. В Yandex Cloud есть защита от атак master host, но для снижения рисков нужно включать опцию шифрования в Kubernetes, что легко делается при использовании образа с интеграцией с Key Management Service.

К чему приводит избыточность прав и сетевых доступовК чему приводит избыточность прав и сетевых доступов

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

Угрозу безопасности могут создавать и избыточные сетевые доступы — из одного пода в другие поды, в интернет или к сервису метаданных, который позволяет получать сертификаты, ssh-ключи, токены сервисного аккаунта.

Так, избыточные сетевые доступы из пода к сервису метаданных могут дать возможность злоумышленнику, попавшему в под, получить доступ к сервисному аккаунту ноды. Если сервисный аккаунт в свою очередь имеет избыточные права, то злоумышленник сможет совершать любые действия от его имени, например, запустить собственную виртуальную машину. Избежать подобных проблем несложно, достаточно применить простую network policy на исходящий трафик.

kubectl create -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-egress
spec:
  podSelector: {}
  policyTypes:
  - Egress
EOF
networkpolicy.networking.k8s.io/default-deny-egresscreated

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

Как отслеживать аномалии сети и контролировать доступКак отслеживать аномалии сети и контролировать доступ

Избыточные права сервисного аккаунта на поде могут привести к успешной атаке container escape, в ходе которой из пода, к которому злоумышленник имеет доступ, создаётся новый привилегированный под с доступом к host-процессу ноды. Из нового пода можно смотреть служебные контейнеры, искать незашифрованные секреты, анализировать сетевой трафик, обращаться к другим подам.

Чтобы защититься от подобных атак, нужно грамотно настроить сетевые политики и анализировать аномалии сети. В Yandex Managed Services for Kubernetes реализована поддержка контроллера сетевых политик Cilium. Он позволяет создавать расширенные сетевые политики и подробную карту сети для отслеживания аномалий. Проанализировать аномалии позволяет Falco — инструмент контроля безопасности, который пропускает через себя все взаимодействия подов и нод, такие как системные вызовы, переходы между namespace, сетевое взаимодействие. Работать с алертами Falco непросто, поэтому команда Yandex Cloud создала Security Solution Library, в которой собраны полезные решения. Одно из этих решений — анализ логов безопасности Kubernetes в облаке Yandex Cloud. Оно содержит Falco и приложение для управления политиками (по умолчанию — Kyverno, но можно установить и OPA). В решение встроен Yandex Managed service for Elasticsearch, куда выгружаются алерты и аудитные логи Kubernetes и где уже подготовлены правила реагирования, дашборды и другая информация о безопасности.

Решение позволяет наглядно с помощью дашбордов в Yandex Managed service for Elasticsearch и Kyverno наблюдать срабатывания при осуществлении вышеперечисленных угроз безопасности, например таких, как использование уязвимостей Shellshock или запуск привилегированного контейнера.

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