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

219a38c38fbf0d52b983b75f03865adb.png

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

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 не может быть создан:

d9d4cfdadc964c303018d22f8d5d27db.png

Нам нужно настроить параметры контекста безопасности 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 теперь работает должным образом.

c12ac5087d7ae49d41a433678f971eab.png

Далее мы создадим правило 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

7fff42155b18e316fff0f25548a596bb.png

Мы можем создать ошибку, используя следующую конфигурацию 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"]

9ce5eac91638844f905341763a694d1e.png

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

5eb00e754125ab44e4d941e0e68242f9.png

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

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

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

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

© Habrahabr.ru