共计 1702 个字符，预计需要花费 5 分钟才能阅读完成。
机制阐明
Kubernetes 作为一个分布式集群的管理工具，保障集群的安全性是其一个重要的工作。API Server 是集群外部各个组件通信的中介，也是内部管制的入口。所以 Kubernetes 的平安机制根本就是围绕爱护 API Server 来设计的。Kubernetes 应用了认证（Authentication）、鉴权（Authorization）、准入管制（AdmissionControl）三步来保障 API Server 的平安
Authentication
-
HTTP Token 认证：通过一个 Token 来辨认非法用户
- HTTP Token 的认证是用一个很长的非凡编码方式的并且难以被模拟的字符串 - Token 来表白客户的一种形式。Token 是一个很长的很简单的字符串，每一个 Token 对应一个用户名存储在 API Server 能拜访的文件中。当客户端发动 API 调用申请时，须要在 HTTP Header 里放入 Token
-
HTTP Base 认证：通过用户名 + 明码的形式认证
- 用户名 +：+ 明码用 BASE64 算法进行编码后的字符串放在 HTTP Request 中的 HeatherAuthorization 域里发送给服务端，服务端收到后进行编码，获取用户名及明码
- 最严格的 HTTPS 证书认证：基于 CA 根证书签名的客户端身份认证形式
Ⅰ、HTTPS 证书认证：
Ⅱ、须要认证的节点
两种类型
- Kubenetes 组件对 API Server 的拜访：kubectl、Controller Manager、Scheduler、kubelet、kube-proxy
- Kubernetes 治理的 Pod 对容器的拜访：Pod（dashborad 也是以 Pod 模式运行）
安全性阐明
- Controller Manager、Scheduler 与 API Server 在同一台机器，所以间接应用 API Server 的非平安端口拜访，–insecure-bind-address=127.0.0.1
- kubectl、kubelet、kube-proxy 拜访 API Server 就都须要证书进行 HTTPS 双向认证
证书颁发
- 手动签发：通过 k8s 集群的跟 ca 进行签发 HTTPS 证书
- 主动签发：kubelet 首次拜访 API Server 时，应用 token 做认证，通过后，Controller Manager 会为 kubelet 生成一个证书，当前的拜访都是用证书做认证了
Ⅲ、kubeconfig
kubeconfig 文件蕴含集群参数（CA 证书、API Server 地址），客户端参数（下面生成的证书和私钥），集群 context 信息（集群名称、用户名）。Kubenetes 组件通过启动时指定不同的 kubeconfig 文件能够切换到不同的集群
Ⅳ、ServiceAccount
Pod 中的容器拜访 API Server。因为 Pod 的创立、销毁是动静的，所以要为它手动生成证书就不可行了。Kubenetes 应用了 Service Account 解决 Pod 拜访 API Server 的认证问题
Ⅴ、Secret 与 SA 的关系
Kubernetes 设计了一种资源对象叫做 Secret，分为两类，一种是用于 ServiceAccount 的 service-accounttoken，另一种是用于保留用户自定义窃密信息的 Opaque。ServiceAccount 中用到蕴含三个局部：Token、ca.crt、namespace
- token 是应用 API Server 私钥签名的 JWT。用于拜访 API Server 时，Server 端认证
- ca.crt，根证书。用于 Client 端验证 API Server 发送的证书
- namespace, 标识这个 service-account-token 的作用域名空间
kubectl get secret --all-namespaces
kubectl describe secret default-token-5gm9r --namespace=kube-system默认状况下，每个 namespace 都会有一个 ServiceAccount，如果 Pod 在创立时没有指定 ServiceAccount，就会应用 Pod 所属的 namespace 的 ServiceAccount
总结
