K8S - 零基础掌握 RBAC - 命名空间安全实战

一、为什么需要 RBAC 权限管理？

真实场景
在企业级 K8S 集群中，不同团队共享同一集群，容易发生权限管理问题，例如：

测试人员误删了生产数据库。

实习生看到了财务系统的敏感配置。

核心需求

确保不同用户 只能在自己负责的「楼层」（命名空间）执行允许的「操作」（权限）。

二、RBAC 四大核心组件图解

RBAC（Role-Based Access Control）是 Kubernetes 提供的访问控制机制。
（类比办公楼的门禁系统）

三、RBAC 权限控制实战

3.1 环境准备

1.安装必要工具

确保已安装如下环境：

• Kubernetes 集群（可使用 Minikube 或 Kind 进行本地测试）
• kubectl命令行工具
• Docker（用于构建镜像）

如果还没有环境，可使用如下命令安装。

# 安装 Docker 并验证
brew install docker
docker --version          # 预期输出：Docker version 20.10.x
docker run hello-world    # 验证基础功能
# 安装 kubectl 并验证
brew install kubectl
kubectl version --client  # 预期输出：Client Version: v1.28.x
# 安装 kind 并验证
brew install kind
kind version              # 预期输出：kind v0.20.x

2.创建本地 Kubernetes 集群

# 创建本地测试集群（需提前安装 kind）
kind create cluster --name k8s-demo
kubectl cluster-info  # 确认集群状态
到此k8s 集群环境已经准备完毕。

3.2 RBAC 权限配置全流程

步骤1：建立隔离区域（创建命名空间）

# 创建开发团队专属区域
kubectl create ns dev-team

步骤2：设计权限卡（定义 Role）

创建 dev-role.yaml

使用 vim或 nano编辑文件（Windows 可用记事本）：

vim dev-role.yaml

dev-role.yaml 内容，可直接粘贴（注意 YAML 缩进必须为 2 个空格）：

# dev-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev-team  # 指定生效的命名空间
  name: developer      # 权限卡名称
rules:
- apiGroups: [""]
  resources: 
    - pods         # 可操作 Pod
    - services     # 可操作 Service
  verbs: 
    - get          # 查看详情
    - list         # 查看列表
    - create       # 创建资源
    - update       # 更新资源

禁止危险操作：故意不授予 delete权限，防止误删资源。

步骤3：发放权限卡（RoleBinding）

创建 bind-dev.yaml

vim bind-dev.yaml

bind-dev.yaml 内容，可直接粘贴使用

# bind-dev.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-access 
  namespace: dev-team
subjects:  # 发卡对象
- kind: Group
  name: frontend-team  # 绑定到前端组
  apiGroup: rbac.authorization.k8s.io
roleRef:   # 使用的权限卡
  kind: Role
  name: developer
  apiGroup: rbac.authorization.k8s.io

步骤4：应用 RBAC 配置到集群

# 应用 Role 配置
kubectl apply -f dev-role.yaml

# 应用 RoleBinding 配置
kubectl apply -f bind-dev.yaml

成功提示：

role.rbac.authorization.k8s.io/developer created
rolebinding.rbac.authorization.k8s.io/dev-access created

步骤 5：验证配置状态

检查 Role 是否创建

kubectl get role -n dev-team

应显示：

NAME        CREATED AT
developer   2023-08-01T08:00:00Z

检查 RoleBinding

kubectl describe rolebinding dev-access -n dev-team

关键信息检查：

Subjects:
  Kind  Name           Namespace
  ----  ----           ---------
  Group frontend-team
Role:
  Kind  Name       Namespace
  ----  ----       ---------
  Role  developer

3.3 实战测试技巧

技巧 1：快速创建测试用户

# 生成测试用户证书（本地开发用）
openssl genrsa -out user1.key 2048
openssl req -new -key user1.key -out user1.csr -subj "/CN=user1/O=frontend-team"

技巧 2：模拟权限验证

# 测试查看 Pod 权限（应有权限）
kubectl get pods -n dev-team --as=user1

# 测试删除 Pod 权限（应无权限）
kubectl delete pod mypod -n dev-team --as=user1

预期结果：

Error from server (Forbidden): pods "mypod" is forbidden: User "user1" cannot delete resource "pods" in API group "" in the namespace "dev-team"

四、常见问题与安全实践

4.1 高频问题解答

Q1：权限配置后不生效怎么办？

• 检查 YAML 缩进（必须 2 空格，禁用 Tab）

• 确认命名空间拼写一致

• 执行诊断命令：

kubectl auth can-i delete pods --as=user1 -n dev-team

Q2：如何批量管理用户权限？

• 组授权优先：通过 O=frontend-team绑定用户组

• 生产环境：集成 LDAP/AD 统一权限管理

4.2 必须遵守的安全原则

最小权限原则

• 新用户默认无权限，按需授予

• 禁用 * 通配符授权，避免过度开放

定期审计

• 检查所有权限绑定：

kubectl get rolebindings,clusterrolebindings -A

五、总结

5.1 核心要点

• RBAC 通过 Role + RoleBinding 实现命名空间级权限管控。
• YAML 缩进和命名空间拼写错误是常见配置陷阱。
• 组授权 + 最小权限原则是生产环境最佳实践。