[](https://pkg.go.dev/knative.dev/security-guard) [](https://goreportcard.com/report/knative.dev/security-guard) [](https://github.com/knative-sandbox/seurity-guard/releases) [](https://github.com/knative-sandbox/seurity-guard/blob/main/LICENSE) [](https://knative.slack.com) [](https://codecov.io/gh/knative-sandbox/security-guard)

Security-Guard

Guard 帮助保护微服务、无服务器容器和无服务器函数。它检测并阻止发送到服务的漏洞利用，并能够检测并重启受破坏的服务 Pod。 本 Readme 文件提供 Guard 的通用信息。Guard 可用于裸 Kubernetes。请参阅[如何在 Kubernetes 上安装和使用 Guard](KUBERNETES.md)。Guard 与 Knative 集成，使使用更加便捷。请参阅[如何在 Knative 上安装和使用 Guard](https://knative.dev/docs/serving/app-security/security-guard-about/)。 本 Readme 其余部分适用于在任何系统上使用 Guard。 ## 为什么需要 Security-Guard？ 部署在 Kubernetes 上的用户容器可能包含漏洞、配置错误或恶意代码。此类漏洞、配置错误或恶意代码的来源可能是 DevOps 团队、依赖项，或已成功渗透任何支持系统（镜像仓库、CI/CD、Knative、Kube、DevOps 团队开发系统等）或用户容器所使用后端服务的黑客。任何此类安全问题都可能使攻击者将用户容器用于其原始意图之外的目的（例如窃取数据、攻击他人、传播、联系 C&C、加密货币挖矿等）。 Kubernetes 用户需要能够阻止（或至少得到关于）利用嵌入在用户容器中的漏洞或配置错误的尝试，并在发现用户容器被攻击者利用时获得警报。此外，用户还需要建立对运行潜在恶意代码的容器的情境感知能力，并在发现容器被利用时获得响应手段。 ## Security-Guard 如何帮助保护 Kubernetes 服务 Security-Guard 的核心组件是 [guard-gate](pkg/guard-gate)。简而言之，guard-gate 通常会嵌入到 sidecar 中，以保护提供服务的 Pod。[guard-gate](pkg/guard-gate) 会监控并可能阻止基于每个服务安全配置的客户端请求和/或响应。 每个服务的独立安全配置存储在 **“Guardian”** 对象中。**Guardian** 维护一组微规则，用于对交付给或来自服务的数据进行细粒度过滤。 通过使用微规则，[guard-gate](pkg/guard-gate) 可以识别针对服务或其依赖项中嵌入漏洞的漏洞利用投递行为。 当使用 [guard-gate](pkg/guard-gate) 并配合适当的微规则时，攻击者通常需要构建专用的投递机制来探测检测和利用服务漏洞的选项。这一漫长的过程可能需要针对每个服务重复进行，因为每个服务维护的微规则集不同。结果，攻击者无法使用常见的统计攻击模式。此外，大量潜在攻击被 Guard 阻止而无法执行。攻击被完全阻止的比例有待社区进一步研究。 使用 [guard-gate](pkg/guard-gate) 的用户得益于情境感知能力，这既依赖于关于异常请求/响应的告警，也依赖于识别 Pod 相关的安全指标——这表明服务被滥用。这类 Pod 相关指标包括比平时更长的服务时间以及服务访问的外部 IP 地址列表。 [guard-gate](pkg/guard-gate) 能够在发现异常行为时进行阻断，并具备根据细粒度可配置的安全门控对潜在攻击和/或正在进行的攻击做出反应的能力。 总体而言，该解决方案提供了对服务安全性的可见性，以及监控和阻止已知模式和未知模式（使用针对未知漏洞的攻击瞄准未知漏洞）的能力。

## 解决方案组件 本项目包含： 1. [guard-gate](pkg/guard-gate) —— 位于每个服务前面的工作负载安全门 2. 一个 **Guardian** —— 以 CRD 或 ConfigMap 形式实现的微规则集合，用于维护每个服务的规则 3. [guard-service](cmd/guard-service) —— 学习并存储 **Guardian** 中微规则的学习服务 4. [guard-ui](cmd/guard-ui) —— 用于简化微规则手动配置的用户界面 Web 应用 此外，项目还包括： 1. [qpoption](pkg/qpoption) —— 用于在 Knative Queue Proxy Option 中使用 [guard-gate](pkg/guard-gate) 的包 2. [test-gate](pkg/test-gate) —— 用于测试 Knative Queue Proxy Options 的包 3. [pluginterfaces](pkg/pluginterfaces) —— 用于注册和接口安全门控的基础包 请参阅[Guard 架构](ARCHITECTURE.md)了解 Guard 内部如何处理和学习安全数据。 ## Guard Gate [guard-gate](pkg/guard-gate) 可作为 knative queue proxy 选项使用 [qpoption](pkg/qpoption) 加载。 加载后，它会监控代理的请求与响应以及 Pod 网络。 ## Guardian [guard-gate](pkg/guard-gate) 使用 **Guardian** —— 一组定义服务预期行为的微规则。 **Guardian** 对象维护以下配置参数： 1. 控制对象，定义 Guard 与服务的工作模式 2. 由 [guard-service](cmd/guard-service) 更新的学习型微规则集合 3. 可使用 `kubectl` 或 [guard-ui](cmd/guard-ui) 更新的手动配置微规则集合 每个服务都有其独立的 **Guardian**。新服务可使用 Kubernetes 命名空间的默认 **Guardian**，或使用默认 Guard 的 **Guardian**。以下过程描述了在命名空间 `namespace` 中查找服务 `servicename` 的 **Guardian** 的方式。请注意，[guard-gate](pkg/guard-gate) 可配置为使用 CRD（guardians.guard.security.knative.dev）或 ConfigMap `guardian-*` 作为 **Guardian**。 查找服务 **Guardian** 时： - 使用每个服务的 **Dedicated-Guardian**（CRD 名为 `` 或 ConfigMap 名为 `guardian-`）。 - 如果未找到 **Dedicated-Guardian**，则使用 **Namespace-Default -Guardian** 作为起点（CRD 名为 `ns-` 或 ConfigMap 名为 `guardian-ns-`）。 - 如果未找到 **Namespace-Default-Guardian**，则使用 **Default-Guardian** 作为起点。 - 注意，**Default-Guardian** 使用自动学习机制来引导新的 **Guardians**。 更多关于不同 Guard 工作模式的详细信息，请参阅 [guard-gate](pkg/guard-gate)。 ## Guard Service [guard-service](cmd/guard-service) 是一个独立服务，用于基于 [guard-gate](pkg/guard-gate) 提供的输入学习 **Guardian** 微规则。[guard-service](cmd/guard-service) 将 **Guardian** 存储为 CRD（guardians.guard.security.knative.dev），名称为 ``，或存储在名为 `guardian-` 的 ConfigMap 中。 此外，[guard-service](cmd/guard-service) 会缓存 **Guardian** 并为 [guard-gate](pkg/guard-gate) 请求提供服务副本，以减少对 KubeApi 的负载——因为任何已部署的 Knative Pod 在启动时都需要访问 **Guardian** 的副本。 [guard-service](cmd/guard-service) 还充当所有服务发现的告警的中心服务。 最后，[guard-gate](pkg/guard-gate) 指示 Pod 已受破坏时，[guard-service](cmd/guard-service) 可以重启该 Pod。 ### guard-gate 的学习策略 在以下情况下与 guard-service 同步： - 如果已聚合 1000 个或更多样本 - 如果已聚合 1000 个告警 - 已过 1 分钟（或由 GURDIAN_SYNC_INTERVAL 环境变量定义）： - 且已聚合至少 10% 的所有已学样本 - 或存在告警 - 已过 5 分钟（或为 GURDIAN_SYNC_INTERVAL 环境变量的 5 倍）： 注意： - 在正常操作期间，如果上次同步在 5 秒内已完成，我们会避免与 guard-service 同步。 - 在 guard-gate Shutdown() 时，在所有和服务关闭后，如果存在样本或告警，会强制同步后再终止。 ### guard-service 的学习和持久化策略 当从 guard-gate 收到同步消息时，我们首先将其合并到 guard-service 维护的堆中； 然后，如果该服务的 guardian 中尚无学习到的标准，我们会创建一个并持久化该 guardian。 如果 guardian 已包含学习标准： - 如果满足以下任一条件，则学习并更新标准： - 从 guard-gate 累积了超过 1000 个新样本 - 从所有已学样本中累积了超过 10% 的新样本 - 自上次学习起已过 30 秒 如果自上次持久化起已过 5 分钟且已更新学习标准，则持久化 guardian。 ## Guard 用户界面 尽管 **Guardian** CRD 和 ConfigMap 可直接通过 `kubectl` 控制，但提供了可选的 [guard-ui](cmd/guard-ui) 来简化和澄清微规则。 ## 总结 Guard 采用零信任方法。假设所有服务都可能存在漏洞，并在每个服务前面放置一个门控以监控客户端交互并阻止漏洞投递。通过这种方式，Guard 实现了零信任架构。同时，Guard 会监控每个服务 Pod，提供基于 Pod 级别的进一步保护。

标签：3D图, AMSI绕过, Chrome Headless, CNCF沙箱, DevOps安全, EVTX分析, GitHub Advanced Security, Go开发, Go语言安全, IPS, K8s审计, Knative安全, Kubernetes安全, Serverless安全, TypeScript, Web截图, 威胁检测, 威胁检测与响应, 子域名突变, 安全加固, 安全守护, 安全插件, 容器入侵检测, 容器安全, 容器沙箱, 容器运行时保护, 容器逃逸防护, 异常检测, 微服务安全, 日志审计, 服务恢复, 自动恢复, 运行时防护, 镜像安全扫描