Авторизація

Авторизація в Kubernetes відбувається після автентифікації. Зазвичай клієнт, що робить запит, має бути автентифікований (увійти в систему), перш ніж його запит може бути дозволений; однак, Kubernetes також дозволяє анонімні запити за деяких обставин.

Для огляду того, як авторизація вписується в ширший контекст контролю доступу до API, читайте Контроль доступу до Kubernetes API.

Вердикти авторизації

Авторизація запитів до API в Kubernetes відбувається всередині API-сервера. API-сервер оцінює всі атрибути запиту щодо всіх політик, потенційно також звертаючись до зовнішніх сервісів, і потім дозволяє або відхиляє запит.

Усі частини запиту до API повинні бути дозволені деяким механізмом авторизації, щоб він міг продовжити виконання. Іншими словами: стандартно доступ заборонений.

Коли налаштовано кілька модулів авторизації, кожен перевіряється по черзі. Якщо будь-який авторизатор схвалює або відхиляє запит, це рішення негайно повертається і жоден інший авторизатор не перевіряється. Якщо всі модулі не мають думки щодо запиту, то запит відхиляється. Загальний вердикт "відхилено" означає, що API-сервер відхиляє запит і відповідає зі статусом HTTP 403 (Forbidden).

Атрибути запиту, що використовуються для авторизації

Kubernetes розглядає тільки наступні атрибути запиту до API:

• user — Рядок user, наданий під час автентифікації.
• group — Список імен груп, до яких належить автентифікований користувач.
• extra — Map довільних рядкових ключів з рядковими значеннями, надана шаром автентифікації.
• API — Вказує, чи є запит запитом на ресурс API.
• Request path — Шлях до різних нересурсних точок доступу, таких як /api або /healthz.
• API request verb — Дієслова API, такі як get, list, create, update, patch, watch, delete і deletecollection, використовуються для запитів до ресурсів. Щоб визначити дієслово запиту для точки доступу API ресурсу, дивіться дієслова запитів та авторизація.
• HTTP request verb — Методи HTTP в нижньому регістрі, такі як get, post, put і delete, використовуються для нересурсних запитів.
• Resource — Ідентифікатор або імʼя ресурсу, до якого здійснюється доступ (тільки для запитів до ресурсів). Для запитів до ресурсів, що використовують дієслова get, update, patch і delete, ви повинні надати імʼя ресурсу.
• Subresource — Субесурс, до якого здійснюється доступ (тільки для запитів до ресурсів).
• Namespace — Простір імен обʼєкта, до якого здійснюється доступ (тільки для запитів до ресурсів у просторі імен).
• API group — Група API, до якої здійснюється доступ (тільки для запитів до ресурсів). Порожній рядок позначає основну групу API.

Дієслова запиту та авторизація

Нересурсні запити

Запити до точок доступу, відмінних від /api/v1/... або /apis/<group>/<version>/..., вважаються нересурсними запитами та використовують метод HTTP як дієслово в нижньому регістрі. Наприклад, виконання запиту GET за допомогою HTTP до точок доступу, таких як /api або /healthz, буде використовувати get як дієслово.

Ресурсні запити

Щоб визначити дієслово запиту для точки доступу API ресурсу, Kubernetes показує використаний HTTP метод і розглядає, чи діє запит на індивідуальний ресурс чи на колекцію ресурсів:

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

• Особливі випадки автентифікації
  • Дієслово impersonate для users, groups, і serviceaccounts в основній групі API, та userextras у групі API authentication.k8s.io.
• Авторизація CertificateSigningRequests
  • Дієслово approve для CertificateSigningRequests, та update для переглядів наявних схвалень
• RBAC
  • Дієслова bind та escalate для ресурсів roles та clusterroles у групі API rbac.authorization.k8s.io.

Контекст авторизації

Kubernetes очікує атрибути, які є загальними для запитів до REST API. Це означає, що авторизація в Kubernetes працює з наявними системами контролю доступу на рівні організації або хмарного провайдера, які можуть обробляти інші API крім Kubernetes API.

Режими авторизації

API-сервер Kubernetes може авторизувати запит, використовуючи один з декількох режимів авторизації:

AlwaysAllow

Цей режим дозволяє всі запити, що несе ризики для безпеки. Використовуйте цей режим авторизації тільки якщо вам не потрібна авторизація для ваших запитів до API (наприклад, для тестування).

AlwaysDeny

Цей режим блокує всі запити. Використовуйте цей режим авторизації тільки для тестування.

ABAC (контроль доступу на основі атрибутів)

Режим ABAC в Kubernetes визначає парадигму управління доступом, згідно з якою права доступу надаються користувачам за допомогою політик, які обʼєднують атрибути разом. Політики можуть використовувати будь-який тип атрибутів (атрибути користувача, атрибути ресурсу, обʼєкта, середовища тощо).

RBAC (контроль доступу на основі ролей)

Kubernetes RBAC — це метод регулювання доступу до компʼютерних або мережевих ресурсів на основі ролей окремих користувачів в організації. У цьому контексті доступ — це можливість окремого користувача виконувати певне завдання, наприклад, переглядати, створювати або змінювати файл. В цьому режимі Kubernetes використовує групу API rbac.authorization.k8s.io для прийняття рішень щодо авторизації, що дозволяє вам динамічно налаштовувати політики дозволів через API Kubernetes.

Node

Спеціальний режим авторизації, який надає дозволи для kubeletʼів на основі запланованих до запуску Podʼів. Щоб дізнатися більше про режим авторизації вузла, див. Авторизація вузла.

Webhook

Kubernetes режим webhook для авторизації робить синхронний HTTP-виклик, блокуючи запит до тих пір, поки віддалений HTTP-сервіс не відповість на нього. Ви можете написати власне програмне забезпечення для обробки виклику або використовувати рішення з екосистеми.

Конфігурація режиму авторизації

Ви можете налаштувати ланцюжок авторизації API сервера Kubernetes, використовуючи або параметри командного рядка, або, як бета-функцію, використовуючи конфігураційний файл.

Ви повинні вибрати один з двох підходів до конфігурації: задати обидва шляхи --authorization-config і налаштувати вебхук авторизації за допомогою аргументів командного рядка --authorization-mode та --authorization-webhook-* не допускається. Якщо ви спробуєте це зробити, API сервер повідомить про помилку під час запуску та одразу завершить роботу.

Конфігурація режиму авторизації через командний рядок

Ви можете використовувати наступні режими:

• --authorization-mode=ABAC (режим контролю доступу на основі атрибутів)
• --authorization-mode=RBAC (режим контролю доступу на основі ролей)
• --authorization-mode=Node (авторизатор вузлів)
• --authorization-mode=Webhook (режим авторизації вебхуком)
• --authorization-mode=AlwaysAllow (завжди дозволяє запити; несе ризики безпеки)
• --authorization-mode=AlwaysDeny (завжди відхиляє запити)

Ви можете вибрати більше одного режиму авторизації; наприклад: --authorization-mode=Node,Webhook

Kubernetes перевіряє модулі авторизації на основі порядку, який ви вказуєте в командному рядку API сервера, тому раніше зазначений модуль має вищий пріоритет для дозволу або відмови в запиті.

Ви не можете поєднувати аргумент командного рядка --authorization-mode з аргументом командного рядка --authorization-config, який використовується для налаштування авторизації за допомогою локального файлу.

Для отримання додаткової інформації про аргументи командного рядка для API сервера, читайте довідник по kube-apiserver.

Підхід з використанням конфігураційного файлу навіть дозволяє вам вказувати правила CEL для попередньої фільтрації запитів перед їх відправленням до вебхуків, допомагаючи вам уникнути непотрібних викликів. API сервер також автоматично перезавантажує ланцюжок авторизатора при зміні конфігураційного файлу.

Ви вказуєте шлях до конфігурації авторизації за допомогою аргументу командного рядка --authorization-config.

Якщо ви хочете використовувати параметри командного рядка замість конфігураційного файлу, це також є дійсним і підтримуваним підходом. Деякі можливості авторизації (наприклад: кілька вебхуків, політика відмови вебхука та правила попередньої фільтрації) доступні тільки при використанні конфігураційного файлу авторизації.

Приклад конфігурації

---
#
# НЕ ВИКОРИСТОВУЙТЕ КОНФІГУРАЦІЮ ТАК, ЯК ВОНА Є. ЦЕ ПРИКЛАД.
#
apiVersion: apiserver.config.k8s.io/v1beta1
kind: AuthorizationConfiguration
authorizers:
  * type: Webhook
    # Назва, що використовується для опису авторизатора
    # Це явно використовується в механізмі моніторингу для метрик
    # Примітка:
    #   - Перевірка цього поля схожа на перевірку міток K8s на сьогодні.
    # Обовʼязково, немає стандартного значення
    name: webhook
    webhook:
      # Тривалість кешування відповідей 'authorized' від вебхука
      # авторизатора.
      # Те саме, що і встановлення прапорця `--authorization-webhook-cache-authorized-ttl`.
      # Стандартно: 5m0s
      authorizedTTL: 30s
      # Тривалість кешування відповідей 'unauthorized' від вебхука
      # авторизатора.
      # Те саме, що і встановлення прапорця `--authorization-webhook-cache-unauthorized-ttl`.
      # Стандартно: 30 с
      unauthorizedTTL: 30s
      # Тайм-аут для запиту вебхука
      # Максимально допустимий: 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.user.groups)"
  * type: Node
    name: node
  * type: RBAC
    name: rbac
  * type: Webhook
    name: in-cluster-authorizer
    webhook:
      authorizedTTL: 5 хв
      unauthorizedTTL: 30 с
      timeout: 3 с
      subjectAccessReviewVersion: v1
      failurePolicy: NoOpinion
      connectionInfo:
        type: InClusterConfig

Під час налаштування ланцюжка авторизації за допомогою файлу конфігурації переконайтеся, що всі вузли панелі управління мають однаковий вміст файлу. Зверніть увагу на конфігурацію API сервера при оновленні / зниженні версії вашого кластера. Наприклад, якщо ви оновлюєтеся з Kubernetes 1.30 до Kubernetes 1.31, вам потрібно переконатися, що файл конфігурації має формат, який розуміє Kubernetes 1.31, перш ніж ви оновите кластер. Якщо ви знижуєте версію до 1.30, вам потрібно відповідно налаштувати конфігурацію.

Конфігурація авторизації та перезавантаження

Kubernetes перезавантажує файл конфігурації авторизації, коли API сервер виявляє зміну у файлі, а також за 60-секундним графіком, якщо події змін не спостерігаються.

Підвищення привілеїв через створення або редагування робочих навантажень

Користувачі, які можуть створювати/редагувати Podʼи в просторі імен, або безпосередньо, або через обʼєкт, що дозволяє опосередковане управління робочими навантаженнями, можуть мати можливість підвищити свої привілеї в цьому просторі імен. Потенційні шляхи до підвищення привілеїв включають розширення API Kubernetes та повʼязані з ними контролери.

Шляхи підвищення привілеїв

Існують різні способи, за якими зловмисник або ненадійний користувач може отримати додаткові привілеї в межах простору імен, якщо ви дозволяєте їм запускати довільні Podʼи в цьому просторі імен:

• Монтування довільних Secretʼів в цьому просторі імен
  • Може бути використано для доступу до конфіденційної інформації, призначеної для інших робочих навантажень
  • Може бути використано для отримання токена службового облікового запису більш привілейованого ServiceAccount
• Використання довільних службових облікових записів в цьому просторі імен
  • Може виконувати дії Kubernetes API як інше робоче навантаження (імперсонізація)
  • Може виконувати будь-які привілейовані дії, які має цей ServiceAccount
• Монтування або використання ConfigMaps, призначених для інших робочих навантажень в цьому просторі імен
  • Може бути використано для отримання інформації, призначеної для інших робочих навантажень, таких як імена хостів баз даних.
• Монтування томів, призначених для інших робочих навантажень в цьому просторі імен
  • Може бути використано для отримання інформації, призначеної для інших робочих навантажень, та її зміни.

Перевірка доступу до API

kubectl надає підкоманду auth can-i для швидкого запиту до рівня авторизації API. Команда використовує API SelfSubjectAccessReview, щоб визначити, чи може поточний користувач виконати вказану дію, і працює незалежно від режиму авторизації, який використовується.

kubectl auth can-i create deployments --namespace dev

Вивід подібний до цього:

yes

kubectl auth can-i create deployments --namespace prod

Вивід подібний до цього:

no

Адміністратори можуть поєднувати це з імперсонізацією користувача, щоб визначити, які дії можуть виконувати інші користувачі.

kubectl auth can-i list secrets --namespace dev --as dave

Вивід подібний до цього:

no

Так само, щоб перевірити, чи може ServiceAccount з іменем dev-sa в просторі імен dev отримати списки Podʼів в просторі імен target:

kubectl auth can-i list pods \
    --namespace target \
    --as system:serviceaccount:dev:dev-sa

Вивід подібний до цього:

no

SelfSubjectAccessReview є частиною групи API authorization.k8s.io, яка викладає авторизацію сервера API для зовнішніх служб. Інші ресурси у цій групі включають:

SubjectAccessReview

Перегляд доступу для будь-якого користувача, не лише поточного. Корисно для делегування рішень про авторизацію серверу API. Наприклад, kubelet та API розширень сервери використовують це для визначення доступу користувача до своїх власних API.

LocalSubjectAccessReview

Подібно до SubjectAccessReview, але обмежено для конкретного простору імен.

SelfSubjectRulesReview

Перегляд, який повертає набір дій, які користувач може виконати в межах простору імен. Корисно для користувачів для швидкого узагальнення їх власного доступу, або для інтерфейсів користувача для приховування/відображення дій.

Ці API можна опитати, створивши звичайні ресурси Kubernetes, де поле відповіді status поверненого обʼєкта є результатом запиту. Наприклад:

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

Що далі

• Щоб дізнатися більше про автентифікацію, перегляньте Автентифікацію.
• Для отримання огляду, перегляньте Керування доступом до API Kubernetes.
• Щоб дізнатися більше про контроль прийняття, перегляньте Використання контролерів допуску.
• Дізнайтесь про Загальну мову запитів (CEL) в Kubernetes.