Ukranian - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Kubernetes Role-Based Access Control(RBAC)

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

Керування доступом на основі ролей (RBAC)

У Kubernetes є модуль авторизації з ім'ям Role-Based Access Control (RBAC), який допомагає встановлювати дозволи використання для сервера API.

Модель дозволів RBAC складається з трьох окремих частин:

  1. Роль\ClusterRole ­– Фактичний дозвіл. Він містить правила, які представляють набір дозволів. Кожне правило містить ресурси та дієслова. Дієслово - це дія, яка буде застосована до ресурсу.

  2. Суб'єкт (Користувач, Група або ServiceAccount) – Об'єкт, який отримає дозволи.

  3. RoleBinding\ClusterRoleBinding – Зв'язок між Роллю\ClusterRole та суб'єктом.

Відмінність між "Ролями" та "ClusterRoles" полягає лише в тому, де буде застосована роль - "Роль" надасть доступ лише до одного конкретного простору імен, тоді як "ClusterRole" може бути використаний у всіх просторах імен в кластері. Більше того, ClusterRoles також можуть надавати доступ до:

  • ресурсів з областю кластера (наприклад, вузли).

  • не-ресурсних кінцевих точок (наприклад, /healthz).

  • ресурсів з областю імен (наприклад, Поди), у всіх просторах імен.

Починаючи з Kubernetes 1.6, політики RBAC включені за замовчуванням. Але для включення RBAC можна використовувати щось на зразок:

kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options

Шаблони

У шаблоні Ролі або Кластерної Ролі вам потрібно вказати ім'я ролі, простір імен (у ролях), а потім apiGroups, ресурси та дії ролі:

  • apiGroups - це масив, який містить різні простори імен API, до яких застосовується це правило. Наприклад, визначення Pod використовує apiVersion: v1. Він може мати значення, такі як rbac.authorization.k8s.io або [*].

  • ресурси - це масив, який визначає, до яких ресурсів застосовується це правило. Ви можете знайти всі ресурси за допомогою: kubectl api-resources --namespaced=true

  • дії - це масив, який містить дозволені дії. Дія в Kubernetes визначає тип дії, яку потрібно застосувати до ресурсу. Наприклад, дія списку використовується проти колекцій, тоді як "get" використовується проти одного ресурсу.

Дії Правил

(Цю інформацію було взято з документації)

HTTP діязапит дії

POST

створення

GET, HEAD

отримати (для окремих ресурсів), список (для колекцій, включаючи повний вміст об'єкта), спостереження (для спостереження окремого ресурсу або колекції ресурсів)

PUT

оновлення

PATCH

патч

DELETE

видалення (для окремих ресурсів), видалення колекції (для колекцій)

Іноді Kubernetes перевіряє авторизацію для додаткових дозволів, використовуючи спеціалізовані дії. Наприклад:

  • Політика Безпеки Подів

  • дія use на ресурси podsecuritypolicies в групі API policy.

  • RBAC

  • дії bind та escalate на ресурси roles та clusterroles в групі API rbac.authorization.k8s.io.

  • Аутентифікація

  • дія impersonate на користувачів, групи та serviceaccounts в основній групі API, та userextras в групі API authentication.k8s.io.

Ви можете знайти всі дії, які підтримує кожен ресурс, виконавши kubectl api-resources --sort-by name -o wide

Приклади

Роль
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: defaultGreen
name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list", "watch"]
ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
# "namespace" omitted since ClusterRoles are not namespaced
name: secret-reader
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "watch", "list"]

Наприклад, ви можете використовувати ClusterRole, щоб дозволити певному користувачеві виконувати:

kubectl get pods --all-namespaces

RoleBinding та ClusterRoleBinding

З документації: RoleBinding надає дозволи, визначені в ролі, користувачеві або групі користувачів. Він містить список суб'єктів (користувачів, груп або облікових записів служби) та посилання на роль, яка надається. RoleBinding надає дозволи в межах конкретного простору імен, тоді як ClusterRoleBinding надає доступ на рівні кластера.

piVersion: rbac.authorization.k8s.io/v1
# This role binding allows "jane" to read pods in the "default" namespace.
# You need to already have a Role named "pod-reader" in that namespace.
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
# You can specify more than one "subject"
- kind: User
name: jane # "name" is case sensitive
apiGroup: rbac.authorization.k8s.io
roleRef:
# "roleRef" specifies the binding to a Role / ClusterRole
kind: Role #this must be Role or ClusterRole
name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
apiGroup: rbac.authorization.k8s.io
ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind: ClusterRoleBinding
metadata:
name: read-secrets-global
subjects:
- kind: Group
name: manager # Name is case sensitive
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.io

Дозволи є додатковими, тому якщо у вас є clusterRole з "list" та "delete" секретами, ви можете додати його з Role з "get". Тому будьте обережні та завжди тестуйте свої ролі та дозволи та вказуйте, що ДОЗВОЛЕНО, оскільки за замовчуванням все ЗАБОРОНЕНО.

Перелік RBAC

# Get current privileges
kubectl auth can-i --list
# use `--as=system:serviceaccount:<namespace>:<sa_name>` to impersonate a service account

# List Cluster Roles
kubectl get clusterroles
kubectl describe clusterroles

# List Cluster Roles Bindings
kubectl get clusterrolebindings
kubectl describe clusterrolebindings

# List Roles
kubectl get roles
kubectl describe roles

# List Roles Bindings
kubectl get rolebindings
kubectl describe rolebindings

Зловживання ролями/ClusterRoles для підвищення привілеїв

pageAbusing Roles/ClusterRoles in Kubernetes
PreviousKubernetes EnumerationNextAbusing Roles/ClusterRoles in Kubernetes

Last updated