第一章：访问控制概述

1.1 概述

• 用户使用 kubectl、客户端库或构造 REST 请求来访问 Kubernetes API。 人类用户和 Kubernetes 服务账户都可以被鉴权访问 API。 当请求到达 API 时，它会经历多个阶段，如下图所示：

1.2 客户端

• 在 Kubernetes 集群中，客户端通常由两类：

  • ① User Account：一般是独立于 Kubernetes 之外的其他服务管理的用户账号。
  • ② Service Account：Kubernetes 管理的账号，用于为Pod的服务进程在访问 Kubernetes 时提供身份标识。

1.3 认证、授权和准入控制

• api-server 是访问和管理资源对象的唯一入口。任何一个请求访问 api-server，都要经过下面的三个流程：

  • ① Authentication（认证）：身份鉴别，只有正确的账号才能通过认证。
  • ② Authorization（授权）：判断用户是否有权限对访问的资源执行特定的动作。
  • ③ Admission Control（准入控制）：用于补充授权机制以实现更加精细的访问控制功能。

1.4 权限流程控制

• 用户携带令牌或者证书给 Kubernetes 的 api-server 发送请求，要求修改集群资源。
• Kubernetes 开始认证。
• Kubernetes 认证通过之后，会查询用户的授权（有哪些权限）。
• 用户执行操作的过程中（操作 CPU、内存、硬盘、网络……），利用准入控制来判断是否可以执行这样的操作。

第二章：认证管理

2.1 Kubernetes 的客户端身份认证方式

• Kubernetes 集群安全的关键点在于如何识别并认证客户端身份，它提供了 3 种客户端身份认证方式：

• ① HTTP Base 认证：

  • 通过 用户名+密码 的方式进行认证。
  • 这种方式是把 用户名:密码 用 BASE64 算法进行编码后的字符串放在 HTTP 请求中的 Header 的 Authorization 域里面发送给服务端。服务端收到后进行解码，获取用户名和密码，然后进行用户身份认证的过程。

• ② HTTP Token 认证：

  • 通过一个 Token 来识别合法用户。
  • 这种认证方式是用一个很长的难以被模仿的字符串--Token 来表明客户端身份的一种方式。每个 Token 对应一个用户名，当客户端发起 API 调用请求的时候，需要在 HTTP 的 Header 中放入 Token，API Server 接受到 Token 后会和服务器中保存的 Token 进行比对，然后进行用户身份认证的过程。

• ③ HTTPS 证书认证：

  • 基于 CA 根证书签名的双向数字证书认证方式。
  • 这种认证方式是安全性最高的一种方式，但是同时也是操作起来最麻烦的一种方式。

2.2 总结

• Kubernetes 允许同时配置多种认证方式，只要其中任意一种方式认证通过即可。

第三章：授权管理

3.1 概述

• 授权发生在认证成功之后，通过认证就可以知道请求用户是谁，然后 Kubernetes 会根据事先定义的授权策略来决定用户是否有权限访问，这个过程就称为授权。
• 每个发送到 API Server 的请求都带上了用户和资源的信息：比如发送请求的用户、请求的路径、请求的动作等，授权就是根据这些信息和授权策略进行比较，如果符合策略，则认为授权通过，否则会返回错误。

3.2 API Server目前支持的几种授权策略

• AlwaysDeny：表示拒绝所有请求，一般用于测试。
• AlwaysAllow：允许接收所有的请求，相当于集群不需要授权流程（Kubernetes 默认的策略）。
• ABAC：基于属性的访问控制，表示使用用户配置的授权规则对用户请求进行匹配和控制。
• Webhook：通过调用外部REST服务对用户进行授权。
• Node：是一种专用模式，用于对 kubelet 发出的请求进行访问控制。
• RBAC：基于角色的访问控制（ kubeadm 安装方式下的默认选项）。
• 证明：kubeadm 安装方式的默认授权策略

cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep -i rbac

3.3 RBAC

3.3.1 概述

• RBAC（Role Based Access Control）：基于角色的访问控制，主要是在描述一件事情：给哪些对象授权了哪些权限。
• RBAC 模型：

• Kubernetes 中的 RBAC 也是基于 RBAC 模型扩展的，涉及到如下的概念：

  • 对象：User、Group、ServiceAccount。
  • 角色：代表一组定义在资源上的可操作的动作（权限）的集合。
  • 绑定：将定义好的角色和用户绑定在一起，也可以理解为分配角色。

• RBAC 引入了 4 个顶级资源对象：

  • Role：角色，用于指定一组权限，限定名称空间下的权限。
  • ClusterRole：集群角色，用于指定一组权限，限定集群范围下的权限。
  • RoleBinding：角色绑定，用于将角色 Role（权限的集合）赋予给对象（User、Group、ServiceAccount）。
  • ClusterRoleBinding：集群角色绑定，用于将集群角色 Role（权限的集合）赋予给对象（User、Group、ServiceAccount）。

说明：为什么 Kubernetes 要设计 Role 、 ClusterRole ？
答：有些资源对象本身就不是 namespace（名称空间）的 ，所以 Kubernetes 增加了 ClusterRole，并且 ClusterRole 也可以管理名称空间下的资源对象。

3.3.2 Role 和 ClusterRole资源清单文件

• 一个角色就是一组权限的集合，这里的权限都是许可形式的（白名单）。
• Role 的资源清单文件：

# 名称空间角色
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: xudaxian-role
  namespace: default # 所属的名称空间
rules: # 当前角色的规则
- apiGroups: [""] # "" 标明 core API 组，默认留空即可。
  resources: ["pods"] 
  verbs: ["get", "watch", "list"]

• Role 只能对名称空间（namespace）进行授权，所以需要指定名称空间（namespace）。

• rules 中的参数说明：

  • apiGroups：[""]，默认留空即可。
  • resources：支持的资源对象列表，通过 kubectl api-resources 查看。

• verbs：对资源对象的操作方法列表，通过 kubectl api-resources -o wide 查看。

• ClusterRole 的资源清单文件：

# 集群角色
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: xudaxian-clusterrole
rules:
- apiGroups: [""] # "" 标明 core API 组，默认留空即可。
  resources: ["namespaces"]
  verbs: ["get", "watch", "list"]

注意：ClusterRole 不需要设置 namespace。

3.3.4 RoleBinding 和 ClusterRoleBinding 资源清单文件

• 角色绑定用来把一个角色绑定到一个目标对象上，绑定目标可以是 User、Group 或者 ServiceAccount 。
• RoleBinding 资源清单文件：

# 账号和角色绑定
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: xudaxian-rolebinding
  namespace: default
subjects:
- kind: ServiceAccount
  name: xudaxian # "name" 是区分大小写的
roleRef:
  kind: Role
  name: xudaxian-role
  apiGroup: rbac.authorization.k8s.io

• ClusterRoleBinding 资源清单文件：

# 账号和集群角色绑定
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: xudaxian-clusterrolebinding
subjects:
- kind: ServiceAccount
  name: xudaxian # "name" 是区分大小写的
  namespace: default # 如果资源是某个 namespace 下的，那么就需要设置 namespace
roleRef:
  kind: ClusterRole
  name: xudaxian-clusterrole
  apiGroup: rbac.authorization.k8s.io

3.3.5 RBAC 实战

• 创建 ServiceAccount 的时候，系统会在底层默认一个含 ServiceAccount 名称的 Secret 。

• 示例：

vi k8s-rbac.yaml

# 名称空间角色
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: xudaxian-role
  namespace: default # 所属的名称空间
rules: # 当前角色的规则
- apiGroups: [""] # "" 标明 core API 组，默认留空即可。
  resources: ["pods"] # 指定能操作的资源 ，通过 kubectl api-resources 查看即可。
  # resourceNames: [""] #  指定只能操作某个名字的资源
  verbs: ["get", "watch", "list"] # 操作动作，通过 kubectl api-resources -o wide 查看即可。 
---
# 集群角色
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: xudaxian-clusterrole
rules:
- apiGroups: [""] # "" 标明 core API 组，默认留空即可。
  resources: ["namespaces"]
  verbs: ["get", "watch", "list"]
---
# ServiceAccount
apiVersion: v1
kind: ServiceAccount
metadata:
  name: xudaxian # ServiceAccount 的名称
  namespace: default
---
# 账号和角色绑定
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: xudaxian-rolebinding
  namespace: default
subjects:
- kind: ServiceAccount
  name: xudaxian # "name" 是区分大小写的
roleRef:
  kind: Role
  name: xudaxian-role
  apiGroup: rbac.authorization.k8s.io
---
# 账号和集群角色绑定
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: xudaxian-clusterrolebinding
subjects:
- kind: ServiceAccount
  name: xudaxian # "name" 是区分大小写的
  namespace: default # 如果资源是某个 namespace 下的，那么就需要设置 namespace
roleRef:
  kind: ClusterRole
  name: xudaxian-clusterrole
  apiGroup: rbac.authorization.k8s.io

kubectl apply -f k8s-rbac.yaml

温馨提示：

• ① 动态供应（NFS）、DashBoard 等底层都使用了 Role、ClusterRole、RoleBinding、ClusterRoleBinding 。
• ② 我们可以创建一个 ServiceAccount ，并将自定义的 ServiceAccount 绑定 cluster-admin （ClusterRole，Kubernetes 底层提供的），然后通过暴露的 API 进行 Kubernetes 管理平台的开发（如：Kubersphere 等）。

第四章：准入控制

4.1 概述

• 通过了前面的认证和授权之后，还需要经过准入控制通过之后，API Server 才会处理这个请求。
• 准入控制是一个可配置的控制器列表，可以通过在 API Server 上通过命令行设置选择执行哪些注入控制器。

--enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,ResourceQuota,DefaultTolerationSeconds

• 只有当所有的注入控制器都检查通过之后，API Server 才会执行该请求，否则返回拒绝。

4.2 当前可配置的 Admission Control

• AlwaysAdmit：允许所有请求。
• AlwaysDeny：禁止所有请求，一般用于测试。
• AlwaysPullImages：在启动容器之前总去下载镜像。
• DenyExecOnPrivileged：它会拦截所有想在 Privileged Container 上执行命令的请求。
• ImagePolicyWebhook：这个插件将允许后端的一个 Webhook 程序来完成 admission control 的功能。
• Service Account：实现 ServiceAccount 实现了自动化。
• SecurityContextDeny：这个插件将使用 SecurityContext 的 Pod 中的定义全部失效。
• ResourceQuota：用于资源配额管理目的，观察所有请求，确保在 namespace 上的配额不会超标。
• LimitRanger：用于资源限制管理，作用于 namespace 上，确保对 Pod 进行资源限制。
• InitialResources：为未设置资源请求与限制的 Pod，根据其镜像的历史资源的使用情况进行设置。
• NamespaceLifecycle：如果尝试在一个不存在的 namespace 中创建资源对象，则该创建请求将被拒绝。当删除一个 namespace 时，系统将会删除该 namespace 中所有对象。
• DefaultStorageClass：为了实现共享存储的动态供应，为未指定 StorageClass 或 PV 的 PVC 尝试匹配默认 StorageClass，尽可能减少用户在申请 PVC 时所需了解的后端存储细节。
• DefaultTolerationSeconds：这个插件为那些没有设置 forgiveness tolerations 并具有 notready:NoExecute 和 unreachable:NoExecute 两种taints的Pod设置默认的容忍时间，为 5min 。
• PodSecurityPolicy：这个插件用于在创建或修改 Pod 时决定是否根据 Pod 的 security context 和可用的 PodSecurityPolicy 对 Pod 的安全策略进行控制