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

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

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

Пространства имен для изоляции ресурсов Kubernetes

Пространства имен позволяют разделить наборы ресурсов в одном кластере.

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

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

Задать пространство имен можно следующей командой:

kubectl run nginx --image=nginx --namespace=<insert namespace>

kubectl — это утилита командной строки в Kubernetes. В этой команде мы используем образ nginx с флагом --namespace для установки пространства имен. Добавив пространство имен, мы обращаемся к pod’ам в нем следующей командой:

kubectl get pods --namespace=<insert namespace>

Если мы хотим указать пространство имен сразу для нескольких последующих команд, мы выполняем следующую команду:

kubectl config set-context --current --namespace=<insert namespace>

Пространство имен обеспечивает логическое разделение и изоляцию ресурсов.

Защита компонентов Kubernetes

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

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

Указывая минимум и максимум для контейнера, мы оставляем запас для дефолтных операций и обеспечиваем нормальное функционирование для всей среды. По умолчанию все объекты в кластере Kubernetes создаются с неограниченными ресурсами ЦП и памяти. После создания пространства имен Kubernetes можно назначить политики с квотами, чтобы ограничить потребление ресурсов.

Ниже мы создаем пространство имен, чтобы ограничить память, ЦП и pod’ы.

apiVersion: v1
metadata: compute-resources
spec:
pods: “6”
request.cpu: “1”
request.memory: 1Gi
limits.cpu: “4”
limits.memory: 4Gi

Мы назвали этот фрагмент кода “com-resources.yaml”. Теперь развернем его в пространстве имен следующей командой:

kubectl create -f ./<resource-name> –<namespace-name>

Ограничение доступа к ресурсам Kubernetes

Чтобы ограничить доступ к ресурсам Kubernetes, организация должна заблокировать SSH и рекомендовать пользователям использовать kubectl exec, чтобы получать доступ к контейнеру, не получая доступ к хосту. В Kubernetes есть плагины авторизации, где можно детально настроить правила контроля доступа пользователей к ресурсам.

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

Сервисы должны общаться друг с другом через TLS, чтобы весь трафик был зашифрован, и злоумышленник не мог украсть информацию. Это важный шаг, потому что иногда мы считаем, что кластер и так достаточно защищен и можно не тратить ресурсы на шифрование. Шифрование также осуществляется через Kubernetes API.

Мы знаем, какое важное место в Kubernetes занимает Kubernetes API, так что для защиты API можно использовать аутентификацию. В Kubernetes есть несколько встроенных методов аутентификации (статичный файл токена, токен аккаунта сервиса и т. д.), но они не подходят для продакшена. Приходится использовать внешние методы аутентификации, например OpenID Connect (OIDC), поставщики удостоверений, имперсонацию в Kubernetes и т. д.

Кроме того, для API требуется авторизация с использованием управления доступом на основе ролей (RBAC). Как следует из названия, RBAC предоставляет пользователям доступ к ресурсам в зависимости от роли. Когда в Kubernetes поступает запрос, он сопоставляется с пользователем или группой. Если у них достаточно разрешений, запрос будет обработан. Если нет — отклонен. Авторизация RBAC использует группу API rbac.authorization.k8s.io, чтобы динамически настраивать политики через Kubernetes API.

Команда для этой задачи:

kube-apiserver --authorization-mode=Example,RBAC --more-options --other-options

Нужно перезапустить сервер API с флагом authorization-mode и указать список для RBAC через --more-options.

Непрерывные обновления для системы безопасности

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

При этом не стоит устанавливать обновление прямо в продакшене, потому что оно может быть несовместимо с уже используемыми пакетами ПО. Сначала нужно все как следует протестировать в стейджинге и только потом выкатывать в продакшен. Для обновления мы используем команду: apt- update.

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

Применение контекста безопасности к разным ресурсам Kubernetes, таким как pod’ы и контейнеры

Мы можем определить в файле deployment.yaml контекст безопасности, например разрешения, чтобы запретить несанкционированный доступ к pod’ам, контейнерам и томам.

Например, мы можем указать SecurityContext->runAsNonRoot, чтобы контейнер мог выполняться, только если у пользователя нет прав root. Можно настроить и другие параметры безопасности.

Пример кода для pod’а:

apiVersion: v1
metadata:
name: test
spec:
securityContext:
runAsNonRoot : True
readOnlyRootFilesystem : True

Заключение

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