/...`, вважаються _нересурсними запитами_ та використовують метод HTTP як дієслово в нижньому регістрі. Наприклад, виконання запиту `GET` за допомогою HTTP до точок доступу, таких як `/api` або `/healthz`, буде використовувати **get** як дієслово.
#### Ресурсні запити {#request-verb-resource}
Щоб визначити дієслово запиту для точки доступу API ресурсу, Kubernetes показує використаний HTTP метод і розглядає, чи діє запит на індивідуальний ресурс чи на колекцію ресурсів:
HTTP метод | дієслово запиту
--------------|---------------
`POST` | **create**
`GET`, `HEAD` | **get** (для індивідуальних ресурсів), **list** (для колекцій, включаючи повний вміст обʼєктів), **watch** (для спостереження за індивідуальним ресурсом або колекцією ресурсів)
`PUT` | **update**
`PATCH` | **patch**
`DELETE` | **delete** (для індивідуальних ресурсів), **deletecollection** (для колекцій)
Увага:
Дієслова get, list та watch можуть повертати повні деталі ресурсу. В плані доступу до повернених даних вони є еквівалентними. Наприклад, list для secrets розкриє атрибути data будь-яких повернених ресурсів.
Іноді Kubernetes перевіряє авторизацію для додаткових дозволів, використовуючи спеціалізовані дієслова. Наприклад:
* Особливі випадки [автентифікації](/docs/reference/access-authn-authz/authentication/)
* Дієслово **impersonate** для `users`, `groups`, і `serviceaccounts` в основній групі API, та `userextras` у групі API `authentication.k8s.io`.
* [Авторизація CertificateSigningRequests](/docs/reference/access-authn-authz/certificate-signing-requests/#authorization)
* Дієслово **approve** для CertificateSigningRequests, та **update** для переглядів наявних схвалень
* [RBAC](/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping)
* Дієслова **bind** та **escalate** для ресурсів `roles` та `clusterroles` у групі API `rbac.authorization.k8s.io`.
* [Динамічне виділення ресурсів (DRA)](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/)
* Синтетичні субресурси, такі як `resourceclaims/binding` та `resourceclaims/driver` у групі API `resource.k8s.io`.
* Дієслова, що враховують вузол, такі як `associated-node:update`, `associated-node:patch`, `arbitrary-node:update` та `arbitrary-node:patch` для оновлень драйвера DRA `resourceclaims/status`.
## Контекст авторизації {#authorization-context}
Kubernetes очікує атрибути, які є загальними для запитів до REST API. Це означає, що авторизація в Kubernetes працює з наявними системами контролю доступу на рівні організації або
хмарного провайдера, які можуть обробляти інші API крім Kubernetes API.
## Режими авторизації {#authorization-modules}
API-сервер Kubernetes може авторизувати запит, використовуючи один з декількох режимів авторизації:
`AlwaysAllow`
: Цей режим дозволяє всі запити, що несе [ризики для безпеки](#warning-always-allow). Використовуйте цей режим авторизації тільки якщо вам не потрібна авторизація для ваших запитів до API (наприклад, для тестування).
`AlwaysDeny`
: Цей режим блокує всі запити. Використовуйте цей режим авторизації тільки для тестування.
`ABAC` ([контроль доступу на основі атрибутів](/docs/reference/access-authn-authz/abac/))
: Режим ABAC в Kubernetes визначає парадигму управління доступом, згідно з якою права доступу надаються користувачам за допомогою політик, які обʼєднують атрибути разом. Політики можуть використовувати будь-який тип атрибутів (атрибути користувача, атрибути ресурсу, обʼєкта, середовища тощо).
`RBAC` ([контроль доступу на основі ролей](/docs/reference/access-authn-authz/rbac/))
: Kubernetes RBAC — це метод регулювання доступу до компʼютерних або мережевих ресурсів на основі ролей окремих користувачів в організації. У цьому контексті доступ — це можливість окремого користувача виконувати певне завдання, наприклад, переглядати, створювати або змінювати файл. В цьому режимі Kubernetes використовує групу API `rbac.authorization.k8s.io` для прийняття рішень щодо авторизації, що дозволяє вам динамічно налаштовувати політики дозволів через API Kubernetes.
`Node`
: Спеціальний режим авторизації, який надає дозволи для kubeletʼів на основі запланованих до запуску Podʼів. Щоб дізнатися більше про режим авторизації вузла, див. [Авторизація вузла](/docs/reference/access-authn-authz/node/).
`Webhook`
: Kubernetes [режим webhook](/docs/reference/access-authn-authz/webhook/) для авторизації робить синхронний HTTP-виклик, блокуючи запит до тих пір, поки віддалений HTTP-сервіс не відповість на нього. Ви можете написати власне програмне забезпечення для обробки виклику або використовувати рішення з екосистеми.
Попередження:
Увімкнення режиму AlwaysAllow обходить авторизацію; не використовуйте це в кластері, де ви не довіряєте всім потенційним клієнтам API, включаючи робочі навантаження, які ви запускаєте.
Механізми авторизації зазвичай повертають результат deny або no opinion; для більш детальної інформації дивіться рішення авторизації. Активування режиму AlwaysAllow означає, що якщо всі інші авторизатори повертають "немає думки", запит дозволяється. Наприклад, --authorization-mode=AlwaysAllow,RBAC має такий самий ефект, як і --authorization-mode=AlwaysAllow, тому що RBAC Kubernetes не надає негативних (відмовних) правил доступу.
Ви не повинні використовувати режим AlwaysAllow на кластері Kubernetes, де API сервер доступний публічно з інтернету.
СТАН ФУНКЦІОНАЛУ:
Kubernetes v1.32 [stable](стандартно увімкнено)
Kubernetes дозволяє налаштовувати ланцюжки авторизації, які можуть включати декілька вебхуків. Елементи авторизації в цьому ланцюжку можуть мати чітко визначені параметри, які перевіряють запити в певному порядку, пропонуючи вам тонке налаштування, наприклад, явну відмову при невдачах.
Підхід з використанням конфігураційного файлу навіть дозволяє вам вказувати [правила CEL](/docs/reference/using-api/cel/) для попередньої фільтрації запитів перед їх відправленням до вебхуків, допомагаючи вам уникнути непотрібних викликів. API сервер також автоматично перезавантажує ланцюжок авторизатора при зміні конфігураційного файлу.
Ви вказуєте шлях до конфігурації авторизації за допомогою аргументу командного рядка `--authorization-config`.
Якщо ви хочете використовувати параметри командного рядка замість конфігураційного файлу, це також є дійсним і підтримуваним підходом. Деякі можливості авторизації (наприклад: кілька вебхуків, політика відмови вебхука та правила попередньої фільтрації) доступні тільки при використанні конфігураційного файлу авторизації.
#### Приклад конфігурації {#authz-config-example}
---
#
# НЕ ВИКОРИСТОВУЙТЕ КОНФІГУРАЦІЮ ТАК, ЯК ВОНА Є. ЦЕ ПРИКЛАД.
#
apiVersion: apiserver.config.k8s.io/v1
kind: AuthorizationConfiguration
authorizers:
- type: Webhook
# Назва, що використовується для опису авторизатора
# Це явно використовується в механізмі моніторингу для метрик
# Примітка:
# - Перевірка цього поля схожа на перевірку міток K8s на сьогодні.
# Обовʼязково, немає типового значення
name: webhook
webhook:
# Тривалість кешування відповідей 'authorized' від вебхука
# авторизатора.
# Те саме, що і встановлення прапорця `--authorization-webhook-cache-authorized-ttl`.
# Типово: 5m0s
authorizedTTL: 30s
# Якщо встановлено в false, 'authorized' відповіді від вебхука не кешуються
# і вказаний authorizedTTL ігнорується/не має ефекту.
# Те саме, що і встановлення прапорця `--authorization-webhook-cache-authorized-ttl` в `0`.
# Примітка: Встановлення authorizedTTL в `0` призводить до використання його типового значення.
# Типове: true
cacheAuthorizedRequests: true
# Тривалість кешування відповідей 'unauthorized' від вебхука
# авторизатора.
# Те саме, що і встановлення прапорця `--authorization-webhook-cache-unauthorized-ttl`.
# Типово: 30 с
unauthorizedTTL: 30s
# Якщо встановлено в false, 'unauthorized' відповіді від вебхука не кешуються
# і вказаний unauthorizedTTL ігнорується/не має ефекту.
# Те саме, що і встановлення прапорця `--authorization-webhook-cache-unauthorized-ttl` в `0`.
# Примітка: Встановлення unauthorizedTTL в `0` призводить до використання його типового значення.
# Типове: true
cacheUnauthorizedRequests: true
# Тайм-аут для запиту вебхука
# Максимально допустимий: 30 с
# Обовʼязково, немає типового значення
timeout: 3s
# Версія API для SubjectAccessReview в authorization.k8s.io, яка
# надсилається до вебхука та очікується від нього.
# Те саме, що і встановлення прапорця `--authorization-webhook-version`.
# Обовʼязково, немає типового значення
# Допустимі значення: v1beta1, v1
subjectAccessReviewVersion: v1
# MatchConditionSubjectAccessReviewVersion визначає версію SubjectAccessReview
# за якою оцінюються вирази CEL
# Допустимі значення: v1
# Обовʼязково, немає типового значення
matchConditionSubjectAccessReviewVersion: v1
# Керує рішенням авторизації, коли запит вебхука не вдалося
# виконати або отримано некоректну відповідь або помилки під час оцінки
# виразів matchConditions.
# Допустимі значення:
# - NoOpinion: продовжувати до наступних авторизаторів, щоб перевірити, чи дозволяє один з них запит
# - Deny: відхиляти запит без консультації з наступними авторизаторами
# Обовʼязково, немає типового значення
failurePolicy: Deny
connectionInfo:
# Керує тим, як вебхук повинен спілкуватися з сервером.
# Допустимі значення:
# - KubeConfigFile: використовуйте файл, вказаний у kubeConfigFile для пошуку сервера.
# - InClusterConfig: використовуйте конфігурацію внутрішнього кластера для виклику API SubjectAccessReview,
# що розміщується kube-apiserver. Цей режим не дозволяється для kube-apiserver.
type: KubeConfigFile
# Шлях до файлу KubeConfigFile для інформації про підключення
# Обовʼязково, якщо connectionInfo.Type є KubeConfigFile
kubeConfigFile: /kube-system-authz-webhook.yaml
# matchConditions - це список умов, які повинні бути виконані для того, щоб запит було відправлено на цей
# вебхук. Порожній список matchConditions підходить для всіх запитів.
# Є максимально допустимі 64 умови відповідності.
#
# Логіка точного порівняння така (в порядку):
# 1. Якщо принаймні одна matchCondition оцінюється як FALSE, тоді вебхук пропускається.
# 2. Якщо ВСІ matchConditions оцінюються як TRUE, тоді вебхук викликається.
# 3. Якщо принаймні одна matchCondition оцінюється як помилка (але ні одна не є FALSE):
# - Якщо failurePolicy=Deny, тоді вебхук відхиляє запит.
# - Якщо failurePolicy=NoOpinion, тоді помилка ігнорується, а вебхук пропускається.
matchConditions:
# expression - це вираз CEL, який оцінюється для кожного запиту. Повертає булеве значення.
# CEL вираз має доступ до вмісту SubjectAccessReview у версії v1.
# Якщо версія у SubjectAccessReview в запиті змінної є v1beta1,
# вміст буде конвертовано у v1 перед оцінкою виразу CEL.
#
# Документація CEL: https://kubernetes.io/docs/reference/using-api/cel/
#
# лише надсилати запити ресурсів до вебхука
- expression: has(request.resourceAttributes)
# лише перехоплювати запити до kube-system
- expression: request.resourceAttributes.namespace == 'kube-system'
# не перехоплювати запити від службових облікових записів kube-system
- expression: "!('system:serviceaccounts:kube-system' in request.groups)"
- type: Node
name: node
- type: RBAC
name: rbac
- type: Webhook
name: in-cluster-authorizer
webhook:
authorizedTTL: 5m
unauthorizedTTL: 30s
timeout: 3s
subjectAccessReviewVersion: v1
failurePolicy: NoOpinion
connectionInfo:
type: InClusterConfig
Примітка:
Ви повинні забезпечити, щоб всі типи авторизаторів, крім вебхука, залишалися незмінними у файлі під час перезавантаження.
Перезавантаження не повинно додавати або видаляти авторизаторів вузла або RBAC (їх можна перевпорядкувати, але не можна додавати або видаляти).
Увага:
Як адміністратор кластера, будьте обережні, надаючи доступ до створення або редагування робочих навантажень. Деякі деталі того, як вони можуть бути використані не за призначенням, задокументовані в
шляхах підвищення привілеїв.
Увага:
Як системному адміністратору, вам слід бути обережними при впровадженні власних визначень ресурсів, що дозволяють користувачам вносити зміни у вищезазначених областях. Це може відкрити шляхи до підвищення привілеїв. Розгляньте наслідки цього виду змін при виборі контролю за авторизацією.
## Перевірка доступу до API {#checking-api-access}
`kubectl` надає підкоманду `auth can-i` для швидкого запиту до рівня авторизації API. Команда використовує API `SelfSubjectAccessReview`, щоб визначити, чи може поточний користувач виконати
вказану дію, і працює незалежно від режиму авторизації, який використовується.
```bash
kubectl auth can-i create deployments --namespace dev
```
Вивід подібний до цього:
```none
yes
```
```shell
kubectl auth can-i create deployments --namespace prod
```
Вивід подібний до цього:
```none
no
```
Адміністратори можуть поєднувати це з [імперсонізацією користувача](/docs/reference/access-authn-authz/authentication/#user-impersonation), щоб визначити, які дії можуть виконувати інші користувачі.
```bash
kubectl auth can-i list secrets --namespace dev --as dave
```
Вивід подібний до цього:
```none
no
```
Так само, щоб перевірити, чи може ServiceAccount з іменем `dev-sa` в просторі імен `dev` отримати списки Podʼів в просторі імен `target`:
```bash
kubectl auth can-i list pods \
--namespace target \
--as system:serviceaccount:dev:dev-sa
```
Вивід подібний до цього:
```none
no
```
SelfSubjectAccessReview є частиною групи API `authorization.k8s.io`, яка викладає авторизацію сервера API для зовнішніх служб. Інші ресурси у цій групі включають:
SubjectAccessReview
: Перегляд доступу для будь-якого користувача, не лише поточного. Корисно для делегування рішень про авторизацію серверу API. Наприклад, `kubelet` та сервери API розширень використовують це для визначення доступу користувача до своїх власних API.
LocalSubjectAccessReview
: Подібно до SubjectAccessReview, але обмежено для конкретного простору імен.
SelfSubjectRulesReview
: Перегляд, який повертає набір дій, які користувач може виконати в межах простору імен. Корисно для користувачів для швидкого узагальнення їх власного доступу, або для інтерфейсів користувача для приховування/відображення дій.
Ці API можна опитати, створивши звичайні ресурси Kubernetes, де поле відповіді `status`
поверненого обʼєкта є результатом запиту. Наприклад:
```bash
kubectl create -f - -o yaml << EOF
apiVersion: authorization.k8s.io/v1
kind: SelfSubjectAccessReview
spec:
resourceAttributes:
group: apps
resource: deployments
verb: create
namespace: dev
EOF
```
Створений SelfSubjectAccessReview схожий на:
apiVersion: authorization.k8s.io/v1
kind: SelfSubjectAccessReview
metadata:
creationTimestamp: null
spec:
resourceAttributes:
group: apps
resource: deployments
namespace: dev
verb: create
status:
allowed: true
denied: false