Kubernetes之RBAC-白红宇

Kubernetes之RBAC

阅读量：4698 次

发布时间：2019-06-09

本文共 3944 字，大约阅读时间需要 13 分钟。

API Server的授权管理

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

Always Deny：表示拒绝所有的请求，一般用户测试。

Always Allow：允许接收所有请求，如果集群不需要授权流程，则可以采用该策略，这也是Kubernetes的默认配置。

ABAC：基于属性的访问控制，表示使用用户配置的授权规则对用户请求进行匹配和控制。

Webhook：通过调用外部REST服务对用户进行授权。

RBAC：Role-Base Access Control，基于角色的访问空。

授权管理配置

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

apiVersion: v1clusters:- cluster:    certificate-authority-data: REDACTED    server: https://172.16.138.44:8443  name: kubernetescontexts:- context:    cluster: kubernetes    user: kubernetes-admin  name: kubernetes-admin@kubernetescurrent-context: kubernetes-admin@kuberneteskind: Configpreferences: {}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/v1kind: Rolemetadata:  name: pods-reader  namespace: defaultrules:- apiGroups:  - ""  resources:  - pods  verbs:  - get  - list  - watch

定义一个clusterrole

apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:  name: clusterrole-readerrules:- 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/v1kind: RoleBindingmetadata:  name: jaxzhai-rolebinding  namespace: defaultroleRef:  apiGroup: rbac.authorization.k8s.io  kind: Role  name: pods-readersubjects:- apiGroup: rbac.authorization.k8s.io  kind: User  name: jaxzhai

roleRef

apiGroup

kind

name

subjects

apiGroup

kind

name

namespace

ClusterRoleBinding样例

apiVersion: rbac.authorization.k8s.io/v1beta1kind: ClusterRoleBindingmetadata:  name: read-pods-allroleRef:  apiGroup: rbac.authorization.k8s.io  kind: ClusterRole  name: clusterrole-readersubjects:- apiGroup: rbac.authorization.k8s.io  kind: User  name: jaxzhai

kubectl describe clusterrolebinding read-pods-allName:         read-pods-allLabels:       
     
      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-readerSubjects:  Kind  Name     Namespace  ----  ----     ---------  User  jaxzhai

RoleBind 引用ClusterRole

apiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata:  name: clusterrole-testroleRef:  apiGroup: rbac.authorization.k8s.io  kind: ClusterRole  name: clusterrole-readersubjects:- apiGroup: rbac.authorization.k8s.io  kind: User  name: jaxzhai

转载于:https://www.cnblogs.com/xzkzzz/p/9909468.html

你可能感兴趣的文章