Kubernetes之RBAC

API Server的受权管理

API Server 内部经过用户认证后，而后进入受权流程。对合法用户进行受权而且随后在用户访问时进行鉴权，是权限管理的重要环节。API Server 目前支持一下几种受权策略。

• Always Deny： 表示拒绝全部的请求，通常用户测试。
• Always Allow：容许接收全部请求，若是集群不须要受权流程，则能够采用该策略，这也是Kubernetes的默认配置。
• ABAC： 基于属性的访问控制，表示使用用户配置的受权规则对用户请求进行匹配和控制。
• Webhook：经过调用外部REST服务对用户进行受权。
• RBAC：Role-Base Access Control， 基于角色的访问空。

受权管理配置

咱们来看一下kubectl使用的配置文件。

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: REDACTED
    server: https://172.16.138.44:8443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED

受权管理也是kubernetes的标准资源对象，顶层配置有

• clusters  配置多个集群
• contexts 配置多个上下文
• users 配置多个用户
• current-context 当前默认上下文

当前配置文件详解，clusters中有一个集群名字叫kubernetes，users中有一个叫kubernetes-admin的用户，contexts有一个叫kubernetes-admin@kubernetes的上下文配置，而关联起来的集群是kubernetes和user名为kubernetes-admin的关系，而前面的上下文配置是使用的kubernetes-admin@kubernetes。

主要讲解RBAC

Role和ClusterRole

 对某个kubernetes的对象（Objects）上施加的一种行为（get post delete 等），咱们称为Permissions，把Permissions授于Role，就是一个角色了。可以扮演为主体的就是咱们以前讲到的serviceAccount。UserAccount和ServiceAccount。

角色能够由命名空间（namespace）内的Role对象定义，而整个Kubernetes集群范围内有效的角色则经过ClusterRole对象实现。一个Role对象只能用于授予对某一单一命名空间中资源的访问权限。

ClusterRole对象能够授予与Role对象相同的权限，但因为它们属于集群范围对象， 也可使用它们授予对如下几种资源的访问权限：

• 集群范围资源（例如节点，即node）
• 非资源类型endpoint（例如”/healthz”）
• 跨全部命名空间的命名空间范围资源（例如pod，须要运行命令kubectl get pods --all-namespaces来查询集群中全部的pod）

 

定义一个读取Pods 的Role

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pods-reader
  namespace: default
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list
  - watch

定义一个clusterrole

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: clusterrole-reader
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list
  - watch

 

 RoleBinding和ClusterBinding

 RoleBinding将定义的Role受权给一个或者一组用户，RoleBinding就包含了一组相关主体（即subject, 包括用户——User、用户组——Group、或者服务帐户——Service Account）以及对被受权的Role的引用。在命名空间中能够经过RoleBinding对象授予权限，而集群范围的权限授予则经过ClusterRoleBinding对象完成。以下图：

解释：NamespaceA中的Role绑定在RoleBinding上并受权给User1,即User1就拥又了NamespaceA的权限。集群ClusterRole经过ClusterRoleBinding受权给User1,即User1拥有集群权限。NamespaceB中的RoleBinding引用了集群中ClusterRole，RoleBinding受权给User2 User3，即User2 User3拥有NamespaceB的权限。这是你们会又给疑问，为何RoleBinding非要引用了ClusterRole，而不在NamespaceB下建立一个Role呢？由于当咱们又不少Namespace的时候，咱们这样须要建立不少的Role,为了重复建立Role，咱们能够建立一个ClusterRole来让各个Namespace来用RoleBinding去引用，这样就避免从新建立Role了。大大减小运维的工做。

RoleBinding样例

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: jaxzhai-rolebinding
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: pods-reader
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: jaxzhai

roleRef

• apiGroup
• kind
• name

subjects

• apiGroup
• kind
• name
• namespace

ClusterRoleBinding样例

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: read-pods-all
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: clusterrole-reader
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: jaxzhai

kubectl describe clusterrolebinding read-pods-all
Name:         read-pods-all
Labels:       <none>
Annotations:  kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"rbac.authorization.k8s.io/v1beta1","kind":"ClusterRoleBinding","metadata":{"annotations":{},"name":"read-pods-all","namespace":""},"role...
Role:
  Kind:  ClusterRole
  Name:  clusterrole-reader
Subjects:
  Kind  Name     Namespace
  ----  ----     ---------
  User  jaxzhai  

RoleBind 引用ClusterRole

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: clusterrole-test
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: clusterrole-reader
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: jaxzhai