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

rbac实验参考:https://zhuanlan.zhihu.com/p/127332919
k8s权限工具:https://github.com/sighupio/permission-manager

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐