K8s 访问控制
整体总流程（访问 API 服务器三关安检）
任何人 / 程序想要操作 K8s 集群，必须依次过完三道关卡：
- Authentication 认证：验身份（你是谁）
- Authorization 授权：查权限（你能干啥）
- Admission Control 准入控制（你行为安全合法吗）：
PSA（Pod 安全准入）：禁止你搞危险操作
NetworkPolicy 网络策略：防火墙
一、ServiceAccount（SA 服务账户）
通俗解释
- 普通用户（管理员、开发）：用证书 / 账号密码登录集群
- SA 是专门给 Pod 容器内部程序用的"身份证"，存储在Namespace中，用于给API server验证
容器里的服务需要调用 K8s 接口（比如查询 Pod、更新部署）时，就靠 SA 证明自己身份。
核心特点
- 每新建一个命名空间，K8s 会自动生成一个名叫default的默认 SA；
- Pod 启动后，系统会自动把 SA 的身份令牌、证书挂载进容器固定目录里，程序直接读取就能完成身份认证；
- 生产规范：不共用默认 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）
- Role 和 ClusterRole 区别对照表
表格
| 类型 | 生效范围 | 管控资源 | 使用场景 |
|---|---|---|---|
| Role | 单个命名空间内 | 仅当前命名空间的 Pod、Service 等资源 | 给开发分配某个测试环境的权限 |
| ClusterRole | 整个集群全局 | 集群所有节点、所有命名空间资源 | 运维管理员，管理整套集群 |
- RoleBinding / ClusterRoleBinding
作用：把「角色权限」绑定给用户、SA、用户组，让身份拥有对应权限
- RoleBinding：仅限单个命名空间绑定
- ClusterRoleBinding：全集群生效
实操案例
案例 1：命名空间内权限（只能查看 Pod）
- 创建 Role：定义权限（可以查看、列出、监控 Pod，不能创建删除）
- 创建 RoleBinding：把这个查看权限绑定给刚才创建的 SA
- 权限校验：
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）
- 创建 ClusterRole：全局管理权限
- ClusterRoleBinding：全局绑定给 SA
- 校验：全集群都能操作 Pod、部署，无法操作密钥等未授权资源
三、PSA Pod 安全准入（Pod Security Admission）
（给Namespace打标签标注其安全等级）
执行 kubectl apply 创建 / 修改 Pod 的时候，PSA 就是集群大门口的安检员。
Pod 提交到 API Server 之后，正式创建运行之前，安检员会检查这个 Pod 权限是否超标、有没有安全隐患；
K8s1.25 之后废弃了老旧的 PSP，改用 PSA，给命名空间打标签管控 Pod 安全级别
三大安全等级（从松到严）
- Privileged 特权级（最宽松）
无任何限制；容器可以开特权、访问主机硬件、主机网络，风险最高，测试环境偶尔用。
- Baseline 基线级
屏蔽大部分高危操作，杜绝明显安全漏洞，线上业务最常用。
- Restricted 受限级（最严格）
强制普通用户运行容器、禁止特权、禁止提权，安全等级最高。
三种执行模式
- enforce强制执行：违规 Pod 直接创建失败
- warn警告：可以创建，但弹出风险提醒
- audit审计：允许创建，只记录违规日志，不拦截
实操示例
给命名空间打上强制受限标签，尝试创建特权 Pod 会直接报错创建失败。
四、NetworkPolicy 网络隔离策略（Pod 之间防火墙）
NetworkPolicy 就是K8s 集群内部的防火墙
用来管控 Pod 之间、外部和 Pod 之间能不能互相访问，允许谁进、禁止谁来往。
默认情况：
K8s 集群默认是扁平网络：所有 Pod 之间随便互相访问
弊端：前端服务被黑客攻破后，能直接打通后端数据库，安全隐患极大。
NetworkPolicy 作用
给 Pod 配置网络防火墙规则：
- 一旦 Pod 被 NetworkPolicy 选中，立刻进入默认拒绝所有访问状态；
- 只有规则里明确放行的流量，才可以互通。
通俗场景举例
- 数据库 Pod 只允许前端 Web Pod 访问；
- 其他 Pod、外部流量一律无法连接数据库；
就算前端沦陷，攻击者也访问不到数据库。
实验流程
- 新建两个命名空间：存放数据库、存放前端应用
- 分别部署数据库 Pod、前端 Pod
- 编写 NetworkPolicy：仅放行前端命名空间访问数据库 80 端口
- 验证：
✅ 前端可以正常连通数据库
❌ 其他命名空间的 Pod 无法访问数据库