Kubernetes权限管理之RBAC

k8s在启用基于角色管理的访问控制 RBAC（Role-based-Access-Control）的授权模式。相当于基于属性的访问控制ABAC（Attribute-based Access Control）,RBAC主要是引入了 角色（Role  权限的集合） 和角色绑定（RoleBinding）的抽象概念。在ABAC中，k8s集群中的访问策略只能跟用户直接关联；而RBAC中，访问策略可以跟某个角色关联，具体的用户再和某个角色或者多个角色关联。

RBAC有四个新的k8s顶级资源对象： 角色（Role）、集群角色（ClusterRole）、角色绑定（RoleBinding）、集群角色绑定（ClusterRoleBinding）。同其他API资源对象一样，用户可以使用kubectl或者API调用方式等操作这些资源对象

 RBAC具有如下优势

• 对集群中的资源和非资源权限有完整的覆盖
• 整个RBAC完由几个API对象完成，同其他API对象一样，可以使用kubectl 或API进行操作
• 可以在运行时进行调整，无须重新启动API server
• 使用RBAC授权模式，则需要在API sever的启动参数中 加上  --authorization-mod=RBAC。

 角色（Role）

 一个角色就是一组权限的集合，这里的权限都是许可形式的，不存在拒绝的规则。在一个名称空间（namespace）中，可以用角色来定义一个角色，如果是集群级别的，就需要使用ClusterRole了，角色只能对指定名称空间内的资源进行授权，下面例子中定义的角色具备读取pod的权限

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]    # ""空字符串，表示核心API群
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

rules中的参数说明：

• apiGroups：支持的API组列表，如“apiVersion: batch/v1"、"apiVersion: extensions:v1beta1"、"apiVersion:apps/v1beta1"等。
• resources： 支持的资源对象列表，如pods、deployments、jobs等
• verbs： 对资源对象的操作方法列表，如 get、watch、list、delete、replace、patch等

 集群角色（ClusterRole）

 集群角色除了具有和角色（role）一致的名称空间内资源的管理能力，因其集群级别的生效范围，还可以用于以下特殊元素的授权管理上：

• 集群范围的资源，如node
• 非资源型的路径，如‘/healthz’
• 包含全部名称空间的资源，如pods（用于kubectl get pods --all-namespaces这样的操作授权）

 下面的集群角色可以让用户有权限访问任意一个或所有名称空间的secrets：

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  # ClusterRole不受限于命名空间，所以省略了namespace name的定义
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

角色绑定（RoleBinding）和 集群角色绑定（ClusterRoleBinding）

角色绑定或集群角色绑定 用来把一个角色绑定到一个目标（用户）上，绑定的目标可以是User（用户）、Group（组）、ServiceAccount。使用RoleBinding可以为某一个名称空间授权，使用ClusterRoleBinding可以为集群范围内授权。

RoleBinding可以引用Role进行授权，如下中的RoleBinding将在defalut名称空间中把pod-reader角色授予用户jane，这一操作让jane用户可以读取到default名称空间中的pod

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-pods   #RoleBinding名称
  namespace: default  #授予的名称空间
subjects:
- kind: User
    name: jane            #授权用户
    apiGroup: rbac.authorization.k8s.io 
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

RoleBinding 也可以引用ClusterRole进行授权

RoleBinding可以引用ClusterRole，对属于同一命名空间内 ClusterRole定义的资源主体进程授权。一种很常用的做法就是集群管理员为集群范围预定义好一组角色（ClusterRole），然后在多个名称空间中应用这些ClusterRole。这样可以提高授权管理工作效率，也使得各个名称空间下基础性授权规则与使用体验保持一致。

 如下，虽然secret-reader是一个集群角色，但是因为使用了RoleBinding，所以dave只能读取development名称空间中的secret

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-secrets
  namespace: development   # 集群角色中，只有在development命名空间中的权限才能赋予dave
subjects:
- kind: User
  name: dave
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding 集群角色绑定中角色只能是集群角色，用于进行集群级别或者对所有名称空间（all-namespaces）都生效的授权。如 允许manager组的用户读取任意namespace中的secret：

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
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

下图展示了上述对Pod的get/watch/list操作进行授权的Role和RoleBinding逻辑关系。

对资源的引用方式

 多数资源可以用其名称的字符串来表达，也就是Endpoint中的URL相对路径，例如pods。然而，某些k8s API包含下级资源，如pod的日志（logs）。pod日志的Endpoint是GET/api/v1/namespaces/{namespace}/pods/{pod_name}/log。

在这个例子中，Pod是一个命名空间内的资源，log就是一个下级资源。要在RBAC角色中体现，则需要用斜线 '/' 来区隔资源和下级资源。

若想授权让某个主体同时能够读取Pod和 Pod log，则可以配置resources为一个数组：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default
  name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list"]

 资源还可以通过名称（ResourceName） 进行引用（这里指的是资源实例的名字）。在指定ResourceName后，使用get、delete、update、patch动作的请求，就会被限制这个资源实例的范围内。

如 声明让一个主体只能对一个configmap进行get 和update操作

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default
  name: configmap-updater
rules:
- apiGroups: [""]
  resources: ["configmap"]
  resourceNames: ["my-configmap"]
  verbs: ["update", "get"]

resourceName 这种用法对list、watch、create、deletecollection操作是无效的，这是因为必须要通过URL进行鉴权，而资源名称在list、watch、create和deletecollection请求中只能请求Body数据的一部分。

常用的角色（Role）实例

1. 允许读取核心API组中的Pod资源

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

2. 允许读写"extensions"和"apps"两个API组中的"deployments"资源

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

3. 允许读取"pods"及读写"jobs"

   rules:
   - apiGroups: [""]
     resources: ["pods"]
     verbs: ["get", "list", "watch"]
   - apiGroups: ["batch", "extensions"]
     resources: ["jobs"]
     verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

4. 允许读取一个名为"my-config"的ConfigMap（必须绑定到一个RoleBinding来限制到一个namespace下的ConfigMap）

   rules:
   - apiGroups: [""]
     resources: ["configmaps"]
     resourceNames: ["my-config"]
     verbs: ["get"]

5. 读取核心组的"node"资源（Node属于集群级的资源，所以必须存在于ClusterRole中，并使用ClusterRoleBinding进行绑定）

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

6. 允许对非资源端点/healthz及其所有子路径进行GET和POST操作（必须使用ClusterRole和ClusterRoleBinding）

   rules:
   - nonResourceURLs: ["/healthz", "/healthz/*"]
     verbs: ["get", "post"]

常用的角色绑定（RoleBinding）示例

注意，下面的例子中只包含subjects部分的内容。

1. 用户名"alice@example.com"

   subjects:
   - kind: User
     name: "alice@example.com"
     apiGroup: rbac.authorization.k8s.io

2. 组名"frontend-admins"

   subjects:
   - kind: Group
     name: "frontend-admins"
     apiGroup: rbac.authorization.k8s.io

3. kube-system命名空间中的默认Service Account

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

4. "qa"命名空间中的所有Service Account

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

5. 所有Service Account

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

6. 所有认证用户（v1.5版本以上）

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

7. 所有未认证用户（v1.5版本以上）

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

8. 全部用户（v1.5版本以上）

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

默认的角色和角色绑定

API Server创建了一系列的默认ClusterRole和ClusterRoleBinding对象，其中许多对象已“system：”前缀开头，代表其中绑定的资源作为基础设施适用和占有的，修改这些资源会导致整个集群不可用。一个例子是system:node  ClusterRole角色拥有一系列的kubelet权限，如果这个集群角色被修改了，可能会让kubelet异常

所有默认的集群角色（ClusterRole） 和其角色绑定（role binding）都带有如下标记

kubernetes.io/bootstrapping=rbac-defaults

对系统角色的说明如下表所示

默认的ClusterRole	默认的ClusterRoleBinding	描述
system:basic-user	system:authenticated和system:unauthenticated组	让用户能够读取自身的信息
system:discovery	system:authenticated和system:unauthenticated组	对API发现Endpoint的只读访问，用于API级别的发现和协商

对用户角色的说明如下表所示：

默认的ClusterRole	默认的ClusterRoleBinding	描述
cluster-admin	system:masters组	让超级用户可以对任何资源执行任何操作。如果在ClusterRoleBinding中使用，则影响的是整个集群的所有namespace中的任何资源；如果使用的是RoleBinding，则能控制这一绑定的namespace中的资源，还包括namespace本身。
cluster-status	None	可以对基础集群状态信息进行只读访问。
admin	None	允许admin访问，可以限制在一个namespace中使用RoleBinding。如果在RoleBinding中使用，则允许对namespace中大多数资源进行读写访问，其中包含创建角色和角色绑定的能力。这一角色不允许操作namespace本身，也不能写入资源限额。
edit	None	允许对命名空间内的大多数资源进行读写操作，不允许查看或修改角色，以及角色绑定。
view	None	允许对多数对象进行只读操作，但是对角色、角色绑定及secret是不可访问的。

注：有些默认角色不是以"system:" 为前缀的，这部分角色是针对用户的，其中包含超级用户角色（cluster-admin），有的用于集群一级的角色（cluster-status），还有针对namespace的角色（admin、edit、view） 

对核心Master组件角色的说明如下表所示：

转载地址：https://www.orchome.com/1308

默认的ClusterRole 默认的ClusterRoleBinding 描述 system:basic-user system:authenticated和system:unauthenticated组 让用户能够读取自身的信息 system:discovery system:authenticated和system:unauthenticated组 对API发现Endpoint的只读访问，用于API级别的发现和协商

作者：半兽人
链接：https://www.orchome.com/1308
来源：OrcHome
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

 

描述