Перейти на PRO

Какие основные механизмы в Kubernetes используются для управления доступом и изоляции ресурсов?

Тип вопроса: DevOps Вероятность: 10% Категория: Golang Разработчик

Ответ

В Kubernetes для управления доступом и изоляции используются несколько ключевых абстракций, работающих на разных уровнях:

  1. Namespaces (Пространства имен)

    • Что это: Логическое разделение кластера на изолированные виртуальные среды (например, dev, staging, prod).
    • Зачем: Предоставляют область видимости для имен ресурсов (поды, сервисы не могут иметь одинаковые имена в одном namespace) и являются основой для применения политик, таких как RBAC и ResourceQuotas.

  2. RBAC (Role-Based Access Control)

    • Что это: Механизм для гранулярной настройки прав доступа пользователей и сервисов к API Kubernetes.
    • Компоненты:
      • Role и ClusterRole: Определяют набор разрешений (verbs: get, list, create) на ресурсы (resources: pods, services). Role действует в рамках одного Namespace, а ClusterRole — на уровне всего кластера.
      • RoleBinding и ClusterRoleBinding: Связывают роли (Role/ClusterRole) с субъектами (subjects: User, Group, ServiceAccount).
    • Пример Role: 
      apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" означает core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

  3. ServiceAccounts (Сервисные аккаунты)

    • Что это: Учетные записи, предназначенные для процессов, работающих внутри подов, чтобы они могли аутентифицироваться в API-сервере Kubernetes.

  4. NetworkPolicies (Сетевые политики)

    • Что это: Правила, управляющие сетевым трафиком между подами на уровне L3/L4. Позволяют реализовать принцип "zero-trust", когда по умолчанию весь трафик запрещен, а разрешается только необходимый.

  5. ResourceQuotas (Квоты на ресурсы)

    • Что это: Ограничения на совокупное потребление ресурсов (CPU, память, хранилище) в рамках одного Namespace.
    • Зачем: Помогают предотвратить проблему "шумного соседа", когда один проект потребляет все ресурсы кластера.

Эти абстракции в совокупности позволяют создавать безопасные, мульти-tenantные среды.

Ответ 18+ 🔞

Давай разберем эту кухню, где готовится наш кластерный борщ. Про безопасность и изоляцию в кубере. Ты знаешь, как у нас в подъезде: если не поставить железную дверь, сосед дядя Вася запросто придёт и сожрёт твой холодец. Так и тут.

Namespaces (Пространства имён) Это типа отдельных квартир в одном доме-кластере. dev, staging, prod — три разные квартиры. В каждой своя обстановка, свои имена подов и сервисов. В prod нельзя назвать под frontend-pidor, а в dev — пожалуйста, хоть govno-service. И самое главное — на каждую квартиру можно повесить свой замок (политики), чтобы из dev не лазили в prod и не выпили весь коньяк.

RBAC (Ролевой доступ, ёпта) Вот это, блядь, система пропусков. Кто что может делать. Не просто "зашёл в кластер", а что именно тебе можно.

  • Role / ClusterRole — это должностная инструкция, написанная кровью. Что можно трогать и как. Role — инструкция для одной квартиры (namespace), ClusterRole — для всего подъезда (кластера). Вот смотри, инструкция "читатель подов":

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"] # МОЖНО: смотреть, листать, глазеть

    Видишь? create или delete — нихуя нельзя. Только глазеть, как они работают.

  • RoleBinding / ClusterRoleBinding — это когда начальник отдела кадров берёт эту инструкцию и пришпиливает её к твоей грудной клетке. Связывает роль с тобой, твоей группой или сервисным аккаунтом. Без этого биндинга твоя роль — просто бумажка, в рот меня чих-пых.

ServiceAccounts (Сервисные аккаунты) А это — спецпропуска для роботов! Не для людей, а для самих подов, чтобы они могли стучаться в API-сервер и говорить: "Э, я свой, пусти, мне надо список сервисов получить". Без своего сервисного аккаута под — как манда без ушей, нихуя не попросит.

NetworkPolicies (Сетевые политики) Вот это, блядь, наш КПП! Представь: по умолчанию в кластере все поды могут друг до друга достучаться. Полный пиздец и бардак. NetworkPolicy говорит: "Слушай сюда, под backend в неймспейсе prod может общаться ТОЛЬКО с подом database на порт 5432. Всё. Остальным — иди нахуй". Реализуем принцип "никому не верь", даже своему соседу по ноде.

ResourceQuotas (Квоты) А это — борьба с жадными соседями. Чтобы какой-нибудь проект в неймспейсе experimental не сожрал всю память и CPU кластера, оставив prod сухим и мёртвым. Выдаётся лимит: "Вот тебе 10 ядер и 64ГБ памяти на всю твою квартиру. Выжми из этого максимум, а как кончится — сиди и жди, пока кто-то умрёт".

Итог, сука Вот когда ты это всё вместе применяешь: разбил на квартиры (namespaces), раздал пропуска (RBAC + ServiceAccounts), поставил КПП между комнатами (NetworkPolicies) и ограничил потребление воды и света (ResourceQuotas) — вот тогда получается не общага, а приличный, безопасный, многоквартирный дом. Где каждый сидит в своей хате и не суёт свой нос, а тем более свои запросы, куда не просят.

© ХакСобесов, 2026
support@hacksobesov.com