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