基于角色的权限设计？

作为AI基础设施的关键组成部分，模型部署环境（如Kubernetes集群）的安全性至关重要。一个常见的安全漏洞是权限过度授予，使得攻击者或意外操作者能够访问、修改甚至删除敏感的模型配置或生产Pod。基于角色的权限控制（RBAC）是解决这一问题的核心机制。

我们将聚焦于如何利用Kubernetes的原生RBAC机制，为AI模型部署流水线或服务账号（ServiceAccount）设置精确的、最小化权限，确保其只能执行部署和状态监控所需的操作，而不能执行破坏性操作。

一、为什么AI部署需要最小权限RBAC？

在典型的模型服务架构中，模型制品、高性能推理配置（如GPU分配、Batching参数）通常以Kubernetes Secrets或ConfigMaps的形式存储。部署流程（通常由CI/CD工具或KServe/Seldon等框架触发）需要读取这些配置。如果部署工具使用的身份拥有集群管理员权限，一旦该身份泄露，整个生产环境将面临风险。

通过RBAC，我们可以精确定义：
1. 谁（Subject，例如ServiceAccount）
2. 能做什么（Verb，例如get/list/create）
3. 在什么资源上（Resource，例如pods/secrets/deployments）
4. 在哪个范围（Scope，例如Namespace或Cluster）

二、实操示例：创建模型只读部署者

假设我们有一个名为 ai-serving-prod 的命名空间，我们的目标是创建一个专用的服务账号，它只能查看（get, list）该命名空间下的所有 Pods 和 Secrets，但绝不能删除或创建新的资源。

步骤 1: 创建专用的服务账号 (ServiceAccount)

服务账号是供进程或应用在集群内部使用的身份标识。

# filename: 1-serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: model-reader-sa
  namespace: ai-serving-prod

kubectl apply -f 1-serviceaccount.yaml

步骤 2: 定义最小权限角色 (Role)

我们将定义一个名为 model-status-viewer 的角色。它只允许对核心资源进行只读操作。

# filename: 2-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: model-status-viewer
  namespace: ai-serving-prod
rules:
# 允许查看Pod和ConfigMap状态，获取模型配置
- apiGroups: [""]
  resources: ["pods", "configmaps", "secrets"]
  verbs: ["get", "list", "watch"]
# 允许查看Deployment状态
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list"]

核心点: 注意 verbs 中缺少了 create, update, delete，这确保了身份是只读的。

kubectl apply -f 2-role.yaml

步骤 3: 绑定服务账号与角色 (RoleBinding)

RoleBinding 是将 Subject（服务账号）和 Role（权限集合）连接起来的关键步骤。

# filename: 3-rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: model-reader-binding
  namespace: ai-serving-prod
subjects:
- kind: ServiceAccount
  name: model-reader-sa
  namespace: ai-serving-prod
roleRef:
  kind: Role
  name: model-status-viewer
  apiGroup: rbac.authorization.k8s.io

kubectl apply -f 3-rolebinding.yaml

三、验证权限边界

要验证这个最小权限配置是否有效，我们可以启动一个使用该服务账号的Pod，并在其中执行kubectl命令。

1. 尝试只读操作 (成功):

   在 Pod 内使用该 ServiceAccount 时，执行 kubectl get pods 将会成功。

2. 尝试破坏性操作 (失败):

   在 Pod 内执行 kubectl delete pod 将会返回 Error from server (Forbidden)。这是因为该身份没有被授予 delete 动词的权限，成功实现了最小权限原则。

总结

Kubernetes RBAC是构建安全AI基础设施的基石。通过为每个模型服务、CI/CD流水线、或监控代理分配精确定义权限的 ServiceAccount 和 Role，我们能够有效地实施最小权限原则，显著降低生产环境中因误操作或攻击导致的风险。在更复杂的场景中，可以使用 ClusterRole 和 ClusterRoleBinding 来管理跨命名空间的权限，例如，允许全局监控系统查看所有AI服务的健康状况。