如果你还没有认识 Phippy，这只友好的 PHP 河马一直在探索云原生世界，也和一群伙伴一起学习容器、Kubernetes 以及相关生态。过去十年里，Phippy 的朋友圈已经扩展到十八位成员，最新加入的是 Falkey the Falco 和 Ky the Kyverno Pyrenees。
这两个新伙伴代表了云原生安全中两个互补的方向：Falco 更关注运行时发生了什么，Kyverno 更关注 Kubernetes 资源是否符合预期策略。把它们放在同一张架构图里理解，比单独记住两个项目的名字更有帮助。
Falkey：盯住运行中的异常行为
Falco 的核心价值在于运行时检测。容器已经启动、Pod 正在运行时，系统仍然可能出现异常行为，例如容器尝试读取敏感文件、启动不常见的进程，或者访问不应访问的系统资源。
这类问题不一定能在镜像扫描或部署检查阶段发现，因此运行时监控补上了另一层防线。可以把它理解为：
- 部署前检查配置和镜像是否存在已知问题。
- 部署时验证资源是否符合组织策略。
- 运行时观察实际行为，并在出现异常时告警。
Falkey 这个角色让 Phippy 记住一个重要事实：Pod Running 只说明容器进程已经启动，不代表应用行为一定安全。
Ky：在资源进入集群前验证规则
Kyverno 面向 Kubernetes 资源策略。团队可以用策略限制镜像来源、要求工作负载声明资源请求和限制、强制设置安全上下文，或者阻止不符合规范的资源进入集群。
与需要开发专用策略语言相比，Kyverno 的策略可以直接围绕 Kubernetes YAML 编写。对于已经熟悉 Deployment、Pod 和 Namespace 的团队，这种方式更容易审查和纳入代码仓库。
下面是一个可以改造的示例策略。它要求所有 Pod 容器都设置 CPU 和内存的 requests 与 limits。示例假设集群已经安装 Kyverno，并且希望先以审计模式观察影响范围。
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-resource-requests-and-limits
spec:
validationFailureAction: Audit
background: true
rules:
- name: check-container-resources
match:
any:
- resources:
kinds:
- Pod
validate:
message: "每个容器都必须设置 CPU 和内存 requests 与 limits。"
pattern:
spec:
containers:
- resources:
requests:
cpu: "?*"
memory: "?*"
limits:
cpu: "?*"
memory: "?*"
可以将策略保存为 require-resources.yaml，然后执行：
kubectl apply -f require-resources.yaml
kubectl get clusterpolicy require-resource-requests-and-limits
kubectl describe clusterpolicy require-resource-requests-and-limits
Audit 模式适合首次上线策略时使用：它会记录不符合规则的资源，但不会立即阻断部署。确认报告中的误报和例外情况后，再根据团队流程切换为阻断模式。生产环境中不建议跳过这一步，否则一条过于严格的策略可能让正常发布全部失败。
两个伙伴如何配合
Falco 和 Kyverno 解决的问题不同，可以形成一条更完整的 Kubernetes 安全链路：
| 阶段 | 关注点 | 典型问题 |
|---|---|---|
| 资源提交或部署 | Kyverno 策略 | 是否使用受信任镜像？是否设置资源限制？ |
| 资源运行期间 | Falco 规则 | 容器是否执行异常命令？是否访问敏感路径？ |
| 运营与响应 | 告警和审计 | 谁需要接收告警？如何定位并处置事件？ |
实际落地时，可以先用 Kyverno 建立少量高价值规则，例如禁止未签名镜像或强制声明资源限制；再用 Falco 关注高信号运行时事件。安全规则不宜一开始就覆盖所有细节，规则数量太多会增加维护成本，也会让真正重要的告警被噪声淹没。
还需要明确例外机制。开发环境、批处理任务和系统组件可能有不同的资源或权限需求。例外应当写进版本控制、标注负责人和有效范围，而不是通过临时手工操作绕过策略。
给云原生团队的实践清单
可以从下面的顺序开始：
- 盘点当前集群中的 Namespace、工作负载和镜像来源。
- 用 Kyverno 的审计模式检查一到两条基础策略的影响范围。
- 为策略建立代码审查和变更记录。
- 选择少量 Falco 运行时规则接入现有告警系统。
- 为每类告警定义负责人、响应时限和处置动作。
- 定期清理无效策略、重复告警和不再需要的例外。
Falkey 与 Ky 的加入，不只是 Phippy 朋友圈数量的增加，也提醒我们云原生安全需要覆盖多个时间点：资源进入集群之前要有规则，工作负载运行之后要有观察。把策略验证和运行时检测结合起来，团队才能更早发现问题，同时避免把安全控制变成一套无法维护的复杂流程。