k8s的访问控制（认证+授权+准入控制）

1. kubernetes API 访问控制

由上图来介绍一下 Kubernetes API 的请求从发起到其持久化入库的一个流程。

首先看一下请求的发起，请求的发起分为两个部分：
第一个部分是人机交互的过程。 是大家非常熟悉的用 kubectl 对 apiserver 的一个请求过程；
第二个部分是 Pod 中的业务逻辑与 apiserver 之间的交互。

当我们的 apiserver 收到请求后，就会开启访问控制流程。这里面分为三个步骤：

Authentication 认证阶段：判断请求用户是否为能够访问集群的合法用户。如果用户是个非法用户，那 apiserver 会返回一个 401 的状态码，并终止该请求；
如果用户合法的话，我们的 apiserver 会进入到访问控制的第二阶段 Authorization：鉴权阶段。在该阶段中 apiserver 会判断用户是否有权限进行请求中的操作。如果无权进行操作，apiserver 会返回 403 的状态码，并同样终止该请求；
如果用户有权进行该操作的话，访问控制会进入到第三个阶段：AdmissionControl。在该阶段中 apiserver 的 admission controller 会判断请求是否是一个安全合规的请求。如果最终验证通过的话，访问控制流程才会结束。

此时我们的请求将会转换为一个 Kubernetes objects 相应的变更请求，最终持久化到 ETCD 中。

认证（任意一种） -->授权（一般是rbac 和 node）–> 准入控制（自己选择）

2. 认证 Authentication

认证一共有8种，可以启动一种或多种认证方式，只要有一种认证方式通过，就不再对其它方式认证，通常启动X 509 Client Certs 和Service Accout Tokens两种认证方式

k8s集群有两类用户： 由k8s管理的Service Accounts 服务帐号和 Users Accounts普通账户，k8s种的帐号是形式上存在的。

默认存在的taken

访问k8s的API Server的客户端主要分为两类：

1.kubectl: 用户家目录种的.kube/config就保存了密钥相关信息，自动读取
2.pod: pod中的进程需要访问API Server。如果是人去访问或编写的脚本去访问，这类访问的帐号为：UserAccount;pod自身访问时使用的帐号时ServerAccount,生产中后者使用居多。

kubectl 向 apiserver发起的命令，采用的时http方式，其实就是对URL发起增删改查的操作。

kubectl proxy --port=8888