安全机制
|-----------------------------------------------------------------------------------------------------|
| k8s的安全机制，分布式集群管理工具，就是容器编排，安全机制的核心就是围绕API SERVER ，作为整个集群内部通信的中介，也是外部控制的入口，所有的安全机制都是围绕api server来进行设计 |
请求api资源需要过三关
|----------------------------------------|
| 1.认证 2.鉴权 3.准入机制 三个条件都通过，才可以在k8s集群当中创建 |
认证
|---------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Anthentcation | HTTP 通过token识别合法用户，token是一个很长，很复杂的一个字符串，字符串是用来表达客户的一种方式，而每一个token都对应一个用户名，用户名存储在apiserver能够访问的文件中，当客户端发起请求时，http headr包含token。 流程：客户端发起请求到-token-apiserver(用户存储文件)-解码-用户名-访问集群 |
| http base | 用户+密码的验证方式，用户名和密码都是通过base64进行加密，加密完成的字符串，http requset的header Atuthorization发送给服务端，服务端会收到加密的字符串，解码，之后获取用户名和密码 |
| https证书 | 最严格的方式，也是最严谨的方式，基于CA根证书签名的客户端身份进行验证 |
认证的访问类型
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| k8s的组件对api server的访问 如kubelet，kube-proxy pod对apiserver的访问 如pod coredns，dashborad都是pod，也需要访问api 客户端和kubectl |
| Kubelet kube-proxy： Controller manager sheduler 与api server在一台服务器，可以直接使用api server的非安全端口访问有可能是（8080） Kubectl和kubelet和kube-proxy都是通过api server的https证书进行双向验证，都是用6443端口进行验证 |
签发证书
|----------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 手动签发 | 二进制部署就是手动签发，CA签发就是把证书匹配到每个对应组件，然后访问6443即可 |
| 自动签发 | kubeadm，kubelet第一次要访问api server使用的是token，token通过之后，comtroller manager 会为kubelet生成一个证书，以后都是通过证书访问，kubeadm修改了证书的有效期，默认是1年 |
| Kubeconfig | 文件包含了集群的参数，CA证书，API server地址，客户端的参数（客户端的整数和私钥），以及集群的名称和用户名，k8s组件都是通过启动时制定访问不同的kubeconfig文件切换到不同的集群，再到api server--namespace再到资源对象，pod，容器，kubeconfig既是集群的描述文件，也是一个集群信息的保存文件，包含了集群的访问方式和他的认证信息，一般都在家目录下（隐藏文件）.kube/config保存的是kubectl的访问认证信息 |
| ServiceAccount | 就是为了方便pod中的容器来访问API server，pod的动作（增删改查），动态的，每个pod手动生成一个证书就不现实了，于是k8s使用了service Account来循环认证，包含了统一的认证信息，直接进行api server访问 |
| Secret | 保存资源对象，aserviceAccount内部，保存的token service-account-token，secret保存的是自定义的保密信息 |
| ServiceAccount | 1.Token 2.Ca.crt 3.Namespace 都会被自动挂载到pod当中 |
鉴权
|-------------|--------------------------------------------------------|
| 鉴权 | 之前的认证过程，只是确认了双方都是可信的，可以互相通信的，鉴权是为了确定请求方的访问权限，能做哪些指定的操作 |
| AlwaysDeny | 拒绝所有，一般是测试 |
| AlwaysAllow | 允许所有，一般也是测试 |
| ABAC | attribute-based access control 基于属性的访问控制 |
| Webhook | 集群外部访问集群内部的鉴权方式 |
| RBAC | role-base access control 基于角色的访问控制，也是k8s现在默认的规则机制 |
角色
|--------------------|-------------------|
| | 角色 |
| role | 指定命名空间的资源控制权限 |
| rolebinding | 将角色绑定到指定的命名空间 |
| | 集群 |
| Clusterrole | 可以授权所有命名空间的资源控制权限 |
| clusterrolebinding | 将集群的角色绑定到命名空间 |
准入控制
|-------------------------------------------------------------------------------------------------------------------------------------|
| 准入控制是API server的一个准入控制器的插件列表，不同的插件可以实现不同的准入控制机制，一般情况下建议使用官方默认的准入控制器 Limitranger：配置命名空间的配额管理 ServiceACCount： ResourceQuota：命名空间的配置限制 |