k8s集群安全机制理解
一、认证(Authentication):HTTP Token认证(单向认证)HTTP Base认证:用户名密码(单向认证)HTTPS证书认证:基于CA双向认证(最安全,最佳)一、组件与ApiServer通信两种类型Controller Manager和Scheduler因为在本机,通常不需要CAkubectl、kubelet、kube-proxy访问API Server需要CA证书...
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通信两种类型
- Controller Manager和Scheduler因为在本机,通常不需要CA
- kubectl、kubelet、kube-proxy访问API Server需要CA证书进行HTTPS
2、Pod与API Server交互之ServiceAccount
Pod中的容器访问API Server。因为Pod的特性,重建、销毁,所以不采用CA(CA通信成本略高),通过SA方式与API Server交互。
K8S的Secret分为两类,
- 用于SA的token、ca.crt、namespace
- 用户自定义加密信息
认证(Authentication)小结:
k8s组件与API Server交互方式使用了CA的HTTPS通信
Pod中容器与API Server交互方式通过SA访问
二、鉴权(Authorization)
基于角色的访问控制(RBAC模式)
RBAC引入4个顶级资源对象,Role、ClusterRole、RoleBinding、ClusterRoleBinding,均可通过kubectl、API操作。
- Role 作用于某个Namespace。
- ClusterRole 作用于整个集群。
- RoleBinding是将Role中定义的权限赋予subjects (users, groups, or service accounts),。一个RoleBinding可以应用同一Namespace下的Role。同时RoleBinding 可以引用 ClusterRole,对 ClusterRole 所定义的、位于 RoleBinding 命名空间内的资源授权。 管理员可以在集群定义一组通用Role,然后在多个Namespace中使用。
- 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
更多推荐
所有评论(0)