Skyportal 为共享集群中的 AI agent 设置命名空间级权限，限制其在生产环境的 kubectl 操作

开发和生产共用一个 Kubernetes 集群时，怎么限制 agent 的 kubectl 权限？

分开的 Kubernetes 环境不一定非要分开的集群。如果 dev 和 prod 在同一个 EKS 集群里作为两个 namespace 运行，费用大概是主要原因：EKS 对每个集群每小时至少收 $0.10，还没跑任何节点就开始计费，所以单为 dev 再开一个集群，光这一项每月就多出约 $73。这个取舍在你把 AI agent 接到集群上时就显现出来了。你想让它在 dev 里帮忙，又希望它离 prod 的删除操作越远越好。

在 Skyportal 里，一个已连接集群的每个 namespace 都可以有自己的环境。把 dev 标为 Dev，prod 保持 Production，Skyportal 的 agent SARA 就能在 dev 里修东西，而 prod 保持只读。针对 prod 的破坏性命令在到达集群之前就会被拒绝。你仍然只有一个集群、一个连接和一个 token，在 EKS、GKE 或 AKS 上都一样。

这建立在只读访问那篇文章的设置之上：在 skyportal namespace 里有一个叫 skyportal 的 service account，绑定到内置的 view 角色，其 token 已连接到 Skyportal。这个 token 改不了任何东西。为了让 SARA 能在 dev 里修东西，只给同一个 service account 在 dev namespace 里授予内置的 edit 角色：

kubectl create rolebinding skyportal-edit -n dev
--clusterrole=edit --serviceaccount=skyportal:skyportal

RoleBinding 只在其所属的 namespace 内生效，所以这个 token 现在可以在 dev 里改动工作负载，在 prod 里仍然只能读。token 本身没变，所以 Skyportal 里不需要更新任何东西。要记住，edit 可以读取 dev 里的 Secret，也能以该 namespace 里任意 service account 的身份运行 pod。Skyportal 从不让 allow list 批准涉及 Secret 的命令，所以这类命令每次都要单独走审批卡片。

RBAC 和 Skyportal 的环境各司其职。RBAC 决定这个 token 究竟能做什么。环境决定 SARA 可以尝试什么，以及什么时候必须先问你。两者都要保留：万一标签标错了，RBAC 仍然能拦住写入。这适用于用 token 连接的集群。通过 Skyportal 的 in-cluster agent 连接的集群会拒绝一切变更，不管标签怎么写。

在应用里，从左侧边栏的 Hosts 下找到该集群，点击它那一行的铅笔图标。Edit Host 窗口里有集群自己的 Environment 字段，下面是一个 Namespace environments 列表，每个 namespace 一行。每一行初始都是 Inherit，即跟随集群的环境。

集群保持 Production，把 dev 设为 Dev，prod 设为 Production，然后点击 Save Changes。kubeconfig 字段留空，已存储的凭据保持不变。prod 本来也会继承 Production，但有了自己的标签，它会在聊天里的 scope picker 中获得一个标记，SARA 也能在名字旁边看到环境。所有你没打标签的 namespace 都继承 Production，你之后新建的 namespace 也一样。

这个列表显示的是 Skyportal 见过 pod 的 namespace，所以一个新的空 namespace 要等有东西在里面运行后才会出现。只有集群的所有者才能修改这些标签，一个集群最多可以有 200 个标签。这些标签在 web 应用里设置：从 CLI 上，skyportalai kubernetes connect --environment 只设置集群自己的环境。

每个环境对应一个策略，策略决定该 namespace 里的命令会怎样处理：

对 kubectl 来说，只有读操作算安全：get、describe、logs、top、events 以及少数几个。所有会改变集群的操作都是破坏性的，Skyportal 不认识的任何动词也一样，包括 exec、cp 和 port-forward。在 prod namespace 里，SARA 可以查看 pod、日志和事件，但 delete、scale 或 rollout restart 会在聊天里收到这样的消息：

Blocked: my-eks namespace prod (Production, read-only) reject destructive commands. Reads still run there.

在 dev 里，带 namespace 的命令的审批卡片还会提供 Always allow。它会保存一条绑定到该 namespace 的 allow list 条目，比如 kubectl -n dev scale，下一次在 dev 里执行 scale 就不用再出卡片。该条目不会匹配其他 namespace 里的同一条命令。针对 Secret 或 RBAC 对象的命令、exec、cp、attach、port-forward，以及删除 namespace、PVC 或 PV 的操作永远不会获得 Always allow，每次都会询问。

策略属于环境名称，而不属于集群。如果你哪天改了 Production 允许的内容，这个改动会影响到你所有的 Production 主机和 namespace。

在做出决定之前，Skyportal 会先判断一条命令绑定到哪个 namespace。kubectl -n dev scale deployment/api --replicas=3 绑定到 dev。当你在聊天的 scope 里选中一个 namespace 时，Skyportal 会替你加上 -n。如果 dev 和 prod 都在 scope 内，命令必须用 -n 指明 namespace，否则会被拒绝。

有些命令不绑定到单个 namespace：-A、kubectl get nodes、集群级资源类型、用 -f 或 -k 传入的 manifest、任何通过 helm 运行的命令，以及指定另一个集群或身份的 flag，比如 --context 或 --as。这些命令会采用集群上所有环境中最严格的策略。像 kubectl get pods -A 这样的读操作仍然会执行。变更则不会：当 prod 处于 Production 时，kubectl apply -f 和 helm upgrade 在所有 namespace 里都被阻止，包括 dev。

所以把 manifest 和 Helm release 留在你自己的流水线里，把 dev 里带 namespace 的工作交给 SARA：扩缩 deployment、重启 rollout、更换镜像或内存限制、删除卡住的 pod。

在聊天里选择集群，并在 scope picker 里选择 SARA 可以使用的 namespace。带自己标签的 namespace 会在名字旁边显示该标签，SARA 也会随 scope 收到同样的标签，所以它在执行任何操作之前就知道哪个 namespace 是 prod。然后像问同事一样提问：

在 dev 里你逐条批准每个变更，或者对你信任的类别点击 Always allow。在 prod 里 SARA 读取日志、事件和 pod 状态，修复方案会作为建议返回给你。Always allow 在 prod 的读操作上也有效：在 prod 里允许一次 kubectl get，下一次就不用再出卡片了。