Kubernetes系统安全
作者：尹正杰
版权声明：原创作品，谢绝转载！否则将追究法律责任。
一.Kubernetes 系统安全概述
1>.Kubernetes API Server的访问控制(Controlling Access)概述
用户可以使用kubectl、客户端库或通过发出REST请求来访问API。 人工用户和Kubernetes服务帐户都可以被授权访问API。 当一个请求到达API时，API Server将通过认证(Authentication)，授权策略(authorization policy)，准入控制(admission control)三类插件来分别实现访问控制,如下图所示。 认证(Authentication):
验证客户端是否是API Server所认可的访问者。即需要账号密码登录。 授权策略(authorization policy)：
通过认证后,需要基于资源的管理逻辑实现权限分配，说白了就是不同的用户登录拥有的权限是不同的。 准入控制(admission control):
功能一是检查客户端定义的资源是否合乎规范，如果合乎规范则按照客户端定义的规则执行，如果不合乎规范，例如缺少字段设置，则会自动补全字段的默认值。
功能二是验证用户的合法性，即检查用户的行为是否合法，默认值补全，比如经历过认证和授权策略可能客户端已经有创建Pod的权限，准入控制可以限制该客户端可以创建的Pod所申请的资源限制，比如CPU,内存，磁盘使用空间等。
2>.Kubernetes 认证(Authentication)
在典型的Kubernetes集群中，端口443上的API服务器。API服务器提供一个证书。一旦建立了TLS，HTTP请求就移动到身份验证步骤。 群集创建脚本或群集管理将API服务器配置为运行一个或多个身份验证器模型。 身份验证步骤的输入是整个HTTP请求，但是，它通常只检查头和/或客户端证书。
身份验证模块包括客户端证书(Client Certificates)、密码(Password)和普通令牌(Plain Tokens)、引导令牌(Bootstrap Tokens)和JWT令牌（用于服务帐户）。
可以指定多个身份验证模块，在这种情况下，依次尝试每个模块，直到其中一个成功为止。
如果请求无法通过身份验证，则会使用HTTP状态代码401拒绝该请求。
否则，用户将作为特定用户名进行身份验证，该用户名可供后续步骤在其决策中使用。
一些身份验证器还提供用户的组成员身份，而其他身份验证器则不提供。
3>.Kubernetes 授权策略(authorization policy)
紧随认证环节之后的是"授权"检查环境;一个常规请求必须在其请求报文中包含用户名,请求的动作以及目标对象;若存在某授权策略对于此请求给予了许可授权，即授权成功。
Kubernetes授权要求使用通用REST属性与现有的组织范围或云提供商范围的访问控制系统进行交互。
Kubernetes支持多种授权模块，如ABAC模式、RBAC模式和Webhook模式，当管理员创建集群时，他们配置了应该在API服务器中使用的授权模块。
如果配置了多个授权模块，Kubernetes将检查每个模块，如果有任何模块授权请求，则可以继续请求，如果所有模块拒绝请求，则拒绝请求（HTTP状态代码403）。
4>.Kubernetes 准入控制(admission control)
二.
三.