K8s 访问控制

整体总流程（访问 API 服务器三关安检）

任何人 / 程序想要操作 K8s 集群，必须依次过完三道关卡：

1. Authentication 认证：验身份（你是谁）
2. Authorization 授权：查权限（你能干啥）
3. Admission Control 准入控制（你行为安全合法吗）：

PSA（Pod 安全准入）：禁止你搞危险操作

NetworkPolicy 网络策略：防火墙

一、ServiceAccount（SA 服务账户）

通俗解释

• 普通用户（管理员、开发）：用证书 / 账号密码登录集群
• SA 是专门给 Pod 容器内部程序用的“身份证”，存储在Namespace中，用于给API server验证

容器里的服务需要调用 K8s 接口（比如查询 Pod、更新部署）时，就靠 SA 证明自己身份。

核心特点

1. 每新建一个命名空间，K8s 会自动生成一个名叫default的默认 SA；
2. Pod 启动后，系统会自动把 SA 的身份令牌、证书挂载进容器固定目录里，程序直接读取就能完成身份认证；
3. 生产规范：不共用默认 SA，一个应用单独创建一个 SA，遵循最小权限原则，权限越小越安全。

实操命令

bash

# 创建命名空间

kubectl create namespace acctest

# 新建自定义SA

kubectl -n acctest create serviceaccount ylacct

# 查看SA

kubectl -n acctest get sa

# 查看SA详情

kubectl -n acctest describe sa ylacct

先创建命名空间（kubectl create namespace acctest）并在其内新建 SA（kubectl -n acctest create serviceaccount ylacct），Pod 清单指定绑定 SA（serviceAccountName: SA名称），Pod 运行后容器内置 SA 凭证，当pod内部程序调用API server时凭借该凭证完成身份核验，API Server 可识别 SA 归属命名空间。

二、RBAC 基于角色的权限控制（最核心权限体系）

规定「某个身份，能对哪些资源做哪些操作」

由两组搭档组成：角色（Role/ClusterRole） + 绑定（RoleBinding/ClusterRoleBinding）

1. Role 和 ClusterRole 区别对照表

表格

类型	生效范围	管控资源	使用场景
Role	单个命名空间内	仅当前命名空间的 Pod、Service 等资源	给开发分配某个测试环境的权限
ClusterRole	整个集群全局	集群所有节点、所有命名空间资源	运维管理员，管理整套集群

2. RoleBinding / ClusterRoleBinding

作用：把「角色权限」绑定给用户、SA、用户组，让身份拥有对应权限

• RoleBinding：仅限单个命名空间绑定
• ClusterRoleBinding：全集群生效

实操案例

案例 1：命名空间内权限（只能查看 Pod）

1. 创建 Role：定义权限（可以查看、列出、监控 Pod，不能创建删除）
2. 创建 RoleBinding：把这个查看权限绑定给刚才创建的 SA
3. 权限校验：

bash

# 验证能查看Pod（返回yes）

kubectl -n acctest auth can-i get pods --as=system:serviceaccount:acctest:ylacct

# 验证不能创建Pod（返回no）

kubectl -n acctest auth can-i create pods --as=system:serviceaccount:acctest:ylacct

案例 2：集群全局权限（管理全集群 Pod 和 Deployment）

1. 创建 ClusterRole：全局管理权限
2. ClusterRoleBinding：全局绑定给 SA
3. 校验：全集群都能操作 Pod、部署，无法操作密钥等未授权资源

三、PSA Pod 安全准入（Pod Security Admission）

（给Namespace打标签标注其安全等级）

执行 kubectl apply 创建 / 修改 Pod 的时候，PSA 就是集群大门口的安检员。

Pod 提交到 API Server 之后，正式创建运行之前，安检员会检查这个 Pod 权限是否超标、有没有安全隐患；

K8s1.25 之后废弃了老旧的 PSP，改用 PSA，给命名空间打标签管控 Pod 安全级别

三大安全等级（从松到严）

1. Privileged 特权级（最宽松）

无任何限制；容器可以开特权、访问主机硬件、主机网络，风险最高，测试环境偶尔用。

1. Baseline 基线级

屏蔽大部分高危操作，杜绝明显安全漏洞，线上业务最常用。

1. Restricted 受限级（最严格）

强制普通用户运行容器、禁止特权、禁止提权，安全等级最高。

三种执行模式

• enforce强制执行：违规 Pod 直接创建失败
• warn警告：可以创建，但弹出风险提醒
• audit审计：允许创建，只记录违规日志，不拦截

实操示例

给命名空间打上强制受限标签，尝试创建特权 Pod 会直接报错创建失败。

四、NetworkPolicy 网络隔离策略（Pod 之间防火墙）

NetworkPolicy 就是K8s 集群内部的防火墙

用来管控 Pod 之间、外部和 Pod 之间能不能互相访问，允许谁进、禁止谁来往。

默认情况：

K8s 集群默认是扁平网络：所有 Pod 之间随便互相访问

弊端：前端服务被黑客攻破后，能直接打通后端数据库，安全隐患极大。

NetworkPolicy 作用

给 Pod 配置网络防火墙规则：

1. 一旦 Pod 被 NetworkPolicy 选中，立刻进入默认拒绝所有访问状态；
2. 只有规则里明确放行的流量，才可以互通。

通俗场景举例

• 数据库 Pod 只允许前端 Web Pod 访问；
• 其他 Pod、外部流量一律无法连接数据库；

就算前端沦陷，攻击者也访问不到数据库。

实验流程

1. 新建两个命名空间：存放数据库、存放前端应用
2. 分别部署数据库 Pod、前端 Pod
3. 编写 NetworkPolicy：仅放行前端命名空间访问数据库 80 端口
4. 验证：

✅ 前端可以正常连通数据库

❌ 其他命名空间的 Pod 无法访问数据库