1. 为什么需要精细化权限控制？
随着企业数字化转型的深入，某电商平台运维团队遇到这样的场景：开发团队A负责订单系统，开发团队B处理支付系统，双方都需要访问Kubernetes集群但必须严格隔离。曾经发生因误操作导致生产环境订单服务配置被修改的事故，凸显出权限控制的必要性。
RBAC（Role-Based Access Control）作为Kubernetes原生的权限控制方案，可以实现：
- 职责分离原则（SoD）
- 最小权限原则
- 操作审计追踪
- 多环境权限复用
2. 基础RBAC组件拆解
2.1 核心概念四象限
# 角色定义（限定在命名空间内）
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: team-a
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]
# 全局角色定义（集群级别）
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cluster-admin
rules:
- apiGroups: [""]
resources: ["*"]
verbs: ["*"]
# 用户绑定角色（命名空间范围）
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: dev-binding
namespace: team-a
subjects:
- kind: User
name: "li.lei@example.com"
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
# 组绑定全局角色
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: admin-all
subjects:
- kind: Group
name: "platform-admins"
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
2.2 权限组合实战
某金融公司的开发测试环境配置策略：
# 开发环境限定命名空间
apiVersion: v1
kind: Namespace
metadata:
name: fintech-dev
# 开发人员角色（不允许操作PVC）
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: fintech-dev
name: developer
rules:
- apiGroups: ["apps"]
resources: ["deployments", "statefulsets"]
verbs: ["*"]
- apiGroups: [""]
resources: ["services", "pods"]
verbs: ["*"]
# 数据库管理员特殊权限
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: fintech-dev
name: dba
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "list"]
- apiGroups: ["batch"]
resources: ["jobs"]
verbs: ["create", "delete"]
3. 跨租户隔离的强化策略
3.1 命名空间资源配额
apiVersion: v1
kind: ResourceQuota
metadata:
name: team-quota
namespace: team-b
spec:
hard:
requests.cpu: "8"
requests.memory: 16Gi
limits.cpu: "16"
limits.memory: 32Gi
pods: "100"
3.2 网络隔离实现
结合NetworkPolicy实现服务网格隔离：
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: tenant-isolation
namespace: team-a
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
ingress:
- from:
- podSelector: {}
- namespaceSelector:
matchLabels:
tenant: team-a
egress:
- to:
- podSelector: {}
- namespaceSelector:
matchLabels:
tenant: team-a
4. 复杂场景下的权限设计
4.1 跨命名空间访问控制
审批系统访问日志服务的特殊授权：
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: log-center
name: log-reader
rules:
- apiGroups: [""]
resources: ["pods/log"]
verbs: ["get", "list"]
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: cross-ns-log
namespace: log-center
subjects:
- kind: ServiceAccount
name: approval-system
namespace: approval-prod
roleRef:
kind: Role
name: log-reader
apiGroup: rbac.authorization.k8s.io
4.2 动态准入控制
使用ValidatingWebhook实现自定义规则：
// 校验Deployment副本数上限
func validateDeployment(req *v1.AdmissionRequest) (*v1.AdmissionResponse, error) {
if req.Resource.Resource == "deployments" {
var deployment appsv1.Deployment
if err := json.Unmarshal(req.Object.Raw, &deployment); err != nil {
return nil, err
}
if *deployment.Spec.Replicas > 10 {
return &v1.AdmissionResponse{
Allowed: false,
Result: &metav1.Status{
Message: "Maximum replicas exceeded (max 10)",
},
}, nil
}
}
return &v1.AdmissionResponse{Allowed: true}, nil
}
5. 技术方案对比分析
5.1 RBAC vs ABAC
优势对比：
- RBAC策略可视化程度高
- 角色变更影响范围明确
- 与组织架构天然契合
5.2 多租户方案选型
不同场景下的选择：
- 命名空间隔离：适合中小型团队
- 虚拟集群方案：适合大型企业
- 服务网格隔离：微服务架构首选
6. 落地实践注意事项
- 定期执行权限审计
kubectl get rolebindings,clusterrolebindings --all-namespaces -o json | jq '.items[] | select(.subjects[].name=="test-user")'
- 服务账户的token管理
# 定期轮换Secret
apiVersion: v1
kind: Secret
metadata:
name: sa-token-refresh
annotations:
kubernetes.io/service-account.name: "critical-system"
type: kubernetes.io/service-account-token
7. 应用场景全景图
典型应用案例：
- 金融行业：满足合规审计要求
- SaaS平台：实现客户环境隔离
- 研发效能：多项目并行开发
- 运维安全：分级访问控制
8. 方案优势与局限性
技术优势：
- 细粒度访问控制（可达具体资源实例）
- 策略组合灵活（角色继承机制）
- 审计追踪完备（与kube-audit集成）
现存挑战：
- 大规模环境管理复杂度高
- 跨集群策略同步问题
- 历史权限回收不及时
9. 实施路线建议
阶段推进策略：
- 环境分区（开发/测试/生产）
- 角色矩阵设计（岗位映射）
- 自动化策略生成（GitOps实现）
- 持续监控优化（Prometheus指标）
10. 总结与展望
随着Open Policy Agent（OPA）等新技术的普及，RBAC将与策略即代码理念深度融合。建议结合Kubernetes审计日志和可视化工具（如Kubecost Permissions Dashboard）构建完整的安全防护体系，最终实现"权限可视、变更可控、风险可知"的多租户治理目标。
Comments