Kubernetes 访问控制体系

API Server及其各客户端的通信模型

API Server是Kubernetes集群的网关，是能够与etcd通信唯一入口
    #kube-controller-manager、kube-scheduler、 kubelet、 kube-proxy，以及后续部署的集群插件CoreDNS、Projet Calico等，彼此间互不通信，彼此间的所有协作均经由APIServer的RES STAPI进行，它们都是APIServer的客户
    #确保对API服务器的安全访问至关重要
        客户端对API Server的访问应经过身份验证及权限检查:
        为防止中间人攻击，各类客户端与APIServer间的通信都应使用TLS进行加密

各kubelet也会监听一些套接字，提供一个小型的REST API
    #10250是具有所在节点上Pod管理权限的读写端口，应谨慎管理
    #10255仅提供只读操作，是REST API的子集
    #10248是本地healthz端点使用的端口

API Server内置了一个有着三级别的访问控制机制-3A

API Server内置了一个有着三级别的访问控制机制-3A
    #认证: 核验请求者身份的合法性。Authentication
    #授权: 核验请求的操作是否获得许可。Authorization
    #准入控制: 检查操作内容是否合规(资源配置的合规性，操作内容是否合规)。 Admission Control

插件化机制，每种访问控制机制有一组专用的插件栈
    #认证:身份核验过程遵循“或”逻辑，且任何一个插件核验成功后都将不再进行后续的插件验证
        均不成功，则失败，或以“匿名者”身份访问
        建议禁用“匿名者
    #授权:鉴权过程遵循“或”逻辑，且任何一个插供对操作的许可授权后都将不再进行后续的插件验证
        均未许可，则拒绝请求的操作
    #准入控制:内容合规性检查过程遵循“与”逻辑，且无论成败，每次的操作请求都要经由所有插件的检验
        将数据写入etcd前，负责检查内容的有效性，因此仅对“写”操作有效分
        两类: validating (校验) 和 mutating (补全或订正)