Охайо! Тема сегодняшнего номера - встроенные механизмы безопасности Security Context. Предлагаем разобраться с деталями и разложить все по полочкам как для Kubernetes, так и для Red Hat OpenShift.

Security Context нужны для контроля доступа контейнеров к ресурсам хостов кластера. Они контролируют сразу несколько аспектов: запуск привилегированных контейнеров, доступ к функциям ядра linux хоста, использование директорий хоста и не только (об этом подробнее читайте по ссылкам).

Security Context задаются в спецификации пода (раздел spec yaml-файла) и могут распространяться как на под, так и на конкретный контейнер в поде. Security Context могут задаваться с помощью политик. В этом случае под/контейнер запускается с конкретной политикой, которая автоматически прописывает нужные параметры конфигурации в yaml-файл пода. Сами политики создаются на уровне кластера и назначаются пользователям или сервисным учетным записям, которые могут управлять образами и контейнерами.

А теперь про главные отличия между политиками Kubernetes и Red Hat OpenShift:

📍В Red Hat OpenShift - Security Context Constraints
📍В Kubernetes - Pod Security Policy
📍Политики в обоих оркестраторах практически одинаковые, используются разные apiVersion
📍В Kubernetes отсутствуют преднастроенные политики
📍В Red Hat OpenShift присутствует набор предопределенных политик, больше опций настроек и есть приоритеты

Want to know more?
- Про политики в Kubernetes
- Про политики в Red Hat OpenShift