一：RBAC体系结构

二：RBAC角色绑定流程

三：说明
1.RBAC的优势
a.对集群中的资源和非资源权限均有完整覆盖
b.RBAC由API对象完成，可以用Kubectl或API进行操作
c.可以在允许时进行调整，无须重新启动API Server

2.Role
一个角色就是一组权限的集合，在一个命名空间中，可以使用Role定义一个角色，如果是集群级别的可以使用ClusterRole.

3.ClusterRole
除了和Role一样具有命名空间内资源的管理能力，还可以用于特殊元素的授权。如：
a.集群范围的资源，node等
b.非资源型的路径，如“/healthz”
c.涵盖全部命名空间的资源

4.RoleBinding和ClusterRoleBinding
两者用于把一个角色绑定到一个目标上，如User,Group或Service Account. RoleBinding可以引用Role和ClusterRole, ClusterRoleBinding仅可以引用ClusterRole.

5.对资源的引用方式
a.使用“/”来分隔资源和下级资源如：resources: ["pods", "pods/log"]
b.通过名字进行引用如：resourceNames: ["my-configmap"]

6.常用角色示例
a.运行读取核心API组中的POD资源

点击(此处)折叠或打开

rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]

b.运行读写“extensions”和"apps"两个API组中的deployment资源

点击(此处)折叠或打开

rules:
- apiGroups: ["extensions", "apps"]
resources: ["deployments"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

7.常用角色绑定示例
a.绑定Kube-system命名空间中默认的service-account

点击(此处)折叠或打开

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

b.qa命名空间中的所有service account

点击(此处)折叠或打开

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

c.所有认证用户

点击(此处)折叠或打开

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

8.对Service Account的授权管理
kube-system之外的service account 是没有任何权限的，这就需要用户为service account赋予所需的权限。如：

点击(此处)折叠或打开

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

ITPub博客

kubernetes实践之十六：RBAC 角色访问控制

最新文章