Керування доступом на основі атрибутів (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). Проте невстановлена властивість має перевагу для зручності читання.
У майбутньому політики можна буде виражати у форматі JSON і керувати ними через REST-інтерфейс.
У запиту є атрибути, які відповідають властивостям обʼєкта політики.
Коли отримано запит, визначаються атрибути. Невідомі атрибути встановлюються на нульове значення свого типу (наприклад, порожній рядок, 0, false).
Властивість, встановлена на "*", буде збігатися з будь-яким значенням відповідного атрибута.
Кортеж атрибутів перевіряється на відповідність кожній політиці в файлі політики. Якщо принаймні один рядок відповідає атрибутам запиту, тоді запит авторизований (але може зазнати невдачі під час подальшої перевірки).
Щоб дозволити будь-якому автентифікованому користувачеві зробити щось, створіть політику з властивістю group, встановленою на "system:authenticated".
Щоб дозволити будь-якому неавтентифікованому користувачеві зробити щось, створіть політику з властивістю group, встановленою на "system:unauthenticated".
Щоб дозволити користувачеві зробити все, створіть політику з властивостями apiGroup, namespace, resource та nonResourcePath, встановленими на "*".
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
Alice може робити все з усіма ресурсами:
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "alice", "namespace": "*", "resource": "*", "apiGroup": "*"}}
kubelet може читати будь-які Podʼи:
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "kubelet", "namespace": "*", "resource": "pods", "readonly": true}}
kubelet може читати та записувати події:
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "kubelet", "namespace": "*", "resource": "events"}}
Bob може лише читати Podʼи в просторі імен "projectCaribou":
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "bob", "namespace": "projectCaribou", "resource": "pods", "readonly": true}}
Будь-хто може робити запити тільки для читання на всі нересурсні шляхи:
{"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 потрібно перезапустити, щоб він підхопив нові рядки політики.