k8s集群安全机制理解

K8S的安全机制主要围绕着API Server设计。使用了认证（Authentication）、鉴权（Authorization）、准入控制（Admission Control）来保证API Server安全。
请求流程图：USER—>Authentication —> Authorization —> Admission Control—> K8S Resource

一、认证（Authentication）：

首先通过认证确认身份，才允许互相通信。
认证支持三种类型，不过咱们通常用CA进行认证，毕竟安全性高

• HTTP Token认证（单向认证）
• HTTP Base认证：用户名密码（单向认证）
• HTTPS证书认证：基于CA双向认证（最安全）

1、组件与ApiServer通信两种类型

1. Controller Manager和Scheduler因为在本机，通常不需要CA
2. kubectl、kubelet、kube-proxy访问API Server需要CA证书进行HTTPS

2、Pod与API Server交互之ServiceAccount

Pod中的容器访问API Server。因为Pod的特性，重建、销毁，所以不采用CA（CA通信成本略高），通过SA方式与API Server交互。
K8S的Secret分为两类，

1. 用于SA的token、ca.crt、namespace
2. 用户自定义加密信息

认证（Authentication）小结：

k8s组件与API Server交互方式使用了CA的HTTPS通信
Pod中容器与API Server交互方式通过SA访问

二、鉴权（Authorization）

基于角色的访问控制（RBAC模式）
RBAC引入4个顶级资源对象，Role、ClusterRole、RoleBinding、ClusterRoleBinding，均可通过kubectl、API操作。

1. Role 作用于某个Namespace。
2. ClusterRole 作用于整个集群。
3. RoleBinding是将Role中定义的权限赋予subjects (users, groups, or service accounts),。一个RoleBinding可以应用同一Namespace下的Role。同时RoleBinding 可以引用 ClusterRole，对 ClusterRole 所定义的、位于 RoleBinding 命名空间内的资源授权。 管理员可以在集群定义一组通用Role，然后在多个Namespace中使用。
4. ClusterRoleBinding 可用来在集群级别或对所有命名空间执行授权。

注：定义user和group时不能使用system:开头，为K8S集群保留的。SA的用户名前缀为system:serviceaccount:， 属于前缀为 system:serviceaccounts: 的用户组。

• API servers创建一组默认为 ClusterRole 和 ClusterRoleBinding 的对象。以 system: 为前缀所属基础设施“owned” ，对于这些资源的修改可能导致集群功能失效。所有默认的 ClusterRole 和 ClusterRoleBinding 对象都会被标记为 kubernetes.io/bootstrapping=rbac-defaults。
  通过命令查看是否属于默认对象：kubectl describe ClusterRole system:node
• 在1.6+版本后默认开启自动更新功能，即在每次启动时，API Server 都会更新默认 ClusterRole 所缺少的各种权限，同时可以保证升级K8S版本带来的权限和RoleBinding变化。

参考官网：https://kubernetes.io/zh/docs/reference/access-authn-authz/rbac/

三、准入控制（Admission Controllers）

准入控制是API Serveer的插件集合，通过添加不同插件，实现额外的准入控制。比如SA也是通过Admission Controllers实现的。列举几个插件功能便于理解：

• LimitRanger：确保请求的资源不会超过Namespace的LimitRange限制。
• NamespaceLifecycle：删除 Namespace 时删除所有对象（ pod 、 services 等）。强制不能在一个正在被终止的 Namespace 中创建新对象，和确保使用不存在 Namespace 的请求被拒绝。
• ServiceAccount：实现了 serviceAccounts 的自动化。
• ResourceQuota：确保请求不会超过 Namespace 中的 ResourceQuota 对象限制。
• PodSecurityPolicy：确保在创建和修改 pod 时根据请求的安全上下文和可用的 pod 安全策略确定是否应该通过 pod。

参考官网：https://kubernetes.io/zh/docs/reference/access-authn-authz/admission-controllers/
https://www.jianshu.com/p/f77d5d0df58b