Всем привет, продолжаем анонсы наших наработок.

Сегодня хотим поделиться с вами - RBAC-Engine 😱

Какую задачу мы решали. 😈

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

Даже на простом примере:

  •  pods/exec   | verb=get,create
  •  nodes/proxy | verb=get,create

Попробуйте сходу понять 💬:
• Какие роли это разрешают
• Какие service accounts / пользователи с ними связаны
• Через какие биндинги это всё выдается

Отдельная боль — политики уровня "*", которые размывают реальную картину доступа.

Чтобы это разобрать, мы пошли двумя путями: 😎

1. Политики (аналог Trivy-подхода)
Сделали свой механизм правил который позволяет:
• Описывать интересующий скоуп
• Применять к кластеру или namespace
• Получать результат со скорингом

Это даёт быстрый ответ — где 💩

2. Граф связей (Agregation Layer API)
AGL позволил реализовать in-memory GRAPH DB, в рамках кторой находятся все связи и граф всегда простраивается относительно прав пользователей, так что лишнего не увидят.

AGL предоставляет возможность: ☹️
• Фильтровать по нужному скоупу
• Отображать, кто реально может использовать доступ
• Накладывать результаты политик поверх найденных связей
• Резолвить "*" в Rule на основе реальной схемы OpenAPI кластера

В итоге вы получаете инструмент с помощью которого:
• Быстро находите роли с нужным доступом
• Понимаете, кто пользуется найденными ролями
• Понимаете, через какой биндинг выдан этот доступ

Такой подход позволяет убрать десятки, а может сотни человекочасов работы и получить ту прозрачность которую мы заслужили)

Полезная информация:
• Исходники на GitHub
• Chart на GitHub

Лучшая ваша похвала — это: 🤪
• Вопросы по теме
• Поиск неточностей
• Советы, как сделать лучше
• И, конечно, ⭐️ на GitHub

Что бы добавить немного контекста, то политика описывается вот таким простым способом
-> 😎

apiVersion: rbacreports.in-cloud.io/v1alpha1
kind: RbacPolicy
metadata:
  name: ksv053-exec-into-pods
spec:
  severity: HIGH
  category: Kubernetes Security Check
  checkID: KSV053
  title: Exec into Pods
  description: >-
    Access to the pods/exec subresource lets a caller run arbitrary commands
    inside any container they can target. Combined with a privileged container,
    a hostPath mount, or a high-permission ServiceAccount, this is a direct path
    to host root or cluster-admin.
  remediation: >-
    Limit pods/exec to a small set of trusted operator identities (or remove
    entirely in production). For routine debugging, prefer ephemeral containers
    or read-only log access.
  match:
    apiGroups: [""]
    resources: [pods/exec]
    verbs:
      - create
      - get
      - "*"

На выходе мы получаем вот такой репорт для каждой роли
-> 😎

apiVersion: rbacreports.in-cloud.io/v1alpha1
kind: ClusterRbacReport
metadata:
  labels:
    app.kubernetes.io/managed-by: rbac-reports-operator
    rbac-reports.io/resource-kind: ClusterRole
  name: admin
  ownerReferences:
  - apiVersion: rbac.authorization.k8s.io/v1
    blockOwnerDeletion: false
    controller: true
    kind: ClusterRole
    name: admin
    uid: 09b10026-db84-4725-aa30-9d6d22623451
report:
  checks:
  - category: Kubernetes Security Check
    checkID: KSV053
    description: Access to the pods/exec subresource lets a caller run arbitrary commands
      inside any container they can target. Combined with a privileged container,
      a hostPath mount, or a high-permission ServiceAccount, this is a direct path
      to host root or cluster-admin.
    messages:
    - ClusterRole 'admin' should not have access to resources [pods/attach, pods/exec,
      pods/portforward, pods/proxy, secrets, services/proxy] for verbs [get, list,
      watch]
    - ClusterRole 'admin' should not have access to resources [pods, pods/attach,
      pods/exec, pods/portforward, pods/proxy] for verbs [create, delete, deletecollection,
      patch, update]
    remediation: Limit pods/exec to a small set of trusted operator identities (or
      remove entirely in production). For routine debugging, prefer ephemeral containers
      or read-only log access.
    severity: HIGH
    success: false
    title: Exec into Pods
  summary:
    criticalCount: 5
    highCount: 2
    lowCount: 0
    mediumCount: 2
    totalCount: 9
spec:
  roleRef:
    kind: ClusterRole
    name: admin
    uid: 09b10026-db84-4725-aa30-9d6d22623451
  scanner:
    name: rbac-reports-operator
    vendor: PRO-Robotech
    version: 0.3.0

А для получения скоупа через граф, достаточно сформировать вот такой манифест:
-> 🤪

{
  "apiVersion": "rbacgraph.in-cloud.io/v1alpha1",
  "kind": "RoleGraphReview",
  "metadata": {"name": "demo"},
  "spec": {
    "selector": {
      "apiGroups": [""],
      "resources": ["pods/exec"],
      "verbs": ["get", "create"]
    },
    "matchMode": "any",
    "includeRuleMetadata": true
  }
}