# 权限管理RBAC
Kubernetes集群的所有操作基本上都是通过kube-apiserver这个组件进行的，它提供HTTP [RESTful](https://www.centos.bz/tag/restful/)形式的API供集群内外客户端调用。需要注意的是：认证授权过程只存在[HTTPS](https://www.centos.bz/tag/https/)形式的API中。也就是说，如果客户端使用HTTP连接到kube-apiserver，那么是不会进行认证授权的。所以说，可以这么设置，在集群内部组件间通信使用HTTP，集群外部就使用HTTPS，这样既增加了安全性，也不至于太复杂。
基本结构主要就是三个:
* 权限: 即对系统中指定资源的增删改查权限
* 角色: 将一定的权限组合在一起产生权限组，如管理员角色
* 用户: 具体的使用者，具有唯一身份标识(ID)，其后与角色绑定便拥有角色的对应权限
**Kubernetes 是不负责维护存储用户数据的；对于 Kubernetes 来说，它识别或者说认识一个用户主要就几种方式**
* X509 Client Certs: 使用由 k8s 根 CA 签发的证书，提取 O 字段
* Static Token File: 预先在 API Server 放置 Token 文件(bootstrap 阶段使用过)
* Bootstrap Tokens: 一种在集群内创建的 Bootstrap 专用 Token(新的 Bootstarp 推荐)
* Static Password File: 跟静态 Token 类似
* Service Account Tokens: 使用 Service Account 的 Token
其他不再一一列举，具体请看文档 [Authenticating](https://kubernetes.io/docs/admin/authentication/)；了解了这些，后面我们使用 RBAC 控制 kubectl 权限的时候就要使用如上几种方法创建对应用户
RBAC 权限定义部分主要有三个层级
* apiGroups: 指定那个 API 组下的权限
* resources: 该组下具体资源，如 pod 等
* verbs: 指对该资源具体执行哪些动作
定义一组权限(角色)时要根据其所需的真正需求做最细粒度的划分
下图是 API 访问要经过的三个步骤，前面两个是认证和授权，第三个是 Admission Control
client发起apiserver调用时，apiserver先**认证(Authentication)用户，再给用户**授权(Authorization)，最后执行**准入控制(Admission Control)**
* 认证：鉴别发起请求的**用户**是否合法
* 授权：授予用户**api请求**权限，并鉴别用户访问的**api请求**是否合法
* 准入控制：一些额外的检查机制，用于做最后的拦截
#### TLS原理
基于CA根证书签名的双向数字证书认证
* client和server向CA机构申请证书
* client->server，server下发服务端证书，client利用证书验证server是否合法
* client发送客户端证书给server，server利用证书校验client是否合法
* client和server利用随机密钥加密消息，然后通信
{% embed url="" %}
## 授权
授权就是授予用户请求权限，并鉴别用户的api请求是否合法的过程
目前支持的几种授权策略：
* AlwaysDeny：拒绝所有请求，用于测试
* AlwaysAllow：允许所有请求，k8s默认策略
* ABAC：基于属性的访问控制。表示使用用户配置的规则对用户请求进行控制
* RBAC：基于角色的访问控制
* Webhook：通过调用外部rest服务对用户授权
RBAC的四个资源对象：
1. Role：一个角色就是一组权限的集合，拥有某个namespace下的权限
2. ClusterRole：集群角色，拥有整个cluster下的权限
3. RoleBinding：将Role绑定目标（user、group、service account）
4. ClusterRoleBinding：将ClusterRoleBinding绑定目标
一个典型的映射关系
##
为kubernetes 访问用户添加权限控制
了方便增加了一个`admin`用户，然后授予了`cluster-admin`的角色绑定，而该角色绑定是系统内置的一个超级管理员权限，也就是用该用户的`token`登录`Dashboard`后会很**强势**，什么权限都有，想干嘛干嘛，这样的操作显然是非常危险的。接下来我们来为一个新的用户添加访问权限控制。
### Role
`Role`表示是一组规则权限，只能累加，`Role`可以定义在一个`namespace`中，只能用于授予对单个命名空间中的资源访问的权限。比如我们新建一个对默认命名空间中`Pods`具有访问权限的角色：
```
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["pods"]
verbs: ["get", "watch", "list"]
```
### ClusterRole
`ClusterRole`具有与`Role`相同的权限角色控制能力，不同的是`ClusterRole`是集群级别的，可以用于:
* 集群级别的资源控制(例如 node 访问权限)
* 非资源型 endpoints(例如 /healthz 访问)
* 所有命名空间资源控制(例如 pods)
比如我们要创建一个授权某个特定命名空间或全部命名空间(取决于绑定方式)访问**secrets**的集群角色：
```
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
# "namespace" omitted since ClusterRoles are not namespaced
name: secret-reader
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "watch", "list"]
```
### RoleBinding和ClusterRoleBinding
`RoloBinding`可以将角色中定义的权限授予用户或用户组，`RoleBinding`包含一组权限列表(`subjects`)，权限列表中包含有不同形式的待授予权限资源类型(users、groups、service accounts)，`RoleBinding`适用于某个命名空间内授权，而 `ClusterRoleBinding`适用于集群范围内的授权。
比如我们将默认命名空间的`pod-reader`角色授予用户jane，这样以后该用户在默认命名空间中将具有`pod-reader`的权限：
```
# This role binding allows "jane" to read pods in the "default" namespace.
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
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
```
`RoleBinding`同样可以引用`ClusterRole`来对当前 namespace 内用户、用户组或 ServiceAccount 进行授权，这种操作允许集群管理员在整个集群内定义一些通用的 ClusterRole，然后在不同的 namespace 中使用 RoleBinding 来引用
例如，以下 RoleBinding 引用了一个 ClusterRole，这个 ClusterRole 具有整个集群内对 secrets 的访问权限；但是其授权用户 dave 只能访问 development 空间中的 secrets(因为 RoleBinding 定义在 development 命名空间)
```
# This role binding allows "dave" to read secrets in the "development" namespace.
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
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
```
最后，使用 ClusterRoleBinding 可以对整个集群中的所有命名空间资源权限进行授权；以下 ClusterRoleBinding 样例展示了授权 manager 组内所有用户在全部命名空间中对 secrets 进行访问
```
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
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
```
案例实践;
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://darren.gitbook.io/project/k8s-yun-wei-pai-cha/gu-zhang-chu-li/quan-xian-guan-li-rbac.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.