企业官网建设流程全解析

sofka 是一款用 Rust 编写的 Kubernetes 终端界面（Kubernetes TUI），基于 kube-rs 和 ratatui 构建，从底层就是异步优先。它的最大卖点之一是内置只读模式与声明式 Guardrails 护栏：把"生产环境永不删除"这类团队纪律，从靠人记住的口头约定，变成配置里强制执行、谁也绕不过去的规则。对于要在生产集群上频繁排障的工程师和新手来说，这套机制就是你误删生产 Pod 之前的最后一道保险。

这篇文章带你完整走一遍：三种方式开启只读模式、用声明式规则写出自己的护栏、多条规则如何合并生效，以及配套的审计日志与权限预检。

为什么需要"防手滑"机制

K8s 世界里最常见的生产事故不是代码 Bug，而是人为失误：

• 想删测试 Pod，却在生产上下文里按了delete
• 批量space选中 50 个资源，一口气全删了
• 为了看日志直接shell进生产 Pod，顺手改坏了东西
• 手动scale了 Deployment，被控制器对账后又改回来，越修越乱

传统做法是"大家小心一点"+ 事后 RBAC 兜底。sofka 的思路不同：把安全规则写进声明式配置，让 TUI 本身成为执行者——动作在发出前就被拦截，而不是发出后再被 API Server 拒绝。

只读模式：一键锁住所有写操作

sofka 的只读模式（Read-only mode）会禁掉一切变更类动作：删除、编辑、扩缩容、进入 Shell、变更类插件、文件上传，一个都不放过。有三种开启方式，按优先级从高到低排列：

命令行参数定义见 src/main.rs，--readonly与--write互斥，参数会覆盖包括"按集群/按上下文"在内的所有readonly配置值。

新手推荐的方式是③：给生产上下文单独建一个覆盖文件，让它"既只读、又醒目"——sofka 官方文档给的经典写法就是给生产环境换一个浅色皮肤，让你从视觉上就意识到"这不是测试环境"：

# clusters/prod-cluster/config.toml — 让生产环境既只读又醒目 readonly = true [skin] name = "catppuccin-latte" background = true

切换上下文时的行为也很贴心：

• 没带命令行参数时，:ctx切进一个readonly = true的上下文，只读模式自动开启，头部会显示[read-only]标记；切出去又自动恢复写模式，无需重启；
• 覆盖文件在每次:ctx切换时都会重新读取，改完配置立即生效。

只读模式对插件同样严格：会屏蔽所有标记为mutating的插件，以及带network_load = true的插件——即使插件不改 K8s 资源，联网插件也需要确认后才能运行。

声明式 Guardrails：给每个危险动作装上"规则引擎"

只读模式是"全有或全无"，而 Guardrails 可以做到精细到每个动作。在配置文件里用[[guardrails]]声明规则，每条规则由两部分组成：

匹配部分（全部可选，省略即匹配一切，支持*通配符）：

• contexts—— kubeconfig 上下文，如*prod*
• namespaces—— 命名空间，如kube-system
• resources—— 资源类型，如deployments
• actions—— 被管控的动作

执行部分（三选一或组合）：

• deny = true—— 直接拦截，并可配reason说明拦截原因
• confirmation—— 要求确认，强度分三档：普通y/N<type-resource-name（手打资源名）<type-context-name（手打上下文名）
• max_bulk—— 限制单次操作的目标数量，如max_bulk = 1表示不许批量

可被护栏管控的actions覆盖了 sofka 直接执行的所有破坏性动作：delete、force-delete、drain、restart、rollback、shell、debug、node-debug、transfer（向 Pod 传文件）、secret-edit、prune（Argo CD 带清理的同步）、pvc-explore、pvc-upload。插件动作则用plugin:<调色板名>匹配，plugin:*匹配所有插件。

实战：给生产环境配一套标准护栏

下面这份配置直接可用，把最常见的三种事故场景全部堵死：

# ① 生产上下文：禁止一切破坏性动作，原因写给人看 [[guardrails]] contexts = ["*prod*"] actions = ["delete", "force-delete", "drain"] deny = true reason = "生产环境的破坏性操作走 GitOps，不走 TUI" # ② 生产上下文：进 Shell 前必须手打上下文名确认 [[guardrails]] contexts = ["*prod*"] actions = ["shell"] confirmation = "type-context-name" reason = "进生产 Pod 前，先确认你操作的是哪个上下文" # ③ 系统命名空间：不允许批量删除 [[guardrails]] namespaces = ["kube-system"] actions = ["delete"] max_bulk = 1

规则效果一览：

• 在prod上下文删 Pod？→ 直接拦截，闪示blocked by guardrail: delete pods — 生产环境的破坏性操作走 GitOps…
• 在prod上下文进 Shell？→ 弹出提示，必须逐字键入当前上下文名才放行
• 在kube-system里勾选 3 个资源批量删？→ 提示超出max_bulk = 1上限，操作被拒绝

规则引擎的核心逻辑（通配符匹配 + 规则合并）实现在 src/app/guardrails.rs。

多条规则命中时，谁说了算？

同一个动作可能同时命中多条规则，sofka 的合并策略简单粗暴——永远取最严的那个，规则书写顺序不影响结果：

1. 拒绝优先：任何一条命中规则带deny = true，动作直接被拦；拦截提示会显示最后一条带非空reason的拒绝规则的文案
2. 数量限制取最小值：多条规则都限max_bulk时，用最小的那个；目标数超限即拦截
3. 确认强度取最高级：多条规则要求不同确认级别时，执行最强的一档（手打上下文名 > 手打资源名 > 普通确认）
4. 规则只能加码，不能松绑：任何规则都无法低于动作自带的默认确认级别

换句话说，你可以在团队共享配置里写严规则、在个人配置里再加规则，结果只会更安全，绝不会"新规则把旧规则覆盖了"。

配套安全特性：留痕与预检

护栏拦下的是"动作"，剩下两个特性管的是"事后追责"和"事前确认"：

• 操作审计日志：:journal（或:audit）是会话级的内存日志，按时间倒序记录你执行过的每个变更动作——动作、目标、上下文、时间。只记录动作开始，且只存标识符，绝不存 Secret 内容；开启info级应用日志后这些动作也会落盘。手滑不可怕，怕的是查不到谁干的；
• 权限预检：:can-i执行SelfSubjectRulesReview，在 TUI 里直接回答"我当前能在这个命名空间做什么"；:can-i <verb> <resource> [ns]可以针对单次操作预检，和kubectl auth can-i等价，但不用切回 Shell；
• 托管资源警告：当你试图编辑、删除、扩缩容一个由 Flux / Argo CD 等控制器托管的对象时，sofka 会先提醒你：下一次对账就会把你的改动回滚或重建对象——去改源头，而不是跟控制器对着干。

另外，节点 drain 本身也内置了安全边界：先 cordon 再检查 Pod，遇到无控制器、emptyDir卷或无 UID 的 Pod 会整体停下并给出原因，始终走驱逐 API 以保留 PodDisruptionBudget 检查，没有"强制跳过"的后门。

小结

sofka 的安全哲学可以概括为一句话："never delete in prod" 是被执行的规则，不是被记住的纪律。完整的安全特性说明见 docs/safety.md，护栏配置示例与按上下文覆盖的目录结构见 docs/configuration.md，更多功能一览可参考 docs/features.md。