概述
本文主要介绍一下 Kubernetes 的 RBAC 体系。
RBAC介绍
在 Kubernetes 中，授权有:
- ABAC（基于属性的访问控制）
- RBAC（基于角色的访问控制）
- Webhook、Node
- AlwaysDeny（一直拒绝）
- AlwaysAllow（一直允许）
从1.6版本起，Kubernetes 默认启用RBAC访问控制策略。从1.8开始，RBAC 已作为稳定的功能。通过设置 –authorization-mode=RBAC 启用 RBAC。在 RBAC API 中，通过如下的步骤进行授权:
- 定义角色: 在定义角色时会指定此角色对于资源的访问控制的规则
- 绑定角色: 将主体与角色进行绑定，对用户进行访问授权
角色和集群角色
在 RBAC API 中，角色包含代表权限集合的规则。在这里，权限只有被授予，而没有被拒绝的设置。在 Kubernetes 中有两类角色，即普通角色和集群角色。可以通过 Role 定义在一个命名空间中的角色，或者可以使用 ClusterRole 定义集群范围的角色。一个角色只能被用来授予访问单一命令空间中的资源。
下面是在 default 命令空间中定义了一个名为 pod-reader 的角色，此角色能够对在 default 命名空间中访问 Pod:
1
2
3
4
5
6
7
8
9
|
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）
- 集群中所有命名空间的资源（类似Pod）
下面是授予集群角色读取秘密字典文件访问权限的例子:
1
2
3
4
5
6
7
8
9
|
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"]
|
角色绑定和集群角色绑定
角色绑定用于将角色与一个或一组用户进行绑定，从而实现将对用户进行授权的目的
主体分为用户、组和服务帐户
角色绑定也分为角色普通角色绑定和集群角色绑定
角色绑定只能引用同一个命名空间下的角色
在下面的例子中，在”default”命名空间中角色绑定将‘jane’用户和“pod-reader”角色进行了绑定，这就授予了“jane”能够访问“default”命名空间下的Pod。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
# This role binding allows "jane" to read pods in the "default" namespace.
# 注意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”用户也仅仅只能读取“development”命名空间中的secrets资源：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
# 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 # 某一个role，可以引用
apiGroup:rbac.authorization.k8s.io
|
集群角色可以被用来在集群层面和整个命名空间进行授权。下面的示例允许在“manager”组的用户能够访问所有命名空间中的保密字典资源。
1
2
3
4
5
6
7
8
9
10
11
12
13
|
# 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 # 类型是 Group，组别
name:manager
apiGroup:rbac.authorization.k8s.io
roleRef:
kind:ClusterRole
name:secret-reader
apiGroup:rbac.authorization.k8s.io
|
资源
在Kubernetes中，主要的资源包括: Pods, Nodes, Services、Deployment、ReplicaSets, StatefulSets, Namespace, Persistent, Secrets 和 ConfigMaps 等。
另外，有些资源下面存在子资源，例如 Pod 下就存在 log 子资源:
1
|
GET /api/v1/namespaces/{namespace}/pods/{name}/log
|
下面的例子显示，“pod-and-pod-logs-reader”角色能够对“pods”和“pods/log”进行访问：
对子资源的访问类似父子集的关系。
1
2
3
4
5
6
7
8
9
|
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"]
|
也可以通过 ResourceNames 指定特定的资源实例，以限制角色只能够对实例进行访问控制:
1
2
3
4
5
6
7
8
9
10
|
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”用户：
1
2
3
4
|
subjects:
- kind: User # 用户
name: "alice@example.com"
apiGroup: rbac.authorization.k8s.io
|
名称为“frontend-admins”的组：
1
2
3
4
|
subjects:
- kind:Group # 组
name:"frontend-admins"
apiGroup:rbac.authorization.k8s.io
|
在kube-system命名空间中，名称为“default”的服务帐户：
1
2
3
4
|
subjects:
- kind:ServiceAccount # 服务账户
name:default
namespace:kube-system # 在什么namespace下
|
在“qa”命名空间中，所有的服务帐户：
1
2
3
4
|
subjects:
- kind:Group # 组
name:system:serviceaccounts:qa # 可以写成一起
apiGroup:rbac.authorization.k8s.io
|
所有的服务帐户：
1
2
3
4
|
subjects:
- kind:Group 组
name:system:serviceaccounts
apiGroup:rbac.authorization.k8s.io
|
所有被认证的用户 (version 1.5+):
1
2
3
|
- kind:Group
name:system:authenticated # 特征？
apiGroup:rbac.authorization.k8s.io
|
所有未被认证的用户 (version 1.5+):
1
2
3
4
|
subjects:
- kind:Group
name:system:unauthenticated
apiGroup:rbac.authorization.k8s.io
|
所有用户(version 1.5+):
1
2
3
4
5
6
7
|
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
在指定的命名空间namespace中进行角色绑定：
1）在“acme”命名空间中，将“admin”集群角色授予“bob”用户：
1
|
$ kubectl create rolebinding bob-admin-binding # 有意义的名字 --clusterrole=admin --user=bob --namespace=acme
|
2）在“acme”命名空间中，将“admin”集群角色授予“acme:myapp”服务帐户：
1
|
$ kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme
|
3 服务帐户权限
默认情况下，RBAC策略授予控制板组件、Node和控制器作用域的权限，但是未授予“kube-system”命名空间外服务帐户的访问权限。这就允许管理员按照需要将特定角色授予服务帐户。
从最安全到最不安全的顺序，方法如下：
1）授予角色给一个指定应用的服务帐户(最佳实践)
这要求在Pod规格中指定serviveAccountName，同时此服务帐户已被创建(通过API、kubectl create serviceaccount等)。例如，在“my-namespace”命名空间内，授予”my-sa”服务帐户“view”集群角色：
1
2
3
4
|
kubectl create rolebinding my-sa-view \
--clusterrole=view \
--serviceaccount=my-namespace:my-sa \
--namespace=my-namespace
|
2）在一个命名空间授予“view”集群角色给“default”服务帐户
1
|
view(cluster role) --> default(service account)
|
如果应用没有指定serviceAccountName，它将使用”default”服务帐户。例如，例如，在“my-namespace”命名空间内，授予”default”服务帐户“view”集群角色：
1
2
3
4
|
kubectl create rolebinding default-view \
--clusterrole=view \
--serviceaccount=my-namespace:default \ # 默认的
--namespace=my-namespace
|
当前，在”kube-system“命名空间中，很多插件作为”default“服务帐户进行运行。为了允许超级用户访问这些插件，在“kube-system”命名空间中授予”cluster-admin“角色给”default”帐户。
1
2
3
|
$ kubectl create clusterrolebinding add-on-cluster-admin \
--clusterrole=cluster-admin \ # cluster admin 是集群管理员？
--serviceaccount=kube-system:default
|
这样default账户就可以访问cluster的控制了。
3）在一个命名空间namespace中，授予角色role给所有的服务帐户serviceaccount：
如果希望在一个命名空间namespace中的所有应用都拥有一个角色role，而不管它们所使用的服务帐户serviceaccount，可以授予角色role给服务帐户组group。例如，在“my-namespace”命名空间中，将”view“集群角色授予“system:serviceaccounts:my-namespace“组：
1
2
3
4
|
$ kubectl create rolebinding serviceaccounts-view \
--clusterrole=view \
--group=system:serviceaccounts:my-namespace \
--namespace=my-namespace
|
4）在整个集群中授予一个角色role给所有的服务帐户serviceaacount(不推荐)
如果不想按照每个命名空间管理权限，可以在整个集群的访问进行授权。例如，在整个集群层面，将”view“集群角色授予“sytem:serviceaccounts“：
1
2
3
|
kubectl create clusterrolebinding serviceaccounts-view \
--clusterrole=view \
--group=system:serviceaccounts # 组别
|
5）在整个集群中授予超级用户访问所有的服务帐户 (强烈不推荐)
如果对访问权限不太重视，可以授予超级用户访问所有的服务帐户。
1
2
3
|
kubectl create clusterrolebinding serviceaccounts-cluster-admin \
--clusterrole=cluster-admin \
--group=system:serviceaccounts
|
宽松的RBAC权限
关于权限的麻烦问题的大杀招…下面的策略允许所有的服务帐户作为集群管理员。在容器中运行的应用将自动的收取到服务帐户证书，并执行所有的 API 行为。包括查看保密字典恩将和修改权限，这是不被推荐的访问策略。
1
2
3
4
5
|
kubectl create clusterrolebinding permissive-binding \
--clusterrole=cluster-admin \
--user=admin \ # 用户
--user=kubelet \ # 用户
--group=system:serviceaccounts # 所有？
|
命令自取:
1
|
kubectl create clusterrolebinding permissive-binding --clusterrole=cluster-admin --user=admin --user=kubelet --group=system:serviceaccounts
|
警告
本文最后更新于 2017年2月1日，文中内容可能已过时，请谨慎参考。
