Kubernetes系统安全

　　用户可以使用kubectl、客户端库或通过发出REST请求来访问API。

　　人工用户和Kubernetes服务帐户都可以被授权访问API。

　　当一个请求到达API时，API Server将通过认证(Authentication)，授权策略(authorization policy)，准入控制(admission control)三类插件来分别实现访问控制,如下图所示。
　　　　认证(Authentication):
　　　　　　验证客户端是否是API Server所认可的访问者。即需要账号密码登录。
　　　　
　　　　授权策略(authorization policy)：
　　　　　　通过认证后,需要基于资源的管理逻辑实现权限分配，说白了就是不同的用户登录拥有的权限是不同的。

　　　　准入控制(admission control):
　　　　　　功能一是检查客户端定义的资源是否合乎规范，如果合乎规范则按照客户端定义的规则执行，如果不合乎规范，例如缺少字段设置，则会自动补全字段的默认值。
　　　　　　功能二是验证用户的合法性，即检查用户的行为是否合法，默认值补全，比如经历过认证和授权策略可能客户端已经有创建Pod的权限，准入控制可以限制该客户端可以创建的Pod所申请的资源限制，比如CPU,内存，磁盘使用空间等。

　　在典型的Kubernetes集群中，端口443上的API服务器。API服务器提供一个证书。一旦建立了TLS，HTTP请求就移动到身份验证步骤。

　　群集创建脚本或群集管理将API服务器配置为运行一个或多个身份验证器模型。

　　身份验证步骤的输入是整个HTTP请求，但是，它通常只检查头和/或客户端证书。
　　　　身份验证模块包括客户端证书(Client Certificates)、密码(Password)和普通令牌(Plain Tokens)、引导令牌(Bootstrap Tokens)和JWT令牌（用于服务帐户）。
　　　　可以指定多个身份验证模块，在这种情况下，依次尝试每个模块，直到其中一个成功为止。
　　　　如果请求无法通过身份验证，则会使用HTTP状态代码401拒绝该请求。
　　　　否则，用户将作为特定用户名进行身份验证，该用户名可供后续步骤在其决策中使用。
　　　　一些身份验证器还提供用户的组成员身份，而其他身份验证器则不提供。

　　紧随认证环节之后的是"授权"检查环境;一个常规请求必须在其请求报文中包含用户名,请求的动作以及目标对象;若存在某授权策略对于此请求给予了许可授权，即授权成功。

　　Kubernetes授权要求使用通用REST属性与现有的组织范围或云提供商范围的访问控制系统进行交互。

　　Kubernetes支持多种授权模块，如ABAC模式、RBAC模式和Webhook模式，当管理员创建集群时，他们配置了应该在API服务器中使用的授权模块。
　　　　如果配置了多个授权模块，Kubernetes将检查每个模块，如果有任何模块授权请求，则可以继续请求，如果所有模块拒绝请求，则拒绝请求（HTTP状态代码403）。

　　一个API请求要么以常规用户的身份进行,要么以某特定账号的身份进行，否则统一被视作匿名用户。换句话说，所有Kubernetes集群都有两类用户：由Kubernetes管理的服务帐户和普通(常规)用户。
　　　　普通(常规)用户(有权限操作集群的用户):
　　　　　　常规用户被认为是由外部的独立服务管理的。
　　　　　　一个分发私钥的管理员，一个类似Keystone或Google帐户的用户存储，甚至一个包含用户名和密码列表的文件。
　　　　　　在这方面，Kubernetes没有表示普通用户帐户的对象，普通用户不能通过API调用添加到集群中。
　　　　服务账号(Service Account):
　　　　　　服务帐户是由Kubernetes API管理的用户。
　　　　　　它们绑定到特定的名称空间，并由API服务器自动创建或通过API调用手动创建。
　　　　　　服务帐户绑定到存储为secert的一组凭据，这些凭据被装载到pods中，允许集群中的进程与Kubernetes API进行对话。

　　无论来自于Kubernetes集群内或集群外的任何进程的请求，都必须由API Server事先完成认证；常见的客户端进程包括:
　　　　(1)kube-scheduler
　　　　(2)kube-controller-manager
　　　　(3)kubectl
　　　　(4)kubelet
　　　　(5)kub-proxy
　　　　(6)Dashboard
　　　　(7)CoreDNS
　　　　(8)flannel

　　集群上运行于Pod中的进程认证时使用的账号即Service Account。