1、RBAC介绍
在Kubernetes中,授权有ABAC(基于属性的访问控制)、RBAC(基于角色的访问控制)、Webhook、Node、AlwaysDeny(一直拒绝)和AlwaysAllow(一直允许)这6种模式。从1.6版本起,Kubernetes 默认启用RBAC访问控制策略。从1.8开始,RBAC已作为稳定的功能。通过设置–authorization-mode=RBAC,启用RABC。在RABC API中,通过如下的步骤进行授权:1)定义角色:在定义角色时会指定此角色对于资源的访问控制的规则;2)绑定角色:将主体与角色进行绑定,对用户进行访问授权。
1.1 角色和集群角色
在RBAC API中,角色包含代表权限集合的规则。在这里,权限只有被授予,而没有被拒绝的设置。在Kubernetes中有两类角色,即普通角色和集群角色。可以通过Role定义在一个命名空间中的角色,或者可以使用ClusterRole定义集群范围的角色。一个角色只能被用来授予访问单一命令空间中的资源。下面是在“default”命令空间中定义了一个名为“pod-reader”的角色,此角色能够对在“default”命名空间中访问Pod:
kind: RoleapiVersion: rbac.authorization.k8s.io/v1metadata: namespace: default name: pod-readerrules:- apiGroups: [""] # "" indicates the core API group resources: ["pods"] verbs: ["get", "watch", "list"]
集群角色(ClusterRole)能够被授予如下资源的权限:
下面是授予集群角色读取秘密字典文件访问权限的例子:
kind:ClusterRoleapiVersion:rbac.authorization.k8s.io/v1metadata: # "namespace" omitted since ClusterRoles are not namespaced name:secret-readerrules:- apiGroups:[""]resources:["secrets"] #明确资源类型verbs:["get","watch","list"]
角色绑定用于将角色与一个或一组用户进行绑定,从而实现将对用户进行授权的目的。主体分为用户、组和服务帐户。角色绑定也分为角色普通角色绑定和集群角色绑定。角色绑定只能引用同一个命名空间下的角色。在下面的例子中,在”default”命名空间中角色绑定将‘jane’用户和“pod-reader”角色进行了绑定,这就授予了“jane”能够访问“default”命名空间下的Pod。
# This role binding allows "jane" to read pods in the "default" namespace.kind:RoleBindingapiVersion:rbac.authorization.k8s.io/v1metadata: name:read-pods namespace:defaultsubjects: #主体- kind:User name:jane apiGroup:rbac.authorization.k8s.ioroleRef: #引用的角色 kind:Role name:pod-reader apiGroup:rbac.authorization.k8s.io
角色绑定也可以通过引用集群角色授予访问权限,当主体对资源的访问仅限与本命名空间,这就允许管理员定义整个集群的公共角色集合,然后在多个命名空间中进行复用。例如,下面的角色绑定引用了集群角色,但是“dave”用户也仅仅只能读取“development”命名空间中的secrets资源:
# This role binding allows "dave" to read secrets in the "development" namespace.kind:RoleBindingapiVersion:rbac.authorization.k8s.io/v1metadata: name:read-secrets namespace:development# This only grants permissions within the "development" namespace.subjects:- kind:User name:dave apiGroup:rbac.authorization.k8s.ioroleRef: 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:ClusterRoleBindingapiVersion:rbac.authorization.k8s.io/v1metadata: name:read-secrets-globalsubjects:- kind:Group name:manager apiGroup:rbac.authorization.k8s.ioroleRef: kind:ClusterRole name:secret-reader apiGroup:rbac.authorization.k8s.io
在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:RoleapiVersion:rbac.authorization.k8s.io/v1metadata: namespace:default name:pod-and-pod-logs-readerrules:- apiGroups:[""] resources:["pods","pods/log"] verbs:["get","list"]
也可以通过resourceNamess指定特定的资源实例,以限制角色只能够对实例进行访问控制:
kind:RoleapiVersion:rbac.authorization.k8s.io/v1metadata: namespace:default name:configmap-updaterrules:- apiGroups:[""] resources:["configmaps"] resourceNames:["my-configmap"] verbs:["update","get"]
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可以通过命令工具进行角色绑定。
在指定的命名空间中进行角色绑定:
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
在整个集群中进行角色绑定:
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
4、宽松的RBAC权限
下面的策略允许所有的服务帐户作为集群管理员。在容器中运行的应用将自动的收取到服务帐户证书,并执行所有的API行为。包括查看保密字典恩将和修改权限,这是不被推荐的访问策略。
$ kubectl create clusterrolebinding permissive-binding \--clusterrole=cluster-admin \--user=admin \--user=kubelet \--group=system:serviceaccounts
本文分享自 kubernetes中文社区 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ,欢迎热爱写作的你一起参与!