Kubernetes Role-Based Access Control(RBAC)
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Kubernetes має модуль авторизації під назвою Role-Based Access Control (RBAC), який допомагає встановити дозволи на використання для API сервера.
Модель дозволів RBAC складається з трьох окремих частин:
Subject (Користувач, Група або ServiceAccount) – Об'єкт, який отримає дозволи.
RoleBinding\ClusterRoleBinding – Зв'язок між Role\ClusterRole та об'єктом.
Різниця між “Roles” та “ClusterRoles” полягає лише в тому, де буде застосовано роль – “Role” надасть доступ лише до одного конкретного простору імен, тоді як “ClusterRole” може використовуватися в усіх просторах імен в кластері. Більше того, ClusterRoles також можуть надавати доступ до:
ресурсів, що охоплюють кластер (як-от вузли).
не-ресурсних кінцевих точок (як-от /healthz).
ресурсів, що належать до простору імен (як-от Pods), по всіх просторах імен.
З Kubernetes 1.6 і далі, політики RBAC є увімкненими за замовчуванням. Але щоб увімкнути RBAC, ви можете використовувати щось на кшталт:
У шаблоні Ролі або КластерноїРолі вам потрібно вказати ім'я ролі, простір імен (в ролях), а також apiGroups, ресурси та дії ролі:
apiGroups - це масив, який містить різні API простори імен, до яких застосовується це правило. Наприклад, визначення Pod використовує apiVersion: v1. Він може мати значення такі як rbac.authorization.k8s.io або [*].
ресурси - це масив, який визначає до яких ресурсів застосовується це правило. Ви можете знайти всі ресурси за допомогою: kubectl api-resources --namespaced=true
дії - це масив, який містить дозволені дії. Дія в Kubernetes визначає тип дії, яку потрібно застосувати до ресурсу. Наприклад, дія списку використовується для колекцій, тоді як "get" використовується для окремого ресурсу.
(Ця інформація була взята з документації)
POST
створити
GET, HEAD
отримати (для окремих ресурсів), список (для колекцій, включаючи повний вміст об'єкта), спостерігати (для спостереження за окремим ресурсом або колекцією ресурсів)
PUT
оновити
PATCH
патч
DELETE
видалити (для окремих ресурсів), видалити колекцію (для колекцій)
Kubernetes іноді перевіряє авторизацію для додаткових дозволів, використовуючи спеціалізовані дії. Наприклад:
дія use
на ресурсах podsecuritypolicies
в групі API policy
.
дії 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
Наприклад, ви можете використовувати ClusterRole, щоб дозволити певному користувачу виконувати:
З документів: Прив'язка ролі надає дозволи, визначені в ролі, користувачу або набору користувачів. Вона містить список суб'єктів (користувачів, груп або облікових записів служб), а також посилання на роль, що надається. RoleBinding надає дозволи в межах конкретного простору імен, тоді як ClusterRoleBinding надає цей доступ по всьому кластеру.
Дозволи є адитивними, тому якщо у вас є clusterRole з “list” та “delete” секретами, ви можете додати його до Role з “get”. Тож будьте обережні та завжди тестуйте свої ролі та дозволи і вказуйте, що ДОЗВОЛЕНО, оскільки все за замовчуванням ЗАБОРОНЕНО.
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)