安全 (security)

security 类不是一套独立的 kustomize 应用，而是给两个安全相关组件 —— cert-manager 和 kyverno —— 补充的监控与网络策略片段。这两个组件的主体 manifest 实际都放在 infrastructure 类的同名目录下，由各自的 ArgoCD Application 同步。

这个类里有什么

applications/security/ 下只有两份目录，各自只装监控相关的零散 manifest：

组件

两个组件的完整定义都在 infrastructure 目录，下面是从 manifest 直接核对的事实。

cert-manager 与 metallb 自签 issuer

除了对外签发 Let's Encrypt 证书，cert-manager 还给集群内部的 webhook 签自签证书。最典型的就是 metallb 的 validating webhook：它的证书不走 ACME，而是用一个 namespace 级的自签 Issuer。

相关对象都在 applications/networking/metallb/，不在 cert-manager 目录里：

# applications/networking/metallb/issuers-selfsigned.yaml
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: selfsigned-issuer
  namespace: metallb-system
spec:
  selfSigned: {}

配套的 certificates-webhook.yaml 用这个 Issuer 给 webhook-server-cert 签一张有效期 1 年、提前 30 天续订的证书，dnsNames 为 webhook-service.metallb-system.svc 及其 .cluster.local 形式。这就是为什么 metallb 的 manifest 相比上游做了定制（--webhook-mode=enabled），它依赖 cert-manager 在场才能起 webhook。

kyverno 的保护策略

kyverno 目前装了两条 ClusterPolicy（applications/infrastructure/kyverno/policies/），都是 validationFailureAction: Enforce、background: false，作用是阻止误删核心基础设施：

也就是说，这两条策略只在删除这些关键对象时拦截并报错，对其它资源不做校验。

工作负载隔离：沙箱运行时决策

是否给集群引入 VM/沙箱级容器运行时（gVisor / Kata Containers）做过一次评估。结论：暂不引入，沿用默认 runc。

判断依据：不可信/多租户用户代码的现状是「可能跑，但很少（约 5%）」。为偶发负载维护一个常驻的沙箱运行时，固定运维成本（额外节点要求、guest 内核/镜像维护、两层排障、可观测性失配）摊不薄，ROI 不划算。这是私有 K3s homelab，不是公网多租户平台 —— 沙箱的核心价值（hypervisor 级、每 Pod 独立内核的隔离）在当前威胁模型下基本兑现不了。

将来真要做隔离时的选型结论（已调研，避免重复评估）：

重新评估的触发线（出现任一条就重启此决策）：不可信任务从偶发变成常规（如开始稳定接外部 PR / 客户代码）；开始多租户、租户间共享内核；出现合规层面的强隔离要求。

Pod 安全硬化：现状与缺口

一次实地核对（2026-06）：集群目前有「运维 guardrail + 网络隔离」层，但没有「Pod 安全硬化」基线。这与上面的隔离决策是配套的 —— 同样基于「为约 5% 的偶发风险折腾，对私有 homelab 不划算」而有意暂缓。

已有：

缺口（即「Pod 硬化」层缺失）：

若改主意要补，按本仓库既有模式、运行时无关的硬化路径（任选）：

• 沿用 PSA 标签（metallb-system / velero 已在用）：给业务 namespace 加 pod-security.kubernetes.io/enforce: baseline + warn/audit: restricted，观察无破坏后再把 enforce 升到 restricted。
• kubelet seccompDefault: true：节点级改动，需重启 kubelet（节点在自己手里，可灰度）。
• 加一条 kyverno ClusterPolicy：kyverno 已安装，用 validationFailureAction: Audit 先观察、再升 Enforce。
• 自己的服务在 pod spec 里补 securityContext：runAsNonRoot / capabilities.drop: [ALL] / allowPrivilegeEscalation: false / seccompProfile.type: RuntimeDefault。