Kubernetes: безопасность
RBAC и ServiceAccount, ConfigMap против Secret и почему Secret не шифруется по умолчанию, SecurityContext и Linux capabilities, укрепление кластера.
8 вопросов
JuniorТеорияОчень частоЧто такое RBAC в Kubernetes и как Role и ClusterRole выдают доступ субъектам?
Что такое RBAC в Kubernetes и как Role и ClusterRole выдают доступ субъектам?
RBAC привязывает субъектов — пользователей, группы или ServiceAccount — к разрешённым verb над ресурсами. Role действует в одном namespace, ClusterRole — на кластер, а RoleBinding привязывает роль к субъектам. Ничего не разрешено без привязки.
Типичные ошибки
- ✗Думать, что в RBAC есть правила deny, а не только allow
- ✗Путать namespaced Role с общекластерным ClusterRole
- ✗Верить, что права действуют без RoleBinding
Уточняющие вопросы
- →Как ClusterRole ограничивается одним namespace через RoleBinding?
- →Почему широкий ClusterRoleBinding на cluster-admin так опасен?
JuniorТеорияЧастоВ чём разница между ConfigMap и Secret в Kubernetes?
В чём разница между ConfigMap и Secret в Kubernetes?
Оба хранят key-value конфигурацию, которую Pod читает как env-переменные или файлы; разница в намерении, а не в защите. Secret лишь закодирован в base64, а не зашифрован в etcd, пока не включишь шифрование, и любой с get может его прочитать.
Типичные ошибки
- ✗Верить, что Secret зашифрован просто потому, что это Secret
- ✗Считать base64 защитой, а не кодированием
- ✗Полагать, что доступ get на Secret не раскрывает его plaintext
Уточняющие вопросы
- →Что нужно настроить, чтобы Secret шифровался в покое?
- →Почему класть учётные данные в ConfigMap хуже, чем в Secret?
JuniorТеорияЧастоЧто такое ServiceAccount в Kubernetes и как Pod его использует?
Что такое ServiceAccount в Kubernetes и как Pod его использует?
ServiceAccount — это внутрикластерная идентичность для нагрузок, а не для людей. Каждый Pod работает под ним — под SA default, если иной не задан, — и его токен монтируется для обращения к API server. Что ему дозволено, решает RBAC.
Типичные ошибки
- ✗Думать, что ServiceAccount — для людей, а не для нагрузок
- ✗Не понимать, что Pod получает SA default, если иной не задан
- ✗Верить, что сам SA даёт права без привязок RBAC
Уточняющие вопросы
- →Где в Pod по умолчанию монтируется токен ServiceAccount?
- →Почему запускать все нагрузки под SA default — плохая идея?
MiddleТеорияЧастоКак выдать нагрузке выделенный ServiceAccount и зачем отключать автомонтирование токена?
Как выдать нагрузке выделенный ServiceAccount и зачем отключать автомонтирование токена?
Создайте ServiceAccount под каждую нагрузку, укажите его в Pod как serviceAccountName и привяжите только нужные роли RBAC. Ставьте automountServiceAccountToken: false, когда Pod не ходит к API server, чтобы у контейнера не было токена.
Типичные ошибки
- ✗Оставлять все Pod на общем ServiceAccount default
- ✗Монтировать токен API в Pod, которые к API не обращаются
- ✗Давать SA широкие роли вместо только необходимого
Уточняющие вопросы
- →В чём риск примонтированного токена в Pod, открытом в интернет?
- →Чем projected bound token лучше старого secret-токена?
MiddleТеорияЧастоЧто задаёт securityContext у Pod или контейнера и какие настройки укрепляют нагрузку?
Что задаёт securityContext у Pod или контейнера и какие настройки укрепляют нагрузку?
securityContext задаёт профиль безопасности процесса: runAsNonRoot с ненулевым runAsUser, readOnlyRootFilesystem, allowPrivilegeEscalation: false и сброшенные capabilities. Избегайте privileged: true — он даёт контейнеру почти полный доступ к хосту.
Типичные ошибки
- ✗Оставлять контейнеры под root вместо
runAsNonRoot - ✗Путать
allowPrivilegeEscalation: falseсprivileged: true - ✗Думать, что read-only корневая ФС ломает любое приложение
Уточняющие вопросы
- →Что на деле блокирует
allowPrivilegeEscalation: false? - →Почему
privileged: trueфактически сводит на нет остальные поля укрепления?
JuniorТеорияИногдаЧто такое Linux capabilities в контейнере и какие стоит сбрасывать по умолчанию?
Что такое Linux capabilities в контейнере и какие стоит сбрасывать по умолчанию?
Linux capabilities дробят полномочия root на единицы вроде NET_BIND_SERVICE или SYS_ADMIN, чтобы процесс держал лишь часть, а не полный root. Контейнеры стартуют с широким набором, поэтому сбрасывайте ALL и добавляйте лишь нужное приложению — обычно ни одной.
Типичные ошибки
- ✗Думать, что процесс контейнера — либо полный root, либо совсем без прав
- ✗Оставлять набор capabilities по умолчанию вместо сброса ALL
- ✗Полагать, что каждому приложению нужна хоть одна capability
Уточняющие вопросы
- →Какое поле
securityContextсбрасывает и добавляет capabilities? - →Почему
SYS_ADMINсчитают близким к полному root?
SeniorДизайнИногдаУ вас один кластер на четыре продуктовые команды. Каждая владеет двумя namespace (staging и prod) и должна полностью самообслуживаться внутри них — деплой, масштабирование, чтение логов, — но никогда не касаться чужих namespace, cluster-scoped объектов вроде nodes и CRD или чужих Secret. Небольшой платформенной команде нужен общекластерный admin, а пайплайнам CI (непрерывная интеграция) — узкие права деплоя на namespace. Спроектируйте модель RBAC (управление доступом на основе ролей): как применять Role против ClusterRole, RoleBinding против ClusterRoleBinding, ServiceAccount для CI и как держать всё по минимуму прав и поддерживаемым по мере роста команд. Объясните, почему широкий ClusterRoleBinding на cluster-admin — неверный инструмент и как избегать wildcard-verb и ресурсов.
У вас один кластер на четыре продуктовые команды. Каждая владеет двумя namespace (staging и prod) и должна полностью самообслуживаться внутри них — деплой, масштабирование, чтение логов, — но никогда не касаться чужих namespace, cluster-scoped объектов вроде nodes и CRD или чужих Secret. Небольшой платформенной команде нужен общекластерный admin, а пайплайнам CI (непрерывная интеграция) — узкие права деплоя на namespace. Спроектируйте модель RBAC (управление доступом на основе ролей): как применять Role против ClusterRole, RoleBinding против ClusterRoleBinding, ServiceAccount для CI и как держать всё по минимуму прав и поддерживаемым по мере роста команд. Объясните, почему широкий ClusterRoleBinding на cluster-admin — неверный инструмент и как избегать wildcard-verb и ресурсов.
Напишите одну переиспользуемую ClusterRole из namespaced-verb и привяжите её на каждый namespace через RoleBinding к группе команды, так что доступ действует лишь внутри этого namespace. Дайте CI Role только на деплой со своим ServiceAccount, а cluster-admin оставьте платформе.
Типичные ошибки
- ✗Давать командам ClusterRoleBinding, охватывающий сразу все namespace
- ✗Брать wildcard-verb или ресурсы вместо перечня нужного
- ✗Делить один ServiceAccount CI с широкими правами на все namespace
Уточняющие вопросы
- →Как провести аудит слишком широких привязок по кластеру?
- →Что не даёт namespaced RoleBinding раскрыть cluster-scoped объекты?
SeniorДизайнИногдаРевью безопасности отмечает, что Secret в вашем кластере хранятся в эквиваленте открытого текста, а часть зашита в образы контейнеров и env-переменные Pod. Требования: учётные данные должны шифроваться в покое, не появляться в образах и в выводе kubectl describe, ротироваться без пересборки образов, а доступ — быть аудируемым и по минимуму прав. Спроектируйте посадку секретов в кластере — как включить шифрование в покое, стоит ли и как интегрировать внешний менеджер секретов, как нагрузки безопасно потребляют секреты и как ограничить, кто их читает. Объясните, почему «это Secret, значит зашифровано» неверно, и компромиссы внешнего хранилища против нативных Secret.
Ревью безопасности отмечает, что Secret в вашем кластере хранятся в эквиваленте открытого текста, а часть зашита в образы контейнеров и env-переменные Pod. Требования: учётные данные должны шифроваться в покое, не появляться в образах и в выводе kubectl describe, ротироваться без пересборки образов, а доступ — быть аудируемым и по минимуму прав. Спроектируйте посадку секретов в кластере — как включить шифрование в покое, стоит ли и как интегрировать внешний менеджер секретов, как нагрузки безопасно потребляют секреты и как ограничить, кто их читает. Объясните, почему «это Secret, значит зашифровано» неверно, и компромиссы внешнего хранилища против нативных Secret.
Включите шифрование etcd в покое через EncryptionConfiguration, лучше через KMS, ведь Secret лишь закодирован в base64. Держите учётные данные вне образов и env, беря их из внешнего менеджера через CSI-драйвер для ротации без пересборки. Ограничьте чтение узким RBAC.
Типичные ошибки
- ✗Считать Secret зашифрованным в покое без EncryptionConfiguration
- ✗Зашивать учётные данные в образы или env-переменные Pod
- ✗Давать широкий
getна Secret вместо чтения по минимуму прав
Уточняющие вопросы
- →В чём компромиссы внешнего хранилища против нативных зашифрованных Secret?
- →Чем провайдер KMS (сервис управления ключами) отличается от aescbc по умолчанию?
