Kubernetes 基于 RBAC 的授权(十六)
一、RBAC介绍
在Kubernetes中,授权有ABAC(基于属性的访问控制)、RBAC(基于角色的访问控制)、Webhook、Node、AlwaysDeny(一直拒绝)和AlwaysAllow(一直允许)这6种模式。
从1.6版本起,Kubernetes 默认启用RBAC访问控制策略。从1.8开始,RBAC已作为稳定的功能。通过设置
--authorization-mode=RBAC,启用RABC。在RABC API中,通过如下的步骤进行授权:
定义角色:在定义角色时会指定此角色对于资源的访问控制的规则;
绑定角色:将主体与角色进行绑定,对用户进行访问授权。
1.1、角色和集群角色
在 RBAC API 中,角色包含代表权限集合的规则。在这里,权限只有被授予,而没有被拒绝的设置。在 Kubernetes 中有两类角色,即普通角色(Role)和集群角色(ClusterRole)。可以通过
Role定义在一个命名空间中的角色,或者可以使用
ClusterRole定义集群范围的角色。一个
Role只能被用来授予访问单一命令空间中的资源。下面是在 default 命令空间中定义了一个名为 pod-reader 的角色,此角色能够对在 default 命名空间中访问 Pod:
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可用于授予与
Role相同的权限。他们能够被授予如下资源的权限:
- 集群范围的资源(类似于Node)
- 非资源端点(类似于”/healthz”)
- 集群中所有命名空间的资源(类似Pod)
下面的
ClusterRole可用于授予对任何特定
namespaces中的秘密的读取访问权限,或跨所有命名空间的访问权限。
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、RoleBinding 和 ClusterRoleBinding
角色绑定用于将角色与一个或一组用户进行绑定,从而实现将对用户进行授权的目的。主体分为用户、组和服务帐户。角色绑定也分为角色普通角色绑定和集群角色绑定。角色绑定只能引用同一个命名空间下的角色。
在下面的例子中,在 default 命名空间中角色绑定将 jane 用户和 pod-reader 角色进行了绑定,这就授予了 jane 能够访问 default 命名空间下的 Pod。
# 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 # Name is case sensitive apiGroup: rbac.authorization.k8s.io roleRef: 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
角色绑定也可以通过引用集群角色授予访问权限,当主体对资源的访问仅限与本命名空间,这就允许管理员定义整个集群的公共角色集合,然后在多个命名空间中进行复用。
例如,下面的角色绑定引用了集群角色,但是 dave 用户也仅仅只能读取 development 命名空间中的 secret s资源:
# 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 # Name is case sensitive apiGroup: rbac.au 5b4 thorization.k8s.io roleRef: kind: ClusterRole name: secret-reader apiGroup: rbac.authorization.k8s.io
集群角色可以被用来在集群层面和整个命名空间进行授权。下面的示例允许在 manager 组的用户能够访问所有命名空间中的保密字典资源。
# 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、资源
在Kubernets中,主要的资源包括:Pods、Nodes、Services、Deployment、Replicasets、Statefulsets、Namespace、Persistents、Secrets和ConfigMaps等。另外,有些资源下面存在子资源,例如:Pod下就存在log子资源:
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 指定特定的资源实例,以限制角色只能够对实例 3eac 进行访问控制:
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 命名空间中,名称为“default”的服务帐户:
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
所有被认证的用户 (version 1.5+):
subjects: - kind:Group name:system:authenticated apiGroup:rbac.authorization.k8s.io
所有未被认证的用户 (version 1.5+):
subjects: - kind:Group name:system:unauthenticated apiGroup:rbac.authorization.k8s.io
所有用户(version 1.5+):
subjects: - kind:Group name:system:authenticated apiGroup:rbac.authorization.k8s.io - kind:Group name:system:unauthenticated apiGroup:rbac.authorization.k8s.io
二、命令行工具
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)在整个集群中,授予
view集群角色给
acme:myapp服务帐户:
$ kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp
三、服务帐户权限
默认情况下,RBAC策略授予控制板组件、Node和控制器作用域的权限,但是未授予
kube-system命名空间外服务帐户的访问权限。这就允许管理员按照需要将特定角色授予服务帐户。
从最安全到最不安全的顺序,方法如下:
- 1)授予角色给一个指定应用的服务帐户(最佳实践)
这要求在Pod规格中指定
ServiveAccountName,同时此服务帐户已被创建(通过API、kubectl create serviceaccount等)。例如,在
my-namespace命名空间内,授予
my-sa服务帐户
view集群角色:
kubectl create rolebinding my-sa-view \ --clusterrole=view \ --serviceaccount=my-namespace:my-sa \ --namespace=my-namespace
- 2)在一个命名空间授予
view
集群角色给default
服务帐户
如果应用没有指定serviceAccountName,它将使用
default服务帐户。例如,例如,在
my-namespace命名空间内,授予
default服务帐户
view集群角色:
kubectl create rolebinding default-view \ --clusterrole=view \ --serviceaccount=my-namespace:default \ --namespace=my-namespace
当前,在 kube-system 命名空间中,很多插件作为 default 服务帐户进行运行。为了允许超级用户访问这些插件,在 kube-system 命名空间中授予 cluster-admin 角色给 default 帐户。
$ 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)在整个集群中授予一个角色给所有的服务帐户 (不推荐)
如果不想按照每个命名空间管理权限,可以在整个集群的访问进行授权。例如,在整个集群层面,将 view 集群角色授予 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
- 6)宽松的RBAC权限
下面的策略允许所有的服务帐户作为集群管理员。在容器中运行的应用将自动的收取到服务帐户证书,并执行所有的API行为。包括查看保密字典恩将和修改权限,这是不被推荐的访问策略。
$ kubectl create clusterrolebinding permissive-binding \ --clusterrole=cluster-admin \ --user=admin \ --user=kubelet \ --group=system:serviceaccounts
官方文档:https://kubernetes.io/docs/reference/access-authn-authz/rbac/
- Kubernetes 1.6新特性:RBAC授权
- Kubernetes 1.6新特性学习:RBAC授权
- Kubernetes - 使用RBAC授权
- RBAC基于角色的权限访问控制
- 微信网页授权(基于springboot)
- Asp.net中基于Forms验证的角色验证授权
- RBAC 基于角色的访问控制
- 基于第三方微信授权登录的iOS代码分析
- Android之旅:Android 与 unity3d 基于微信授权、支付、分享,QQ分享,支付宝支付的交互
- CentOS 7.2基于Kubernetes部署简单应用示例
- 基于Android SDK腾讯微博授权认证实现
- kubernetes工作记录(2)——基于release工程的kubernetes1.7.3 rpm包的编译生成
- 基于小程序点击button,获取用户授权信息跟授权弹窗
- RBAC基于角色的权限控制
- 基于OWIN WebAPI 使用OAuth授权服务【客户端验证授权(Resource Owner Password Credentials Grant)】
- 【有容云案例系列】基于Jenkins和Kubernetes的CI工作流
- 基于角色管理(RBAC)的权限系统
- 深度学习(十六)基于2-channel network的图片相似度判别-CVPR 2015
- Asp.Net中基于Forms验证的角色验证授权
- 基于RBAC的Easyui树形权限菜单的实现原理