Ukranian - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

Kubernetes Role-Based Access Control(RBAC)

Support HackTricks

Role-Based Access Control (RBAC)

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

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

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

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

  3. RoleBinding\ClusterRoleBinding – Зв'язок між Role\ClusterRole та об'єктом.

Різниця між “Roles” та “ClusterRoles” полягає лише в тому, де буде застосовано роль – “Role” надасть доступ лише до одного конкретного простору імен, тоді як “ClusterRole” може використовуватися в усіх просторах імен в кластері. Більше того, ClusterRoles також можуть надавати доступ до:

  • ресурсів, що охоплюють кластер (як-от вузли).

  • не-ресурсних кінцевих точок (як-от /healthz).

  • ресурсів, що належать до простору імен (як-от Pods), по всіх просторах імен.

З 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 іноді перевіряє авторизацію для додаткових дозволів, використовуючи спеціалізовані дії. Наприклад:

  • PodSecurityPolicy

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

  • RBAC

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

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

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

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

Приклади

Role
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 надає дозволи в межах конкретного простору імен, тоді як 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

Зловживання Role/ClusterRoles для ескалації привілеїв

Abusing Roles/ClusterRoles in Kubernetes
Підтримайте HackTricks
PreviousKubernetes EnumerationNextAbusing Roles/ClusterRoles in Kubernetes

Last updated