Безопасный k8s: Допуск безопасности пода (PSA)

от автора

Автор статьи: Рустем Галиев

IBM Senior DevOps Engineer & Integration Architect. Официальный DevOps ментор и коуч в IBM

Привет Хабр! Поговорим о безопасности в k8s, и начнем с безопасности подов, как базового строительного блока нашего кластера.

Немного основ

Старые версии Kubernetes поставлялись с функцией Pod Security Policies (PSP). Политики безопасности Pod — это концепция, которая помогает обеспечить соблюдение стандартов безопасности для объектов Pod. Kubernetes 1.21 устарел от политик безопасности Pod и представил заменяющую функциональность Pod Security Admission (PSA). PSA определяет, каким стандартам безопасности Pod (PSS) следует следовать. PSS определяет ряд политик безопасности, от строго ограничивающих до строго разрешающих.

Однако в релизе Kubernetes 1.25 политики безопасности подов полностью удалены. Сейчас мы сосредоточимся только на допуске к безопасности пода. PSA включен по умолчанию в Kubernetes 1.23, однако нам нужно будет указать, какие поды должны соответствовать стандартам безопасности. Все, что вам нужно сделать, чтобы включить функцию PSA, — это добавить метку определенного формата в пространство имен. Все поды в этом пространстве имен должны будут следовать заявленным стандартам.

Метка состоит из трех частей: префикса, мода и уровня. Префикс всегда использует заданное значение pod-security.kubernetes.io, за которым следует / (слэш). Мод определяет обработку нарушения. Наконец, уровень диктует степень стандарта безопасности, которого следует придерживаться. Пример такого лейбла может выглядеть так:

metadata:   labels:     pod-security.kubernetes.io/enforce: restricted

Мод может в свою очередь принимать три значения:

  • enforce: Нарушения приведут к отклонению запуска пода,

  • audit: Создание пода будет разрешено. Нарушения будут добавлены в лог аудита,

  • warn: Создание пода будет разрешено. Нарушения будут отображаться на консоли.

Также у нас есть политики безопасности, определяемые уровнем, установленным для PSA:

  • privileged: Полностью неограниченная политика,

  • baseline: Минимально ограничительная политика, которая охватывает важные стандарты,

  • restricted: Жестко ограниченная политика в соответствии с рекомендациями по усилению защиты подов с точки зрения безопасности.

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

Restricted

Давайте применим PSA к поду в пространстве имен psa. Здесь показано определение пространства имен и объявление соответствующей метки. Метка обеспечит соответствие PSS самым высоким стандартам безопасности.

apiVersion: v1 kind: Namespace metadata:   name: psa-restricted   labels: pod-security.kubernetes.io/enforce: restricted

И создадим под, который нарушает наши установленные ограничения

apiVersion: v1 kind: Pod metadata:   name: busybox   namespace: psa-restricted spec:   containers:   - image: busybox:1.35.0 name: busybox command: ["sh", "-c", "sleep 1h"]

Нарушения будут отображены в консоли после запуска команды создания пода в пространстве имен. Как вы можете видеть из следующего, Pod не может быть создан:

Нам нужно настроить параметры контекста безопасности Pod, чтобы они соответствовали очень строгим стандартам. Здесь показано примерное определение пода, которое не нарушает стандарт безопасности пода.

apiVersion: v1 kind: Pod metadata:   name: busybox   namespace: psa-restricted spec:   containers:   - image: busybox:1.35.0     name: busybox     command: ["sh", "-c", "sleep 1h"]     securityContext:         allowPrivilegeEscalation: false         capabilities:             drop: ["ALL"]          runAsNonRoot: true          runAsUser: 2000          runAsGroup: 3000          seccompProfile:      type: RuntimeDefault

Создание объекта Pod теперь работает должным образом.

Далее мы создадим правило Pod Security Admission (PSA). В пространстве имен, которое называется Audited, мы создадим Pod Security Standard (PSS) с базовым уровнем, который должен отображаться на консоли.

Указываем пространство имен с именем audited в файле psa-namespace.yaml. Мы устанавливаем метку PSA с baseline и режимом warn:

apiVersion: v1 kind: Namespace metadata:   name: audited   labels:     pod-security.kubernetes.io/warn: baseline

Мы можем создать ошибку, используя следующую конфигурацию Pod в файле psa-pod.yaml. Манифест YAML устанавливает атрибут hostNetwork: true, что не разрешено для базового уровня:

apiVersion: v1 kind: Pod metadata:   name: busybox   namespace: audited spec:   hostNetwork: true   containers:   - name: busybox        image: busybox:1.28        command: ["sh", "-c", "sleep 1h"]

При создании пода появляется предупреждающее сообщение:

Тем не менее, Pod будет создан. Мы можем предотвратить создание Pod, настроив PSA с уровнем restricted:

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

К сожалению, PSA применяется только к подам с заранее определенным набором политик. Вы не можете писать свои собственные правила, изменять обмен сообщениями, а также изменять объект Pod, если он не соответствует PSS.

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


ссылка на оригинал статьи https://habr.com/ru/companies/otus/articles/741326/


Комментарии

Добавить комментарий

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