1、k8s集群安全-概述

概述

• k8s通过认证（Authentication）、鉴权（Authoriaztion）、准入控制（AdmissionContorl）三步来保障其安全

Authentication

• 由一到多个认证插件完成。收到请求后，API Server依次调用为其配置的认证插件来认证客户端身份，直到其中的一个插件可以识别出请求者的身份。
• 认证方式现共有8种，可以启用一种或多种认证方式，只要有一种认证方式通过，就不再进行其它方式的认证。
• 通常启用Client Certs和Service Account Tokens两种认证方式。
• 证书或token解决的是“你是谁”的问题，因为证书在生成时要指定用户名和组织，token生成的前提是有SA，SA中也有用户名

Authorization

• 由一到多个授权插件进行，负责确定那些通过认证的用户是否有权限执行其发出的资源操作请求，如创建、读取、删除或者修改指定对象等
• 授权方式现共有6种，AlwaysDeny、AlwaysAllow、ABAC、RBAC、Webhook、Node
• 默认集群强制开启RBAC(系统推荐)
• 认证授权的整个逻辑是：认证 → 得到用户名 → RBAC判断 → 是否允许

Admission Control

• 通过授权检测的用户所请求的修改相关的操作还要经由一到多个准入控制插件的遍历检测，例如是否违反系统资源限制等

用户和组

• 在Kubernetes里不存在创建用户这个说法，也就不存在用户这个资源类型，Kubernetes 不存储用户。可以理解为，Kubernetes 是“外部身份系统”模型。它认为用户管理不是它的职责。所以企业里常见的做法是接入LDAP或接入OIDC或接入企业 CA。APIServer 只负责验证签名。

用户

• 用户包含两种：UserAccount（用户账户）和 ServiceAccount（服务账户）
• 面向对象：用户账户是面向人类用户的，例如：运维、开发、管理员。 服务账户是针对运行在 pod 中的进程而言的。
• 作用范围：用户账户是集群唯一的，跨所有namespace。服务账户是 namespace 隔离的。
• 创建和管理：用户账户通常从企业认证系统（LDAP/AD）同步，生命周期长（和人的企业身份绑定）。服务账号遵循 “权限最小化”原则，为具体任务创建，生命周期短（和Pod或任务的声明周期绑定）
• 使用场景：用户账户的创建是为了让某些用户登录集群执行运维操作或者开发人员调试集群。服务账户的创建是为了Pod访问 API Server或应用程序调用集群资源（如读取 ConfigMap、操作 Pod）

组

• 用户账号的逻辑集合。Kubernetes几个内建的用于特殊目的的组：
• system:unauthenticated               未通过任何一个授权插件检验的账号会进入该组
• system:authenticated                 认证成功后的用户自动加入的一个组
• system:serviceaccounts               包含当前系统所有的Service Account对象
• system:serviceaccounts: namespace   包含指定名称空间内所有的Service Account对象

RBAC

• Role Based Access Control）：基于角色访问控制授权
• 允许管理员通过Kubernetes API动态配置授权策略。RBAC就是用户通过角色与权限进行关联；
• RBAC只有授权，没有拒绝授权，所以只需要定义允许该用户做什么即可；
• RBAC包括四种类型：Role、ClusterRole、RoleBinding、ClusterRoleBinding。

Role和ClusterRole

• Role 或 ClusterRole 只是定义一组权限规则，它并不关心用户是谁。
• Role是一系列的权限的集合，Role只能授予单个namespace中资源的访问权限。
• ClusterRole作用于集群中的所有namespace，用于编写集群中的通用规则

RoleBinding和ClusterRoleBinding

• 作用是把“某个身份”绑定到“某个权限”
• RoleBinding是将Role中定义的权限授予给用户或者用户组。它包含一个subjects列表（users，groups，service accounts），并引用该Role。
• RoleBinding对集群中单个namespace进行授权，ClusterRoleBinding对集群中所有namespace进行授权
• 编写ClusterRole，然后在不同的namaspace中使用RoleBinding来引用

证书的作用是让 APIServer 确认这个请求来自一个可信的客户端，即让APIServer信任你。当你用证书时，也就是指定了client-certificate-data、client-key-data

APIServer：
验证证书是否由 CA 签发
读取证书里的 CN
比如：
CN=ops-user
O=devops
APIServer 就认为：
用户名 = ops-user
组 = devops
然后 RBAC 开始判断。

例如：

subjects:

• kind: User
  name: ops-user

注意：
kind: User
这个 User 不是 Kubernetes 创建的资源。
只是一个字符串。
只要认证阶段识别出的 username 是：
ops-user
就能匹配上。

完整流程

当你执行 kubectl get pods 后 APIServer 做三件事：
第一步：认证（你是谁）。它会看证书、Bearer Token、OIDC、、Basic Auth（基本已废弃）这几种认证方式只要有一个认证成功即可进入授权阶段，如果成功，它会得到username: ops-user，groups: [devops]。如果失败会提示Unauthorized（未授权）
第二步：授权（你能干什么）。然后 RBAC 开始工作，查看 Role / ClusterRole、查 RoleBinding / ClusterRoleBinding，看是否允许 get pods。如果不允许会提示Forbidden（禁止）
第三步：准入控制（Admission）检查LimitRange、ResourceQuota、PSP，看该操作是否违反限制

七、为什么证书比 token 更适合人类用户？
因为：
项目 证书 ServiceAccount Token
是否过期 可控 默认短期
是否自动轮换 可配置 是
适合场景 人类 Pod
是否需要定期生成 否 是