kubernetes&&基础学习6
安全
机制说明
kubernetes作为一个分布式集群的管理工具，保证集群的安全性是其一个重要的任务。
API Server是集群内部各个组件通信的中介，也是外部控制的入口，所以kubernetes的安全机制基本就是围绕保护API Server 来设计的。
kubernetes使用了认证、鉴权、准入控制三步来保证API Server的安全
认证（Authentication）
-
HTTP Token认证： 通过一个Token来识别合法用户
HTTP Token的认证是用一个很长的特殊编码方式的并且难以被模仿的字串-Token来表达客户的一种方式。Token是一个很长又很复杂的字符串，每一个Token对应一个用户名存储在API Server能访问的文件中。当客户端发起API调用请求时，需要在HTTP Header里放入Token -
HTTP Base认证 ： 通过用户名 + 密码 的方式认证
用户名 + ： + 密码 用BASE64算法进行编码后的字符串放在HTTP Request 中的 Heather Authorization域里发送给服务器端，服务器端接收到后进行解码，获取其用户名和密码 -
最严格的HTTPS证书认证 ： 基于CA根证书签名的客户端身份认证方式
鉴权
Authorization
上面认证过程，只是确认通信的双方都确认了对方是可信的，可以相互通信。
而鉴权是确定请求方有哪些资源的权限。
API Server目前支持以下几种授权策略（通过API Server的启动参数“–authorization-mode”设置）：
- AlwaysDeny : 表示拒绝所有的请求，一般用于测试
- AlwaysAllow : 允许接收所有的请求，如果集群不需要授权流程，则可以采用该策略
- ABAC (Attribute-Based Access Control)：基于属性的访问控制，表示使用用户配置的授权规则对用户请求进行匹配和控制
- Webbook : 通过调用外部REST服务对用户进行授权
- RBAC(Role-Based Access Control) : 基于角色的访问控制，现行默认规则
RBAC授权模式
RBAC(Role-Based Access Control)基于角色的访问控制，在kubernetes1.5中引入，现行版本成为默认标准。相对其他访问控制方式，具备以下优势：
- 对集群中的资源和非资源均拥有完整的覆盖
- 整个RBAC完全由几个API对象完成，同其他API对象一样，可以用kubectl或API进行操作
- 可以在运行时进行调整，无需重启API Server
RBAC的API资源对象说明
Role and ClusterRole
RoleBinding和ClusterRoleBinding
Resources
to Subjects
实践：创建一个用户只能管理dev空间
提前创建用户devuser并设置密码，此时devuser没有权限执行kubectl get pod
准入控制
