3. 认证

# 一、认证
1. 认证方式
- HTTP Token 认证：用一个很长的特殊编码方式的并且难以被模仿的字符串 - Token来表达客户的一种方式。Token 是一个很长的很复杂的字符串，每一个 Token对应一个用户名存储在 API Server 能访问的文件中。当客户端发起 API调用请求时，需要在 HTTP Header 里放入 Token
- HTTP Base 认证：用户名+密码用 BASE64 算法进行编码后的字符串放在 HTTP Request中的 HeatherAuthorization域里发送给服务端，服务端收到后进行编码，获取用户名及密码
- HTTPS 证书认证：基于 CA 根证书签名的客户端身份认证方式

![未命名图片.png](/media/202406/11.3.15282731_image1.png)

2. 安全性说明
- Controller Manager、Scheduler 与 API Server 在同一台机器，所以直接使用 API Server 的非安全端口访问，--insecure-bind-address=127.0.0.1
- kubectl、kubelet、kube-proxy 访问 API Server 就都需要证书进行 HTTPS 双向认证

# 二、HTTPS认证

1. 证书颁发
- 手动签发：通过 k8s 集群的跟 ca 进行签发 HTTPS 证书
- 自动签发：kubelet 首次访问 API Server 时，使用 token做认证，通过后，Controller Manager 会为kubelet生成一个证书，以后的访问都是用证书做认证了

# 三、kubeconfig

1. kubeconfig 文件包含集群参数（CA证书、API Server地址），客户端参数（上面生成的证书和私钥），集群context 信息（集群名称、用户名）。Kubenetes 组件通过启动时指定不同的 kubeconfig文件可以切换到不同的集群。

![未命名图片.png](/media/202406/11.3.15282731_image2.png)

2. 查看kubeconfig文件内容

![未命名图片.png](/media/202406/11.3.15282731_image3.png)

- clusters：集群列表，包含访问API Server的URL和所属集群的名称等。
- users：用户列表，包含访问API Server时的用户名和认证信息。
- contexts：kubelet的可用上下文列表，由用户列表中的某特定用户名称和集群列表中的某特定集群名称组合而成。
- current-context：kubelet当前使用的上下文名称，即上下文列表中的某个特定项。
3. kubectlconfig命令的常用操作
- kubectl config view：打印kubeconfig文件内容。
- kubectl config set-cluster：设置kubeconfig的clusters配置段。
- kubectl config set-credentials：设置kubeconfig的users配置段。
- kubectl config set-context：设置kubeconfig的contexts配置段。
- kubectl config use-context：设置kubeconfig的current-context配置段。

# 四、TLS bootstrapping机制

1. 新的工作节点接入集群时，由kubelet自行生成私钥和证书签署请求，而后发送给集群上的证书签署进程（CA），由管理员验证请求后予以签署或直接控制器进程自动统一签署。这种方式即为Kubelet TLS Bootstrapping机制。

# 五、总结

![未命名图片.png](/media/202406/11.3.15282731_image4.png)