Kubernetes — авторизация на основе RBAC

задняя часть Docker Kubernetes

1,RBACпредставлять

В Kubernetes существует 6 режимов авторизации: ABAC (управление доступом на основе атрибутов), RBAC (управление доступом на основе ролей), Webhook, Node, AlwaysDeny (всегда запрещать) и AlwaysAllow (всегда разрешать). Начиная с версии 1.6, Kubernetes по умолчанию включает политику управления доступом RBAC. RBAC доступен как стабильная функция с версии 1.8. Включите RABC, установив --authorization-mode=RBAC. В RABC API авторизация выполняется по следующим шагам: 1) Определение роли: При определении роли будут указаны правила контроля доступа для этой роли к ресурсам 2) Привязка роли: Привязка субъекта к роли, и выполните над пользователем следующие операции: Авторизация доступа.

1.1 Роли и кластерные роли

В API RBAC роли содержат правила, представляющие наборы разрешений. Здесь разрешения только предоставляются, а не запрещаются. В Kubernetes есть два типа ролей: обычные роли и кластерные роли. Роли можно определить в пространстве имен с помощью Role, или роли в масштабе кластера можно определить с помощью ClusterRole. Роль можно использовать только для предоставления доступа к ресурсам в одном командном пространстве. Ниже приведена роль под названием «pod-reader», определенная в пространстве команд «по умолчанию». Эта роль может получать доступ к модулям в пространстве имен «по умолчанию»:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Кластерной роли (ClusterRole) могут быть предоставлены разрешения на следующие ресурсы:

  • Общекластерные ресурсы (аналогично Node)
  • конечная точка без ресурсов (аналогично «/healthz»)
  • Ресурсы для всех пространств имен в кластере (например, Pods)

Ниже приведен пример предоставления роли кластера доступа на чтение к файлу секретного словаря:

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

1.2 Привязка ролей и привязка ролей кластера

Привязка ролей используется для привязки роли к одному или группе пользователей для достижения цели авторизации пользователей. Участники делятся на пользователей, группы и учетные записи служб. Привязка ролей также делится на обычную привязку ролей и привязку кластерной роли. Привязки ролей могут ссылаться только на роли в одном и том же пространстве имен. В приведенном ниже примере привязка роли в пространстве имен «по умолчанию» связывает пользователя «jane» с ролью «pod-reader», которая предоставляет «jane» доступ к модулям в пространстве имен «default».

# This role binding allows "jane" to read pods in the "default" namespace.
kind:RoleBinding
apiVersion:rbac.authorization.k8s.io/v1
metadata:
  name:read-pods
  namespace:default
subjects: #主体
- kind:User
  name:jane
  apiGroup:rbac.authorization.k8s.io
roleRef: #引用的角色
  kind:Role
  name:pod-reader
  apiGroup:rbac.authorization.k8s.io

Привязки ролей также могут предоставлять доступ, ссылаясь на роли кластера.Когда доступ субъекта к ресурсам ограничен этим пространством имен, это позволяет администраторам определить набор общих ролей для всего кластера, который затем можно повторно использовать в нескольких пространствах имен. Например, следующая привязка роли ссылается на роль кластера, но пользователь «dave» может только читать ресурс secrets в пространстве имен «development»:

# This role binding allows "dave" to read secrets in the "development" namespace.
kind:RoleBinding
apiVersion:rbac.authorization.k8s.io/v1
metadata:
  name:read-secrets
  namespace:development# This only grants permissions within the "development" namespace.
subjects:
- kind:User
  name:dave
  apiGroup:rbac.authorization.k8s.io
roleRef:
  kind:ClusterRole
  name:secret-reader
  apiGroup:rbac.authorization.k8s.io

Кластерные роли можно использовать для авторизации как на уровне кластера, так и во всем пространстве имен. В следующем примере пользователи из группы «менеджер» получают доступ к ресурсам секретного словаря во всех пространствах имен.

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

1.3 ресурс

В Kubernetes к основным ресурсам относятся: Pods, Nodes, Services, Deployment, Replicasets, Statefulsets, Namespace, Persistents, Secrets, ConfigMap и т. д. Кроме того, под некоторыми ресурсами есть подресурсы, например подресурсы log под Pod:

GET /api/v1/namespaces/{namespace}/pods/{name}/log

Следующий пример показывает, "pod-and-pod-logs-reader» имеет доступ к «pods» и «pods/log»:

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

Вы также можете указать конкретный экземпляр ресурса через resourceNamess, чтобы ограничить роль только контролем доступа к экземпляру:

kind:Role
apiVersion:rbac.authorization.k8s.io/v1
metadata:
  namespace:default
  name:configmap-updater
rules:
- apiGroups:[""]
  resources:["configmaps"]
  resourceNames:["my-configmap"]
  verbs:["update","get"]

1.4 основной корпус

Участниками авторизации RBAC могут быть группы, пользователи или учетные записи служб. Пользователи представлены строками, такими как «alice», «bob@example.com» и т. д. Конкретная форма зависит от имени пользователя, настроенного администратором в модуле аутентификации. system: зарезервирован для использования системой Kubernetes и поэтому не может использоваться в качестве префикса для пользователей. Группы также предоставляются модулем аутентификации в формате, аналогичном формату пользователей.

Пример привязки тела к роли:

Пользователь с именем "alice@example.com":

subjects:
- kind:User
  name:"alice@example.com"
  apiGroup:rbac.authorization.k8s.io

Группа под названием «frontend-admins»:

subjects:
- kind:Group
  name:"frontend-admins"
  apiGroup:rbac.authorization.k8s.io

В пространстве имен kube-system учетная запись службы с именем «по умолчанию»:

subjects:
- kind:ServiceAccount
  name:default
  namespace:kube-system

В пространстве имен «qa» все сервисные аккаунты:

subjects:
- kind:Group
  name:system:serviceaccounts:qa
  apiGroup:rbac.authorization.k8s.io

Все сервисные аккаунты:

subjects:
- kind:Group
  name:system:serviceaccounts
  apiGroup:rbac.authorization.k8s.io

Все авторизованные пользователи (версия 1.5+):

subjects:
- kind:Group
  name:system:authenticated
  apiGroup:rbac.authorization.k8s.io

Все неаутентифицированные пользователи (версия 1.5+):

subjects:
- kind:Group
  name:system:unauthenticated
  apiGroup:rbac.authorization.k8s.io

Все пользователи (версия 1.5+):

subjects:
- kind:Group
  name:system:authenticated
  apiGroup:rbac.authorization.k8s.io
- kind:Group
  name:system:unauthenticated
  apiGroup:rbac.authorization.k8s.io

2, инструменты командной строки

Kubernetes может выполнять привязку ролей с помощью командных инструментов.

2.1 kubectl create rolebinding

Привязка роли в указанном пространстве имен:

1) В пространстве имен «acme» назначьте кластерную роль «admin» пользователю «bob»:

$ kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme

2) В пространстве имен «acme» назначьте кластерную роль «admin» учетной записи службы «acme:myapp»:

$ kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme

2.2 kubectl create clusterrolebinding

Привязка ролей в кластере:

1) Во всем кластере назначьте роль кластера «cluster-admin» пользователю «root»:

$ kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root

2) Во всем кластере назначьте роль кластера «system:node» пользователю «kubelet»:

$ kubectl create clusterrolebinding kubelet-node-binding --clusterrole=system:node --user=kubelet

3) Во всем кластере предоставьте роль кластера «просмотр» учетной записи службы «acme:myapp»:

$ kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp

3, разрешения сервисного аккаунта

По умолчанию политика RBAC предоставляет разрешения для компонентов панели мониторинга, узлов и контроллеров, но не предоставляет доступ к учетным записям служб за пределами пространства имен «kube-system». Это позволяет администраторам назначать определенные роли сервисным учетным записям по мере необходимости.

Методы от самого безопасного к наименее безопасному следующие:

1) для предоставления ролей учетной записи службы для данного приложения(Лучшие практики)

Для этого необходимо, чтобы имя serviveAccountName было указано в спецификации Pod и чтобы учетная запись службы была создана (через API, kubectl create serviceaccount и т. д.). Например, в пространстве имен «my-namespace» предоставьте служебной учетной записи «my-sa» роль кластера «просмотр»:

kubectl create rolebinding my-sa-view \ 
--clusterrole=view \ 
--serviceaccount=my-namespace:my-sa \ 
--namespace=my-namespace

2) предоставляется в пространстве имен"Посмотреть"Кластерные роли дают"По умолчанию"сервисный аккаунт

Если приложение не указывает serviceAccountName, оно будет использовать учетную запись службы «по умолчанию». Например, в пространстве имен «my-namespace» предоставьте учетной записи службы «по умолчанию» роль кластера «просмотр»:

kubectl create rolebinding default-view \ 
--clusterrole=view \ 
--serviceaccount=my-namespace:default \ 
--namespace=my-namespace

В настоящее время в пространстве имен «kube-system» многие плагины работают как учетная запись службы «по умолчанию». Чтобы разрешить суперпользователю доступ к этим подключаемым модулям, предоставьте роль «cluster-admin» учетной записи «default» в пространстве имен «kube-system».

$ kubectl create clusterrolebinding add-on-cluster-admin \ 
--clusterrole=cluster-admin \ 
--serviceaccount=kube-system:default

3) в пространстве имен предоставьте роли всем учетным записям служб:

Если вы хотите, чтобы все приложения в пространстве имен имели роль, независимо от используемой ими учетной записи службы, вы можете предоставить роли группам учетных записей служб. Например, в пространстве имен «my-namespace» предоставьте роль кластера «view» группе «system:serviceaccounts:my-namespace»:

$ kubectl create rolebinding serviceaccounts-view \ 
--clusterrole=view \ 
--group=system:serviceaccounts:my-namespace \ 
--namespace=my-namespace

4), чтобы предоставить роль всем учетным записям служб в кластере. (Не рекомендуется)

Если вы не хотите управлять разрешениями для каждого пространства имен, вы можете разрешить доступ ко всему кластеру. Например, на уровне всего кластера предоставьте роль кластера «просмотр» для «sytem:serviceaccounts»:

$ kubectl create clusterrolebinding serviceaccounts-view \ 
--clusterrole=view \ 
--group=system:serviceaccounts

5), чтобы предоставить доступ суперпользователя ко всем учетным записям служб в кластере. (настоятельно не рекомендуется)

Если права доступа менее важны, вы можете предоставить доступ суперпользователя ко всем учетным записям служб.

$ kubectl create clusterrolebinding serviceaccounts-cluster-admin \ 
--clusterrole=cluster-admin \ 
--group=system:serviceaccounts

4, свободныйRBACразрешение

Следующая политика позволяет всем учетным записям служб действовать в качестве администраторов кластера. Приложения, работающие в контейнерах, автоматически получают учетные данные служебной учетной записи и выполняют все действия API. Это включает в себя просмотр словаря конфиденциальности и изменение разрешений, которые не являются рекомендуемыми политиками доступа.

$ kubectl create clusterrolebinding permissive-binding \ 
--clusterrole=cluster-admin \ 
--user=admin \ 
--user=kubelet \ 
--group=system:serviceaccounts

использованная литература

1. Адрес «Обзор авторизации»:Это специально.IO/docs/admin/…

2. Адрес «Использование авторизации RBAC»: https://kubernetes.io/docs/reference/access-authn-authz/rbac/

Об авторе:
Цзи Сянъюань, менеджер по продукции компании Beijing Shenzhou Aerospace Software Technology Co., Ltd. Авторские права на эту статью принадлежат оригинальному автору.

Категории