Kubernetes Role-Based Access Control(RBAC)

Reading time: 6 minutes

Role-Based Access Control (RBAC)

Kubernetes має модуль авторизації, названий Role-Based Access Control (RBAC), який допомагає встановити дозволи на використання для API сервера.

Модель дозволів RBAC складається з трьох окремих частин:

1. Role\ClusterRole ­– Фактичний дозвіл. Він містить правила, які представляють набір дозволів. Кожне правило містить ресурси та дії. Дія – це дія, яка буде застосована до ресурсу.
2. Subject (Користувач, Група або ServiceAccount) – Об'єкт, який отримає дозволи.
3. RoleBinding\ClusterRoleBinding – Зв'язок між Role\ClusterRole та об'єктом.

Різниця між “Roles” та “ClusterRoles” полягає лише в тому, де буде застосовано роль – “Role” надасть доступ лише до одного конкретного простору імен, тоді як “ClusterRole” може використовуватися в усіх просторах імен в кластері. Більше того, ClusterRoles також можуть надавати доступ до:

• ресурсів, що охоплюють кластер (як-от вузли).
• не-ресурсних кінцевих точок (як-от /healthz).
• ресурсів, що належать до простору імен (як-от Pods), по всіх просторах імен.

З Kubernetes 1.6 і далі, RBAC політики увімкнені за замовчуванням. Але для увімкнення RBAC ви можете використовувати щось на кшталт:

kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options

Шаблони

У шаблоні Ролі або ClusterRole вам потрібно вказати ім'я ролі, простір імен (в ролях), а також apiGroups, ресурси та дії ролі:

• apiGroups - це масив, який містить різні API простори імен, до яких застосовується це правило. Наприклад, визначення Pod використовує apiVersion: v1. Він може мати значення такі як rbac.authorization.k8s.io або [*].
• ресурси - це масив, який визначає, до яких ресурсів застосовується це правило. Ви можете знайти всі ресурси за допомогою: kubectl api-resources --namespaced=true
• дії - це масив, який містить дозволені дії. Дія в Kubernetes визначає тип дії, яку потрібно застосувати до ресурсу. Наприклад, дія списку використовується для колекцій, тоді як "get" використовується для окремого ресурсу.

Дії Правил

(Ця інформація була взята з документації)

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

• PodSecurityPolicy
• дія use на ресурсах podsecuritypolicies в групі API policy.
• RBAC
• дії bind та escalate на ресурсах roles та clusterroles в групі API rbac.authorization.k8s.io.
• Аутентифікація
• дія impersonate на users, groups та serviceaccounts в основній групі API, а також userextras в групі API authentication.k8s.io.

Приклади

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: defaultGreen
name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list", "watch"]

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
# "namespace" omitted since ClusterRoles are not namespaced
name: secret-reader
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "watch", "list"]

Наприклад, ви можете використовувати ClusterRole, щоб дозволити певному користувачу виконувати:

kubectl get pods --all-namespaces

RoleBinding та ClusterRoleBinding

З документації: Прив'язка ролі надає дозволи, визначені в ролі, користувачу або набору користувачів. Вона містить список суб'єктів (користувачів, груп або облікових записів служб), а також посилання на роль, що надається. RoleBinding надає дозволи в межах конкретного простору імен, тоді як ClusterRoleBinding надає цей доступ по всьому кластеру.

piVersion: rbac.authorization.k8s.io/v1
# This role binding allows "jane" to read pods in the "default" namespace.
# You need to already have a Role named "pod-reader" in that namespace.
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
# You can specify more than one "subject"
- kind: User
name: jane # "name" is case sensitive
apiGroup: rbac.authorization.k8s.io
roleRef:
# "roleRef" specifies the binding to a Role / ClusterRole
kind: Role #this must be Role or ClusterRole
name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
apiGroup: rbac.authorization.k8s.io

apiVersion: rbac.authorization.k8s.io/v1
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind: ClusterRoleBinding
metadata:
name: read-secrets-global
subjects:
- kind: Group
name: manager # Name is case sensitive
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.io

Дозволи є адитивними, тому якщо у вас є clusterRole з “list” та “delete” секретами, ви можете додати його до Role з “get”. Тож будьте обережні та завжди тестуйте свої ролі та дозволи і вказуйте, що ДОЗВОЛЕНО, оскільки все за замовчуванням ЗАБОРОНЕНО.

Перерахування RBAC

# Get current privileges
kubectl auth can-i --list
# use `--as=system:serviceaccount:<namespace>:<sa_name>` to impersonate a service account

# List Cluster Roles
kubectl get clusterroles
kubectl describe clusterroles

# List Cluster Roles Bindings
kubectl get clusterrolebindings
kubectl describe clusterrolebindings

# List Roles
kubectl get roles
kubectl describe roles

# List Roles Bindings
kubectl get rolebindings
kubectl describe rolebindings

Зловживання Ролями/Кластерними Ролями для Підвищення Привілеїв

Abusing Roles/ClusterRoles in Kubernetes