一 RBAC
1.1 RBAC 授权
基于角色的访问控制 (RBAC) 是一种基于个人用户的角色来管理对计算机或网络资源的访问的方法.
RBAC 使用 rbac.authorization.k8s.io API 组来推动授权决策, 允许管理员通过 Kubernetes API 动态配置策略.
使用 --authorization-mode=RBAC 开启 RBAC 授权模块功能.
RBAC API 定义了四个资源对象用于描述 RBAC 中用户和资源之间的连接权限:
- Role
- ClusterRole
- RoleBinding
- ClusterRoleBinding
二 角色
2.1 Role 和 ClusterRole
RBAC API 声明了四种类型.
在 RBAC API 中, 角色包含表示一组权限的规则. 权限都是叠加的, 没有 deny 规则. 附加的(没有 "拒绝" 规则). 可以使用参数 role 在一个 namespace 中定义一个角色, 或者在集群范围内使用 ClusterRole 定义集群角色.
一个 Role 只能用于授予对单个命名空间内的资源的访问权限.
示例 1:
- apiVersion: rbac.authorization.k8s.io/v1
- kind: Role
- metadata:
- namespace: default
- name: pod-reader
- rules:
- - apiGroups: [""] #"" indicates the core API group
- resources: ["pods"]
- verbs: ["get", "watch", "list"]
解释: 该 Role 授予对 "default" 命名空间中的 pod 的读取权限.
一个 ClusterRole 可用于授予与一个 Role 相同的权限, 同时由于它们是群集范围的, 因此它们还可用于授予对以下内容的访问权限:
集群范围的资源(如 nodes);
non-resource endpoints(如 "/healthz");
跨所有命名空间 (可通过 kubectl get pods --all-namespaces 查看) 的命名空间资源(如 pods).
示例 2:
- 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 可用于授予对任何特定命名空间或所有命名空间中的 secrets 资源的读访问权限.
2.2 RoleBinding 和 ClusterRoleBinding
角色绑定将角色中定义的权限授予用户或用户组. 它包含由 users,groups, 或 service accounts 组成的列表, 以及对所授予角色的引用. 可以在具有个 RoleBinding 集群名称或具有一个 ClusterRoleBinding 范围内授予权限.
一个 RoleBinding 可以引用同一名称空间中的 Role.
示例:
- apiVersion: rbac.authorization.k8s.io/v1
- # This role binding allows "jane" to read pods in the "default" namespace.
- kind: RoleBinding
- 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
解释: 该 RoleBinding 将 "pod-reader" 角色授予 "default" 命名空间中的用户 "jane", 同时允许 "jane" 读取 "default" 命名空间中的 pod.
该 RoleBinding 使用 roleRef 将用户 "jane" 绑定到 Role 上面创建的名称 pod-reader.
2.3 默认角色
API 服务器创建了一组默认 ClusterRole 和 ClusterRoleBinding 对象. 其中格式为 system: 前缀的表示该资源由系统基础设施所拥有. 手动修改该类资源可能导致集群功能异常, 若 system:node 的 ClusterRole, 定义了 kubelet 的权限.
提示: 所有默认群集角色和角色绑定都标有 kubernetes.io/bootstrapping=rbac-defaults.
三 角色相关命令
3.1 创建角色
- [[email protected] ~]# kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods
- role.rbac.authorization.k8s.io/pod-reader created
解释: 创建一个名为 "pod-reader" 的 Role, 允许用户在 pod 上执行 "get","watch" 和 "list".
1 [[email protected] ~]# kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod
解释: 创建一个指定了 namespace 为 anotherpod 的名为 "pod-reader" 的 Role.
1 [[email protected] ~]# kubectl create role foo --verb=get,list,watch --resource=replicasets.apps
解释: 创建一个指定 apiGroups 的名为 "foo" 的 Role, 允许用户在 replicasets.apps 上执行 "get","watch" 和 "list".
1 [[email protected] ~]# kubectl create role foo --verb=get,list,watch --resource=pods,pods/status
解释: 创建一个指定子资源权限的名为 "foo" 的 Role, 允许用户在 pods 上执行 "get","watch" 和 "list".
3.2 创建集群角色
1 [[email protected] ~]# kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods
解释: 创建一个名为 "pod-reader" 的 clusterrole, 允许用户在 pod 上执行 "get","watch" 和 "list".
1 [[email protected] ~]# kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod
解释: 创建一个指定了 resourceNames 名为 "pod-reader" 的 clusterrole, 并允许执行 "get".
1 [[email protected] ~]# kubectl create clusterrole foo --verb=get,list,watch --resource=replicasets.apps
解释: 创建一个指定 apiGroups 的名为 "foo" 的 clusterrole, 允许用户在 replicasets.apps 上执行 "get","watch" 和 "list".
1 [[email protected] ~]# kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status
解释: 创建一个指定子资源权限的名为 "foo" 的 clusterrole, 允许用户在 pods 上执行 "get","watch" 和 "list".
1 [[email protected] ~]# kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/*
解释: 创建一个指定了 non-resource 路径名为 "pod-reader" 的 clusterrole, 并允许执行 "get".
3.3 权限和角色绑定
1 [[email protected] ~]# kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme
解释: 在 acme 的 namespace 中, 将 admin 的 clusterrole 和 bob 用户进行绑定.
1 [[email protected] ~]# kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme
解释: 在 acme 的 namespace 中, 将 view 的 clusterrole 和 myapp 服务账号进行绑定.
1 [[email protected] ~]# kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme
解释: 在 acme 的 namespace 中, 将 view 的 clusterrole 和 myapp 的 namespace 中的服务账号进行绑定.
3.4 权限和集群角色绑定
1 [[email protected] ~]# kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme
解释: 在整个集群中, 将 cluster-admin 的 clusterrole 和 root 用户进行绑定.
1 [[email protected] ~]# kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy
解释: 在整个集群中, 将 system:node-proxier 的 clusterrole 和 system:kube-proxy 用户进行绑定.
1 [[email protected] ~]# kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp
解释: 在整个集群中, 将 view 的 clusterrole 和 myapp 中的 acme 服务账户进行绑定.
提示: roles 和 clusterroles 的区别在于 roles 只能对某个命令空间内的资源定义权限. 而集群角色定义的权限都是针对整个集群的命名空间的.
更多 RBAC 参考: https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-clusterrole
3.4 相关对比
ClusterRole 和 ClusterRoleBinding 是针对整个 Cluster 范围内有效的, 无论用户或资源所在的 namespace 是什么;
Role 和 RoleBinding 的作用范围是局限在某个 k8s namespace 中的.
kubernetes 在安装之初就已经生成了许多 role,rolebinding,clusterrole 和 clusterrolebinding, 它们也是属于 kubernetes 资源的一部分, 可通过 get,describe 等命令查看, 如下:
1 [[email protected] ~]# kubectl get role -n kube-system
1 [[email protected] ~]# kubectl describe role extension-apiserver-authentication-reader -n kube-system
来源: http://www.bubuko.com/infodetail-3109721.html