Kubernetes — ценный ресурс и ведущая система управления контейнерами в конвейерах разработки по всему миру, но это не освобождает её от вредоносных атак. Использование Kubernetes требует глубокого понимания среды, включая разные уязвимости, с которыми можно столкнуться при создании, развертывании или запуске приложений в ваших кластерах.
Поскольку кластер Kubernetes один из самых ценных облачных ресурсов, он нуждается в защите. Его безопасность обеспечивает безопасность облака, кластеров приложений, контейнеров, приложений и кода. Хотя Kubernetes обеспечивает преимущества в области безопасности, укрепление способов защиты имеет решающее значение для обороны вашей системы от хакеров и других кибер-угроз.
В этом обзоре рассматриваются семь основных способов, которые могут подвергнуть кластер атаке, с соответствующими мерами противодействия к каждому.
Зачем вам нужна защитная тактика для избегания взлома
Из-за распределенной и динамичной природы кластера Kubernetes необходимо применять тактику защиты, соответствующую лучшим методам обеспечения безопасности на протяжении всего жизненного цикла контейнера.
Хотя в Kubernetes есть несколько проблем безопасности на протяжении всего жизненного цикла приложения (сборка, развертывание и время выполнения), некоторые из наиболее важных проблем безопасности включают:
Использование кодов из непроверенных публичных реестров с открытым исходным кодом. Это создаёт бэкдоры, которыми могут воспользоваться субъекты угроз, получив доступ к критически важным ресурсам. Нужно защитить цепочку поставок программного обеспечения от вредоносных атак.
Несоблюдение принципа наименьших привилегий (PoLP). PoLP гарантирует, что вы ограничиваете привилегии, к которым имеют доступ пользователи. Согласно CISA, если субъекту не требуется право доступа, у него не должно быть этого права. Предоставление ненужных привилегий расширяет возможности атаки и создает больше лазеек в системе безопасности, которыми могут воспользоваться злоумышленники.
Создание сложных кластеров Kubernetes. Это затрудняет изоляцию и замену скомпрометированных кластеров при атаке, затрудняя процесс исправления. Так разработка адекватных стратегий защиты является ключом к постоянной защите кластеров от злоумышленников и неправильных настроек.
Семь лучших тактик защиты кластеров Kubernetes
Хотя Kubernetes по умолчанию включает некоторые важные меры безопасности, разработчики должны изучить наиболее действенные методы для обеспечения безопасности своих кластеров.
Тактика защиты, описанная в этой статье, была выбрана на основе рекомендаций отраслевых стандартов по предотвращению взлома Kubernetes. В ней содержатся комментарии нескольких экспертов, объясняющие, как и почему эти стратегии помогут обезопасить рабочие нагрузки Kubernetes и снизить риски облачной среды.
1. ABAC против RBAC
Хотя управление доступом на основе атрибутов (ABAC) является отличным методом контроля доступа, его сложно понять и управлять им. Помимо своей сложности, ABAC предоставляет права доступа пользователям на основе пользовательских атрибутов, таких как атрибуты субъекта, атрибуты ресурса и атрибуты среды. ABAC предоставляет пользователям общекластерное разрешение делать все, что они хотят: создавать ресурсы в кластере, просматривать секреты, удалять коды и многое другое. Это не обеспечивает максимальной защиты и может иметь катастрофические последствия.
Kubernetes объявила о выпуске Kubernetes 1.6 28 марта 2017 года, заявив, что управление доступом на основе ролей (RBAC), kubefed, kubeadm и другие функции планирования переходят в бета-версию. Переход RBAC в бета-версию стал главным событием этого анонса. Эндрю Грант, соучредитель Control Plane и соавтор Hacking Kubernetes, отметил в статье, что ABAC был заменен RBAC с версии 1.6 и что его не следует использовать на сервере API.
По словам Гранта, отключение ABAC и включение RBAC с наименьшими привилегиями обеспечивают мощную защиту от взлома. В отличие от ABAC, RBAC предоставляет права доступа пользователям на основе их ролей. Например, в то время как команда DevOps может иметь доступ к файлам программирования, команда управления проектом будет иметь доступ ко всем файлам проекта. Это пример того, что делает RBAC — включение разрешений на основе функций пользователей.
Вы можете включить RBAC, запустив сервер kube-apiserver с флагом --authorization-mode:
kube-apiserver --authorization-mode=Example,RBAC --other-options --more-optionsБолее подробную информацию о RBAC можно найти в документации Kubernetes и Kubernetes API Access Hardening.
2. Следите за логами
Другой способ предотвратить взлом кластеров — убедиться, что вы отслеживаете логи и регулярно проводите их аудит на предмет подозрительных действий, таких как необычные или нежелательные API-вызовы, особенно сбои аутентификации. Хотя ведение журнала аудита помогает анализировать и выявлять тенденции с течением времени, как отмечает Амир Каушански, вице-президент по продуктам Armo, оно чаще всего используется организациями для мониторинга производительности кластера Kubernetes и обеспечения безопасности.
Например, если запись в логе отображает статус сообщения типа «Запрещено», которое не было авторизовано администратором кластера, это может означать, что злоумышленник пытается использовать украденные учетные данные. Пользователи Kubernetes могут получить доступ к этим данным в своей консоли и настроить уведомления при сбое авторизации.
Ведение журнала аудита позволяет настраивать ведение журнала событий. Вы можете установить один из четырех уровней ведения журнала API:
None;
Только метаданные;
Request: при этом регистрируются метаданные и запросы, но не ответы;
RequestResponse: регистрирует метаданные, запросы и ответы.
Примечание: Хранение этих логов внутри кластеров представляет угрозу безопасности, поскольку компрометация сектора любого кластера может предоставить хакерам логи, хранящиеся в этом кластере, и поставить под угрозу общую безопасность кластеров. Любые конфиденциальные журналы следует транспортировать за пределы кластера, чтобы снизить риск.
Чтобы включить ведение журнала аудита, вам необходимо использовать флаг --audit-policy-file при запуске kube-apiserver. Файл политики содержит правила, которые определяют, что будет регистрироваться. Вот пример файла шаблона политики:
apiVersion: audit.k8s.io/v1
kind: Policy
# Ignore all requests in RequestReceived stage.
omitStages:
- "RequestReceived"
rules:
# Log pod changes at RequestResponse level
- level: RequestResponse
resources:
- group: ""
resources: ["pods"]3. Регулярно меняйте ключи шифрования
Один из лучших методов обеспечения безопасности для защиты Kubernetes от злоумышленников — регулярная смена ключей шифрования и сертификатов. По умолчанию эти сертификаты выдаются с годичным сроком действия, так что вам не придется часто их продлевать. Однако вы также можете настроить их на более подходящее для вас время.
Kubernetes позволяет автоматически генерировать новый ключ и запрашивать новый сертификат у сервера API по мере истечения срока действия текущего сертификата. Как только новый сертификат станет доступен, он проверит подлинность подключений к API Kubernetes. Этот процесс экономит время, поскольку пользователю не нужно часто менять ключи и сертификаты.
Важно всегда шифровать свои резервные копии с помощью хорошо зарекомендовавшего себя решения для шифрования резервных копий и по возможности использовать полное шифрование диска.
Регулярная смена ключей шифрования и сертификатов ограничивает ущерб в случае компрометации ключа. К счастью, автоматизированный процесс смены ключей и сертификатов Kubernetes устраняет возможность человеческой ошибки: утечки конфиденциальных ключей.
Если вы хотите узнать, как вращать ключи шифрования etcd в Kubernetes, ознакомьтесь с этой статьей.
4. Обновление версии Kubernetes
Поддержание Kubernetes в актуальном состоянии — отличный способ обезопасить кластеры от атак. Чтобы получить представление о том, насколько безопасна текущая версия, можете найти список уязвимостей Kubernetes в этом списке CVE.
Тем разработчикам, которые используют хостинг-провайдер, такой как AWS EKS, нужно проверить, автоматически ли ваш провайдер обновляет версию Kubernetes.
5. Процессы внесения заявок в белый список
Белый список процессов помогает идентифицировать процессы, которые запускаются неожиданно.
Первый шаг к использованию белого списка процессов для защиты Kubernetes — наблюдение и идентификация каждого процесса, который выполняется, когда приложение ведет себя нормально. Затем используйте этот список в качестве белого списка для проверки на наличие любых аномалий в будущем поведении приложения.
Если хакеру удается получить доступ к кластеру и запустить вредоносные процессы, белый список помогает быстро выявлять и отмечать такие нарушения.
6. Запускайте контейнеры от имени пользователя, не являющегося root
Запуск контейнеров от имени пользователя root приводит к нарушениям безопасности. Как пишет технический обозреватель Ракель Кампузано Годой на Bitnami, «любой, кто получает доступ к вашему контейнеру, работающему от имени root, может запустить в нем нежелательные процессы — такие как внедрение вредоносных кодов». Запуск контейнеров docker от имени пользователя root также делает ваши приложения уязвимыми, поскольку позволяет пользователям изменять идентификатор пользователя или группы при запуске контейнера.
Перенастройка ваших контейнеров с root на non-root обеспечивает дополнительный уровень защиты, который защищает вас от хакеров. Подборка non-root контейнеров изображений с пометкой «non-root» доступна здесь, в репозитории Bitnami на GitHub.
Чтобы запустить контейнер от имени пользователя non-root, вам необходимо установить поле securitycontext, чтобы точно указать, какие разрешения должен иметь контейнер. В этом контексте вам необходимо настроить securitycontext.RunAsUser и SecurityContext.runAsGroup для запуска контейнеров от имени пользователя, не являющегося root.
Вот как настроить контекст безопасности для модуля или контейнера.
7. Аудит использования kubectl
Интеграция Kubernetes со сторонним поставщиком аутентификации, таким как Teleport, является еще одним эффективным способом защиты ваших кластеров от субъектов угроз. Он предоставляет дополнительные функции безопасности, такие как многофакторная аутентификация, и гарантирует отсутствие изменений на сервере kube-api при добавлении или удалении пользователей.
Teleport предлагает прокси-сервер доступа на основе идентификации для нескольких кластеров Kubernetes. Сертификаты пользователей выдаются после проверки их личности поставщиками единого входа (SSO), такими как Okta, GitHub, Google Apps и другими. Teleport Kubernetes Access предлагает простой унифицированный способ доступа ко всем средам через единую точку доступа, используя одного и того же поставщика удостоверений. Это обеспечивает одинаковые правила доступа на основе ролей (RBAC) для всех ваших кластеров и ресурсов Kubernetes, обеспечивая безопасный доступ к ним.
Teleport предоставляет компаниям передовые методы обеспечения безопасности. Используйте его, чтобы:
Защитите свои кластеры Kubernetes, соблюдая требования соответствия;
Безопасный доступ к базовой инфраструктуре Linux;
Предотвратите атаки honeypot и устраните проблему доверия при первом использовании;
Разрешить пользователям перечислять все серверы и другие текущие онлайн-ресурсы;
Улучшите прозрачность доступа и поведения в вашей инфраструктуре;
Полное воспроизведение
kubectl execs;Сократите операционные издержки, связанные с внедрением передовых методов обеспечения безопасности.
Вывод
Хотя многие команды DevOps включают меры безопасности по умолчанию, которые поставляются с Kubernetes, этих мер недостаточно для защиты кластеров от атак.
На курсе «Kubernetes: Мега» мы рассказываем о том, как отладить механизмы обеспечения стабильности и безопасности, отказоустойчивости приложений и масштабирования.
Бдительные команды DevOps должны делать больше для создания защиты, необходимой для предотвращения проникновения хакеров в системы.
