Kubernetes 授权方式-RBAC方式介绍

2019-08-22 0 By admin

Kubernetes 对合法用户进行授权(Authorization)并且随后在用户访问时进行鉴权,是权限与安全系统的重要一环。授权就是授予不同用户不同访问权限。
API Server目前支持以下几种授权策略(通过API Server的启动参数 --authorization-mode 设置):

  1. AlwaysDeny:拒绝所有请求,该配置一般用于测试
  2. AlwaysAllow:接收所有请求,如果集群不需要授权流程,可以采用该策略,此为Kubernetes默认的策略
  3. ABAC:为基于属性的访问控制,表示使用用户配置的授权规则对用户的请求进行匹配和控制
  4. Webhook:通过调用外部REST服务对用户进行授权
  5. RBAC:Role-Based Access Control,基于角色的访问控制

API Server在接收到请求后,会读取该请求中的数据,生成一个访问策略对象,如果该请求中不带某些属性,则会被自动填充默认值。然后将这个访问策略对象和授权策略文件中的所有访问策略对象逐条匹配。如果至少有一个策略对象被匹配,则该请求将被鉴权通过,否则终止API调用流程,并返回客户端的错误调用码。

一、RBAC 授权方式概述

在Kubernetes中,授权有ABAC(基于属性的访问控制)、RBAC(基于角色的访问控制)、Webhook、Node、AlwaysDeny(一直拒绝)和AlwaysAllow(一直允许)这6种模式。从1.6版本起,Kubernetes 默认启用RBAC访问控制策略。从1.8开始,RBAC已作为稳定的功能。
通过设置 –authorization-mode=RBAC,启用RABC。在RABC API中,通过如下的步骤进行授权:
1)定义角色:在定义角色时会指定此角色对于资源的访问控制的规则;
2)绑定角色:将主体与角色进行绑定,对用户进行访问授权。

RBAC 授权方式

二、角色和集群角色

在RBAC API中,角色是代表对一些资源有某些权限集合的规则的名称,和生活中我们谈到的角色很相似。

  1. 在Kubernetes 的 RBAC 授权方式中,权限只有被授予,而没有被拒绝的设置。
  2. 在Kubernetes中有两类角色,即普通角色(role)和集群角色(ClusterRole)。

可以通过Role定义在一个命名空间中的角色,或者可以使用ClusterRole定义集群范围的角色。

2.1、角色 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"]

2.2、集群角色 ClusterRole

集群角色(ClusterRole)能够被授予如下资源的权限:
集群范围的资源(类似于Node)
非资源端点(类似于”/healthz”)
集群中所有命名空间的资源(类似Pod)
下面是授予集群角色读取秘密字典文件访问权限的例子:
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"]

三、角色绑定和集群角色绑定

角色绑定用于将角色与一个或一组用户进行绑定,从而实现对用户进行授权的目的。
主体分为用户、组和服务帐户。
角色绑定也分为角色普通角色绑定和集群角色绑定。

3.1、角色绑定 RoleBinding

角色绑定只能引用同一个命名空间下的角色。
在下面的例子中,在”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
  apiGroup:rbac.authorization.k8s.io
roleRef: #引用的角色
  kind:Role
  name:pod-reader
  apiGroup:rbac.authorization.k8s.io

3.2、角色绑定集群角色 RoleBinding

角色绑定也可以通过引用集群角色授予访问权限,当主体对资源的访问仅限与本命名空间,这就允许管理员定义整个集群的公共角色集合,然后在多个命名空间中进行复用。
例如,下面的角色绑定引用了集群角色,但是“dave”用户也仅仅只能读取“development”命名空间中的secrets资源:
# 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
  apiGroup:rbac.authorization.k8s.io
roleRef:
  kind:ClusterRole
  name:secret-reader
  apiGroup:rbac.authorization.k8s.io

3.3、集群角色绑定 ClusterRoleBinding

集群角色可以被用来在集群层面和整个命名空间进行授权。
下面的示例允许在“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

四、资源的引用方式

在Kubernets中,主要的资源包括:Pods、Nodes、Services、Deployment、Replicasets、Statefulsets、Namespace、Persistents、Secrets和ConfigMaps等。
另外,有些资源下面存在子资源,例如:Pod下就存在log子资源:
GET /api/v1/namespaces/{namespace}/pods/{name}/log

4.1、示例

下面的例子显示,“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"]

4.2、resourceNamess 指定资源实例名称

也可以通过resourceNamess指定特定的资源实例,以限制角色只能够对实例进行访问控制:
kind:Role
apiVersion:rbac.authorization.k8s.io/v1
metadata:
   namespace:default
   name:configmap-updater
rules:
  - apiGroups:[""]
   resources:["configmaps"]
   resourceNames:["my-configmap"]
   verbs:["update","get"]

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

五、主体(授权对象)

RBAC授权中的主体可以是组,用户或者服务帐户。用户通过字符串表示,比如“alice”、 “bob@example.com”等,
具体的形式取决于管理员在认证模块中所配置的用户名。
system:被保留作为用来Kubernetes系统使用,因此不能作为用户的前缀。组也有认证模块提供,格式与用户类似。

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命名空间中,名称为“default”的服务帐户:
subjects:
- kind:ServiceAccount
  name:default
  namespace:kube-system

4、qa”命名空间中,所有的服务帐户:
subjects:
- kind:Group
  name:system:serviceaccounts:qa
  apiGroup:rbac.authorization.k8s.io

5、所有的服务帐户:
subjects:
- kind:Group
  name:system:serviceaccounts
  apiGroup:rbac.authorization.k8s.io

6、所有被认证的用户 (version 1.5+):
subjects:
- kind:Group
  name:system:authenticated
  apiGroup:rbac.authorization.k8s.io

7、所有未被认证的用户 (version 1.5+):
subjects:
- kind:Group
  name:system:unauthenticated
  apiGroup:rbac.authorization.k8s.io

8、所有用户(version 1.5+):
subjects:
- kind:Group
  name:system:authenticated
  apiGroup:rbac.authorization.k8s.io
- kind:Group
  name:system:unauthenticated
  apiGroup:rbac.authorization.k8s.io