mcpField
D
defender-for-containers

defender-for-containers

github.com/vinayaklatthe安全17842 次安装19 周前更新
代码仓库

关于 defender-for-containers

用于规划和强化 Kubernetes 集群及其镜像仓库防护的技能，面向使用 Microsoft Defender for Cloud 的团队。它覆盖集群态势、镜像漏洞、运行时威胁和准入控制。

主要功能

  1. 01规划集群接入与传感器部署
  2. 02配置镜像持续漏洞扫描
  3. 03规划运行时威胁检测
  4. 04设计 Kubernetes 准入策略
  5. 05审查攻击路径

适用场景

  1. 01通过 Arc 接入 EKS 或 GKE 集群
  2. 02在镜像发布后持续发现新漏洞
  3. 03先以审计模式测试准入策略
  4. 04调查容器运行时威胁告警

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/vinayaklatthe/microsoft-security-skills --skill defender-for-containers

安装后在 Claude Code 中输入/defender-for-containers确认已加载。

详细介绍

Microsoft Defender for Containers

Defender for Containers 是 Microsoft Defender for Cloud 中支持 Kubernetes 的计划。 它覆盖 AKS、Azure Arc-enabled Kubernetes（本地、EKS、GKE、OpenShift）以及为这些集群提供镜像的容器注册表，提供安全态势管理、镜像漏洞评估、运行时威胁检测和准入控制。

适用场景

保护 Kubernetes 集群及其镜像来源注册表。此技能适用于计划部署、传感器与无代理方案的权衡、注册表扫描、准入策略设计和运行时警报响应。

此技能不适用于 VM/主机加固（defender-for-servers）、集群网络设计（azure-network-security-design）或通用 AKS 运维（azure-kubernetes）。

功能概览

功能工作方式覆盖范围
无代理发现基于 API 的集群清单、控制平面配置错误、K8s API 审计日志分析AKS、EKS、GKE、Arc
无代理漏洞评估对节点磁盘创建快照；扫描注册表中的镜像和正在运行的容器AKS、EKS、GKE
注册表扫描在拉取时、推送时和持续扫描镜像ACR、ECR、GAR
运行时威胁检测Defender 传感器（DaemonSet，在 Linux 上使用 eBPF）——检测无文件攻击、横向移动和加密货币挖矿程序AKS、Arc、EKS、GKE
Kubernetes 数据平面加固Azure Policy for Kubernetes 加载项（OPA/Gatekeeper）AKS、Arc-enabled K8s
攻击路径分析综合安全态势、漏洞和运行时数据，找出互联网 → Pod → 云 IAM 攻击路径全部

实施方法

  1. 在订阅范围启用 Defender for Containers。 自动预配会安装：

    • Defender 传感器（DaemonSet），用于检测 Linux 节点上的运行时威胁。
    • 用于准入控制的 Azure Policy for Kubernetes 加载项。
    • 自动连接 ACR 扫描。 验证：kubectl get ds -n kube-system 显示 microsoft-defender-collector-ds；AKS 显示 Defender 配置文件 = enabled。

  2. 通过 Arc 连接非 Azure 集群。 EKS/GKE 需要在 AWS/GCP 云帐户级别配置连接器，并通过 Arc 完成接入，才能使用运行时传感器（无代理功能无需传感器即可使用）。

  3. 配置注册表扫描安全态势。 开启持续扫描，确保新披露的 CVE 能在已推送的镜像中触发发现，而不仅仅是在推送时触发。设置保留期限，以便 90 天后仍能回答“镜像 X 是否易受 CVE-Y 影响”。

  4. 在管道中管理镜像漏洞。 不要等到运行时才处理：将相同的 MDVM API 集成到 CI 中，在发现严重且可利用的 CVE 时让构建失败。结合镜像签名（Notation / cosign）和准入控制，要求镜像必须经过签名。

  5. 运行时威胁检测——使用传感器还是无代理方案？

    • 以下情况需要传感器：无文件攻击、进程树、内存中利用、横向移动、反向 Shell。
    • 无代理方案覆盖：镜像漏洞、安全态势、基于 K8s API 审计的检测。
    • 在生产环境中两者都用。仅在 Linux 节点池上部署传感器（Windows 运行时传感器的覆盖范围有限）。

  6. 使用 Azure Policy / Gatekeeper 实施准入控制。 先以审计模式运行 14 天，然后再启用拒绝。基线策略：

    • 禁止特权容器。
    • 禁止将 hostPath 挂载到敏感路径。
    • 应用工作负载必须使用 readOnlyRootFilesystem。
    • 必须设置资源限制。
    • 必须使用经过签名的镜像（注册表允许列表）。

  7. 每周检查攻击路径分析。 应优先修复的高价值路径是暴露于互联网的 Pod 存在严重 CVE → 工作负载标识 → 云 IAM。应根据影响范围排序，而非发现数量。

  8. 通过 Defender for Cloud 连接器将警报流式传输到 Sentinel。 针对按 ProductName = "Microsoft Defender for Containers" 筛选的 SecurityAlert 构建威胁搜寻查询。

防护措施

  • 运行时检测需要 Defender 传感器。 仅靠无代理方式无法发现 Pod 内运行的反向 Shell 或加密货币挖矿程序。
  • 先以审计模式部署准入策略。 如果第一天就以拒绝模式启用 requiredLabels 策略，会导致部署受阻。
  • 未经测试，不要运行两个会挂接内核的特权 DaemonSet（例如 Defender 传感器、Falco 和第三方 EDR）；这可能导致 eBPF 程序冲突和节点不稳定。
  • ACR + 专用终结点 + Defender 扫描需要仔细设计网络。 扫描器必须能够访问注册表；请验证专用 DNS 解析和受信任服务绕过设置。
  • 不要将计划范围限定为单个集群的资源组。 其他资源组中的新集群将得不到保护。请使用订阅范围 + 策略强制实施。
  • Windows 容器的传感器覆盖范围有限。 请通过对 Windows 工作负载实施更严格的准入控制和映像扫描来弥补。
  • 没有可利用性上下文的映像漏洞发现结果只是噪声。 分类处理前，务必按可利用漏洞 / KEV 筛选。

常见反模式

  • “只有无代理模式，因为传感器会让每个节点增加 80 MB 内存开销”——但你没有任何运行时检测。请为内存预留预算。
  • “第一天就以拒绝模式启用准入策略”——会造成服务中断。先审计 14 天，修复违规项，然后再启用拒绝模式。
  • “只在推送时扫描映像”——昨天的映像若出现今天的 CVE，就不会被标记。请启用持续扫描。
  • “CI 忽略 MDVM 发现结果——我们会在运行时发现漏洞”——漏洞会进入生产环境；回滚代价高昂。对于严重且可利用的漏洞，应让构建失败。
  • “所有集群都纳入范围，不为沙盒环境设置例外”——警报过多会掩盖真实事件。通过标记 / 范围设置，将沙盒环境排除在准入拒绝和警报路由之外。
  • “在直接运行 Docker 的 VM 主机上使用了 Defender for Containers”——工具不对；这种情况应使用 defender-for-servers。
  • “因为连接器已经够用，所以跳过了 EKS/GKE 的 Arc”——没有运行时传感器，也就没有 eBPF 检测。

示例提示词

  • 为包含 AKS 集群的 5 个订阅启用 Defender for Containers；先在开发环境试运行 7 天。
  • 部署用于 Kubernetes 准入控制的 Azure Policy——将基线策略集设为审计模式。
  • 通过 Arc 连接 3 个 EKS 集群并启用运行时传感器。
  • 构建一个 CI 门禁：发现 MDVM 报告的严重可利用 CVE 时让构建失败。
  • 调查“容器中的加密货币挖矿活动”警报——提供运行手册 + KQL。
  • 调整攻击路径分析，使其只显示从互联网到云 IAM 的路径。
  • 设计准入控制，仅允许来自已批准 ACR 的已签名映像。

Microsoft Learn

评论

支持 Markdown