Керування доступом до API

• 1: Авторизація
• 2: Використання авторизації ABAC
• 3: Автентифікація/авторизація kubelet

1 - Авторизація

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

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

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

Авторизація запитів до 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 — Субресурс, до якого здійснюється доступ (тільки для запитів до ресурсів). Це може бути стандартний субресурс (наприклад, status або scale) або синтетичний субресурс, який використовується для детальної авторизації.
• 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.
• Динамічне виділення ресурсів (DRA)
  • Синтетичні субресурси, такі як resourceclaims/binding та resourceclaims/driver у групі API resource.k8s.io.
  • Дієслова, що враховують вузол, такі як associated-node:update, associated-node:patch, arbitrary-node:update та arbitrary-node:patch, для оновлень resourceclaims/status драйверами DRA.
• Примусове видалення пошкоджених ресурсів
  • Дієслово unsafe-delete-ignore-read-errors для ресурсу, яке перевіряється додатково до дієслова delete.

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

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

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

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

AlwaysAllow

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

AlwaysDeny

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

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

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

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

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

Node

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

Webhook

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

Група system:masters

Група system:masters є вбудованою групою Kubernetes, яка надає необмежений доступ до API-сервера. Будь-який користувач, призначений до цієї групи, має повні привілеї адміністратора кластера, обходячи будь-які обмеження авторизації, що накладаються механізмами RBAC або Webhook. Не додавайте користувачів до цієї групи. Якщо вам потрібно надати користувачеві права cluster-admin, ви можете створити ClusterRoleBinding до вбудованої ClusterRole cluster-admin.

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

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

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

Налаштування API-сервера за допомогою конфігураційного файлу авторизації

Kubernetes дозволяє налаштовувати ланцюжки авторизації, які можуть включати декілька вебхуків. Елементи авторизації в цьому ланцюжку можуть мати чітко визначені параметри, які перевіряють запити в певному порядку, пропонуючи вам тонке налаштування, наприклад, явну відмову (Deny) у разі збоїв.

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

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

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

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

---
#
# НЕ ВИКОРИСТОВУЙТЕ КОНФІГУРАЦІЮ ТАК, ЯК ВОНА Є. ЦЕ ПРИКЛАД.
#
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`
      # Типово: 30s
      unauthorizedTTL: 30s
      # Якщо встановлено в false, відповіді 'unauthorized' від вебхука не кешуються
      # і вказаний unauthorizedTTL ігнорується/не має ефекту.
      # Те саме, що і встановлення прапорця `--authorization-webhook-cache-unauthorized-ttl` в `0`.
      # Примітка: Встановлення unauthorizedTTL в `0` призводить до використання його типового значення.
      # Типово: true
      cacheUnauthorizedRequests: true
      # Тайм-аут для запиту вебхука
      # Максимально допустимий: 30s.
      # Обовʼязково, немає типового значення.
      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.
      # Якщо версія, вказана в subjectAccessReviewVersion, для змінної request є 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Перевірка доступу до 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 в Namespace dev отримати перелік Podʼів у Namespace target:

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

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

yes

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.

2 - Використання авторизації ABAC

Керування доступом на основі атрибутів (ABAC) визначає парадигму керування доступом, за якою права доступу надаються користувачам за допомогою політик, які комбінують атрибути.

Формат файлу політики

Для увімкнення режиму ABAC вказуйте --authorization-policy-file=SOME_FILENAME та --authorization-mode=ABAC під час запуску.

Формат файлу — один обʼєкт JSON на рядок. Не повинно бути зовнішнього списку чи map, лише один map на рядок.

Кожний рядок — "обʼєкт політики", де такий обʼєкт є map із такими властивостями:

• Властивості версіювання:
  • apiVersion, типу string; допустимі значення "abac.authorization.kubernetes.io/v1beta1". Дозволяє версіювання та конвертацію формату політики.
  • kind, типу string: допустимі значення "Policy". Дозволяє версіювання та конвертацію формату політики.
• Властивість spec встановлена на map з такими властивостями:
  • Властивості зіставлення субʼєкта:
    • user, типу string; рядок користувача з --token-auth-file. Якщо ви вказуєте user, він повинен збігатися з імʼям користувача автентифікованого користувача.
    • group, типу string; якщо ви вказуєте group, вона повинна збігатися з однією з груп автентифікованого користувача. system:authenticated збігається з усіма автентифікованими запитами. system:unauthenticated збігається з усіма неавтентифікованими запитами.
  • Властивості зіставлення ресурсу:
    • apiGroup, типу string; група API.
      • Наприклад: apps, networking.k8s.io
      • Маска: * збігається з усіма групами API.
    • namespace, типу string; простір імен.
      • Наприклад: kube-system
      • Маска: * збігається з усіма запитами ресурсів.
    • resource, типу string; тип ресурсу
      • Наприклад: pods, deployments
      • Маска: * збігається з усіма запитами ресурсів.
  • Властивості зіставлення нересурсів:
    • nonResourcePath, типу string; шляхи запитів нересурсів.
      • Наприклад: /version або /apis
      • Маска:
        • * збігається з усіма запитами нересурсів.
        • /foo/* збігається з усіма підшляхами /foo/.
  • readonly, типу boolean, якщо true, означає, що політика, що зіставляється з ресурсом, застосовується тільки до операцій get, list, та watch, а політика, що зіставляється з нересурсами, застосовується тільки до операції get.

Алгоритм авторизації

У запиту є атрибути, які відповідають властивостям обʼєкта політики.

Коли отримано запит, визначаються атрибути. Невідомі атрибути встановлюються на нульове значення свого типу (наприклад, порожній рядок, 0, false).

Властивість, встановлена на "*", буде збігатися з будь-яким значенням відповідного атрибута.

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

Щоб дозволити будь-якому автентифікованому користувачеві зробити щось, створіть політику з властивістю group, встановленою на "system:authenticated".

Щоб дозволити будь-якому неавтентифікованому користувачеві зробити щось, створіть політику з властивістю group, встановленою на "system:unauthenticated".

Щоб дозволити користувачеві зробити все, створіть політику з властивостями apiGroup, namespace, resource та nonResourcePath, встановленими на "*".

Kubectl

Kubectl використовує точки доступу /api та /apis apiserver, щоб виявити типи ресурсів, які обслуговуються, і перевіряє обʼєкти, надіслані до API за допомогою операцій create/update, використовуючи інформацію про схему, розташовану в /openapi/v2.

Під час використання авторизації ABAC ці спеціальні ресурси мають бути явно відкриті за допомогою властивості nonResourcePath в політиці (див. приклади нижче):

• /api, /api/*, /apis та /apis/* для вибору версії API.
• /version для отримання версії сервера через kubectl version.
• /swaggerapi/* для операцій create/update.

Щоб перевірити HTTP-виклики, повʼязані з певною операцією kubectl, ви можете збільшити рівень деталізації:

kubectl --v=8 version

Приклади

1. Alice може робити все з усіма ресурсами:

   {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "alice", "namespace": "*", "resource": "*", "apiGroup": "*"}}
   

2. kubelet може читати будь-які Podʼи:

   {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "kubelet", "namespace": "*", "resource": "pods", "readonly": true}}
   

3. kubelet може читати та записувати події:

   {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "kubelet", "namespace": "*", "resource": "events"}}
   

4. Bob може лише читати Podʼи в просторі імен "projectCaribou":

   {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "bob", "namespace": "projectCaribou", "resource": "pods", "readonly": true}}
   

5. Будь-хто може робити запити тільки для читання на всі нересурсні шляхи:

   {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group": "system:authenticated", "readonly": true, "nonResourcePath": "*"}}
    {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group": "system:unauthenticated", "readonly": true, "nonResourcePath": "*"}}
   

Приклад повного файлу

Коротка нотатка про службові облікові записи

Кожен службовий обліковий запис має відповідне імʼя користувача ABAC, і імʼя користувача цього службового облікового запису генерується згідно з такою конвенцією найменування:

system:serviceaccount:<namespace>:<serviceaccountname>

Створення нового простору імен призводить до створення нового службового облікового запису в такому форматі:

system:serviceaccount:<namespace>:default

Наприклад, якщо ви хочете надати типовому (default) службовому обліковому запису (у просторі імен kube-system) повні привілеї в API за допомогою ABAC, додайте цей рядок до файлу політики:

{"apiVersion":"abac.authorization.kubernetes.io/v1beta1","kind":"Policy","spec":{"user":"system:serviceaccount:kube-system:default","namespace":"*","resource":"*","apiGroup":"*"}}

apiserver потрібно перезапустити, щоб він підхопив нові рядки політики.

3 - Автентифікація/авторизація kubelet

Огляд

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

У цьому документі описано, як автентифікувати та авторизувати доступ до HTTPS-точки доступу kubelet.

Автентифікація kubelet

Типово запити до HTTPS-точки доступу kubelet, які не відхилені іншими налаштованими методами автентифікації, розглядаються як анонімні запити та отримують імʼя користувача system:anonymous та групу system:unauthenticated.

Щоб вимкнути анонімний доступ та надсилати відповіді 401 Unauthorized на неавтентифіковані запити:

• запустіть kubelet з прапорцем --anonymous-auth=false

Щоб увімкнути автентифікацію за допомогою клієнтських сертифікатів X509 до HTTPS-точки доступу kubelet:

• запустіть kubelet з прапорцем --client-ca-file, передавши набір сертифікатів CA для перевірки клієнтських сертифікатів
• запустіть apiserver з прапорцями --kubelet-client-certificate та --kubelet-client-key
• див. документацію з автентифікації apiserver для отримання додаткових відомостей

Щоб увімкнути використання API-токенів на предʼявника (включаючи токени службових облікових записів) для автентифікації до HTTPS-точки доступу kubelet:

• переконайтеся, що група API authentication.k8s.io/v1 ввімкнена в API-сервері
• запустіть kubelet з прапорцями --authentication-token-webhook та --kubeconfig
• kubelet викликає API TokenReview на налаштованому API-сервері, щоб визначити інформацію про користувача з токенів на предʼявника

Авторизація kubelet

Будь-який запит, який успішно автентифікується (включаючи анонімний запит), потім авторизується. Типовий режим авторизації — AlwaysAllow, який дозволяє всі запити.

Є багато можливих причин розмежувати доступ до API kubelet:

• ввімкнено анонімну автентифікацію, але потрібно обмежити можливості анонімних користувачів викликати API kubelet
• ввімкнено автентифікацію з використанням токенів на предʼявника, але потрібно обмежити можливості довільних користувачів API (наприклад, службових облікових записів) викликати API kubelet
• ввімкнено автентифікацію за допомогою клієнтських сертифікатів, але дозволено використовувати API kubelet тільки деяким сертифікатам клієнтів, які підписані налаштованим кореневим сертифікатом

Щоб розмежувати доступ до API kubelet, делегуйте авторизацію API-серверу:

• переконайтеся, що група API authorization.k8s.io/v1 ввімкнена в API-сервері
• запустіть kubelet з прапорцями --authorization-mode=Webhook та --kubeconfig
• kubelet викликає API SubjectAccessReview на налаштованому API-сервері, щоб визначити, чи авторизований кожний запит

kubelet авторизує запити до API, використовуючи той самий підхід до атрибутів запиту, що й apiserver.

Дієслово визначається з HTTP-дії вхідного запиту:

Ресурс та субресурс визначаються з шляху вхідного запиту:

Атрибути простору імен та групи API завжди є порожніми рядками, а імʼя ресурсу завжди є імʼям обʼєкта API Node цього kubelet.

Під час використання цього режиму переконайтеся, що користувач, визначений прапорцями --kubelet-client-certificate та --kubelet-client-key, переданими до apiserver, авторизований для таких атрибутів:

• verb=*, resource=nodes, subresource=proxy
• verb=*, resource=nodes, subresource=stats
• verb=*, resource=nodes, subresource=log
• verb=*, resource=nodes, subresource=spec
• verb=*, resource=nodes, subresource=metrics

Детальна авторизація

kubelet виконує детальну перевірку перед поверненням до субресурсу proxy для точок доступу /pods, /runningPods, /configz та /healthz. Ресурс і субресурс визначаються за шляхом вхідного запиту:

Коли функціональну можливість KubeletFineGrainedAuthz увімкнено, переконайтеся, що користувач, ідентифікований прапорцями --kubelet-client-certificate та --kubelet-client-key, переданими API-серверу, авторизований для таких атрибутів:

• verb=*, resource=nodes, subresource=proxy
• verb=*, resource=nodes, subresource=stats
• verb=*, resource=nodes, subresource=log
• verb=*, resource=nodes, subresource=metrics
• verb=*, resource=nodes, subresource=configz
• verb=*, resource=nodes, subresource=healthz
• verb=*, resource=nodes, subresource=pods

Якщо використовується авторизація RBAC, увімкнення цієї функціональної можливості також гарантує, що вбудована system:kubelet-api-admin ClusterRole буде оновлена з дозволами на доступ до всіх вищезгаданих субресурсів.