本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 启用运行时监控的先决条件 要启用 Runtime Monitoring 并管理 GuardDuty 安全代理，您必须满足要监控的每种资源类型的先决条件，以进行威胁检测。每种资源类型都有不同的先决条件。例如，根据资源类型 GuardDuty 支持不同的操作系统分布。 如果您只想监控 Amazon EC2 资源，则需要满足 Amazon EC2 实例的先决条件。如果您以后选择监控 Amazon EKS 资源，则必须满足特定于 Amazon EKS 集群的先决条件。 以下章节包含不同资源类型的先决条件。 **Topics** + [Amazon EC2 实例支持的先决条件](prereq-runtime-monitoring-ec2-support.md) + [AWS Fargate （仅限 Amazon ECS）支持的先决条件](prereq-runtime-monitoring-ecs-support.md) + [Amazon EKS 集群支持的先决条件](prereq-runtime-monitoring-eks-support.md) # Amazon EC2 实例支持的先决条件 本节包含监控 Amazon EC2 实例的运行时行为的先决条件。满足这些先决条件后，请参阅[启用 GuardDuty 运行时监控](runtime-monitoring-configuration.md)。 **Topics** + [将 EC2 实例设为由 SSM 托管（仅限自动代理配置）](#ssm-managed-prereq-ec2) + [验证架构要求](#validating-architecture-req-ec2) + [在多账户环境中验证组织服务控制策略](#validate-organization-scp-ec2) + [使用自动代理配置时](#runtime-ec2-prereq-automated-agent) + [GuardDuty 代理的 CPU 和内存限制](#ec2-cpu-memory-limits-gdu-agent) + [后续步骤](#next-step-after-prereq-ec2) ## 将 EC2 实例设为由 SSM 托管（仅限自动代理配置） GuardDuty 使用 AWS Systems Manager (SSM) 在您的实例上自动部署、安装和管理安全代理。如果您计划手动安装和管理 GuardDuty 代理，则不需要 SSM。 要使用 Systems Manager 管理 Amazon EC2 实例，请参阅《AWS Systems Manager 用户指南》**中的[为 Amazon EC2 实例设置 Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html)。 ## 验证架构要求 操作系统分发的架构可能会影响 GuardDuty 安全代理的行为。在为 Amazon EC2 实例使用运行时监控之前，您必须满足以下要求： + 内核支持包括 `eBPF`、`Tracepoints` 和 `Kprobe`。对于 CPU 架构，运行时监控支持 AMD64 (`x64`) 和 ARM64 （Graviton2 及更高版本）。[1](#runtime-monitoring-ec2-graviton-2-support) 下表显示了经验证可支持 Amazon EC2 实例 GuardDuty安全代理的操作系统分配。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html) 1. Amazon EC2 资源运行时监控不支持第一代 Graviton 实例，例如 A1 实例类型。 1. 对各种操作系统的支持- GuardDuty 已验证运行时监控支持上表中列出的操作发行版。虽然 GuardDuty 安全代理可以在上表中未列出的操作系统上运行，但该 GuardDuty 团队无法保证预期的安全值。 1. 对于任何内核版本，都必须将 `CONFIG_DEBUG_INFO_BTF` 标志设置为 `y`（含义为 *true*）。这是必需的，这样 GuardDuty 安全代理才能按预期运行。 1. 对于内核版本 5.10 及更早版本， GuardDuty 安全代理使用 RAM (`RLIMIT_MEMLOCK`) 中的锁定内存来按预期运行。如果您的系统`RLIMIT_MEMLOCK`值设置得太低， GuardDuty 建议将硬限制和软限制都设置为至少 32 MB。有关验证和修改默认 `RLIMIT_MEMLOCK` 值的信息，请参阅[查看和更新 `RLIMIT_MEMLOCK` 值](#runtime-monitoring-ec2-modify-rlimit-memlock)。 1. 对于 Ubuntu 24.04，内核版本 6.13 和 6.14 仅支持 EC2 代理版本 1.9.2 及更高版本。 + 其他要求-仅当您拥有 Amazon ECS/Amazon EC2 时 对于亚马逊 ECS/Amazon EC2，我们建议您使用最新的亚马逊 ECS 优化版 AMIs （日期为 2023 年 9 月 29 日或之后），或者使用亚马逊 ECS 代理版本 1.77.0。 ### 查看和更新 `RLIMIT_MEMLOCK` 值 当您的系统`RLIMIT_MEMLOCK`限制设置得太低时， GuardDuty 安全代理可能无法按设计运行。 GuardDuty 建议硬限制和软限制都必须至少为 32 MB。如果您不更新限制， GuardDuty 将无法监控资源的运行时事件。当 `RLIMIT_MEMLOCK` 超过规定的最低限额时，您可以选择更新这些限制。 您可以在安装 GuardDuty 安全客户端之前或之后修改默认`RLIMIT_MEMLOCK`值。 **查看 `RLIMIT_MEMLOCK` 值** 1. 运行 `ps aux | grep guardduty`。这将输出进程 ID (`pid`)。 1. 从上一条命令的输出中复制进程 ID (`pid`)。 1. 将 `pid` 替换为从上一步中复制的进程 ID，然后运行 `grep "Max locked memory" /proc/pid/limits`。 这将显示运行 GuardDuty 安全代理时的最大锁定内存。 **更新 `RLIMIT_MEMLOCK` 值** 1. 如果 `/etc/systemd/system.conf.d/NUMBER-limits.conf` 文件存在，则从该文件中注释掉 `DefaultLimitMEMLOCK` 行。此文件将默认 `RLIMIT_MEMLOCK` 设置为高优先级，这会覆盖您在 `/etc/systemd/system.conf` 文件中的设置。 1. 打开 `/etc/systemd/system.conf` 文件并取消注释包含 `#DefaultLimitMEMLOCK=` 的行。 1. 更新默认值，将 `RLIMIT_MEMLOCK` 硬限制和软限制设置为至少 32 MB。更新后的策略应如下所示：`DefaultLimitMEMLOCK=32M:32M`。格式为 `soft-limit:hard-limit`。 1. 运行 `sudo reboot`。 ## 在多账户环境中验证组织服务控制策略 如果您设置了服务控制策略（SCP）来管理组织中的权限，请验证权限边界允许 `guardduty:SendSecurityTelemetry` 操作。它是支持跨不同资源类型的运行时监控所必需的。 GuardDuty 如果您是成员账户，则连接到关联的委派管理员。有关为您的组织 SCPs 进行管理的信息，请参阅[服务控制策略 (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)。 ## 使用自动代理配置时 为[使用自动代理配置（推荐）](how-runtime-monitoring-works-ec2.md#use-automated-agent-config-ec2)此，您 AWS 账户 必须满足以下先决条件： + 在自动代理配置中使用包含标签时， GuardDuty 要为新实例创建 SSM 关联，请确保新实例由 SSM 管理并显示在控制台的 **Fleet Manager** 下。[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) + 将排除标签与自动代理配置结合使用时 + 在为您的账户配置 GuardDuty 自动代理之前，请添加`GuardDutyManaged`:`false`标签。 务必要在启动 Amazon EC2 实例之前添加排除标签。为 Amazon EC2 启用自动代理配置后，任何启动时没有排除标签的 EC2 实例都将受到 GuardDuty 自动代理配置的保护。 + 为您的实例启用**允许在元数据中添加标签**设置。此设置是必需的，因为 GuardDuty 需要从实例元数据服务 (IMDS) 读取排除标签，以确定是否应将该实例排除在代理安装之外。有关更多信息，请参阅《Amazon EC2 用户指南》**中的[启用对实例元数据中标签的访问权限](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/work-with-tags-in-IMDS.html#allow-access-to-tags-in-IMDS)。 ## GuardDuty 代理的 CPU 和内存限制 **CPU 限制** 与 Amazon EC2 实例关联 GuardDuty 的安全代理的最大 CPU 限制为 vCPU 内核总数的 10%。例如，假设您的 EC2 实例有 4 个 vCPU 核心，则在 400% 的总可用容量中，安全代理最多可以使用 40%。 **内存限制** 从与您的 Amazon EC2 实例关联的内存中， GuardDuty 安全代理可以使用的内存有限。 具体内存限制详见下表。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html) ## 后续步骤 下一步是配置运行时监控并管理安全代理（自动或手动）。 # AWS Fargate （仅限 Amazon ECS）支持的先决条件 本节包含监控 Fargate-Amazon ECS 资源的运行时行为的先决条件。满足这些先决条件后，请参阅[启用 GuardDuty 运行时监控](runtime-monitoring-configuration.md)。 **Topics** + [验证架构要求](#validating-architecture-req-ecs) + [访问容器映像的先决条件](#before-enable-runtime-monitoring-ecs) + [在多账户环境中验证组织服务控制策略](#validate-organization-scp-ecs) + [验证角色权限和策略权限边界](#guardduty-runtime-monitoring-ecs-permission-boundary) + [CPU 和内存限制](#ecs-runtime-agent-cpu-memory-limits) ## 验证架构要求 您使用的平台可能会影响 GuardDuty 安全代理支持 GuardDuty 从 Amazon ECS 集群接收运行时事件的方式。您必须验证自己使用的是其中一个经过验证的平台。 **初步注意事项：** 您的亚马逊 ECS 集群的 AWS Fargate 平台必须是 Linux。相应的平台版本必须至少为 `1.4.0` 或 `LATEST`。有关平台版本的更多信息，请参阅《Amazon Elastic Container Service 开发人员指南》中的 [Linux 平台版本](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/platform-linux-fargate.html)**。 尚不支持 Windows 平台版本。 ### 经过验证的平台 操作系统分布和 CPU 架构会影响 GuardDuty安全代理提供的支持。下表显示了用于部署 GuardDuty安全代理和配置运行时监控的经过验证的配置。 | 操作系统分发 **[1](#runtime-monitoring-ecs-os-support)** | 内核支持 | CPU 架构 x64 () AMD64 | CPU 架构 Graviton () ARM64 | | --- | --- | --- | --- | | Linux | eBPF、Tracepoints、Kprobe | 支持 | 支持 | 1 Support 支持各种操作系统- GuardDuty 已验证运行时监控支持上表中列出的操作发行版。虽然 GuardDuty 安全代理可以在上表中未列出的操作系统上运行，但该 GuardDuty 团队无法保证预期的安全值。 ## 访问容器映像的先决条件 以下先决条件可帮助您从 Amazon ECR 存储库访问 GuardDuty 边车容器镜像。 ### 权限要求 任务执行角色需要特定的 Amazon Elastic Container Registry (Amazon ECR) 权限才能下载安全代理容器 GuardDuty 镜像： ``` ... "ecr:GetAuthorizationToken", "ecr:BatchCheckLayerAvailability", "ecr:GetDownloadUrlForLayer", "ecr:BatchGetImage", ... ``` 要进一步限制 Amazon ECR 权限，您可以添加托管其 GuardDuty 安全代理的 Amazon ECR 存储库 URI（仅限 AWS Fargate Amazon ECS）。有关更多信息，请参阅 [Amazon ECR 存储库托管代理 GuardDuty](runtime-monitoring-ecr-repository-gdu-agent.md)。 您可以使用 [Amazon ECSTask ExecutionRolePolicy](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_execution_IAM_role.html) 托管策略，也可以将上述权限添加到您的`TaskExecutionRole`策略中。 ### 任务定义配置 创建或更新 Amazon ECS 服务时，您需要在任务定义中提供子网信息： [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) APIs 在《*亚马逊弹性容器服务 API 参考*》中运行[CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html)和需要您传递子网信息。有关更多信息，请参阅《Amazon Elastic Container Service 开发人员指南》中的 [Amazon ECS 任务定义](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html)**。 ### 网络连接要求 您必须确保网络连接才能从 Amazon ECR 下载 GuardDuty 容器映像。此要求特定于， GuardDuty 因为它使用 Amazon ECR 来托管其安全代理。需要实施以下操作之一，具体取决于网络配置： **选项 1：使用公共网络访问（如果可用）** 如果您的 Fargate 任务在具有出站互联网访问权限的子网中运行，则无需进行额外的网络配置。 **选项 2：使用 Amazon VPC 端点（用于私有子网）** 如果您的 Fargate 任务在无法访问互联网的私有子网中运行，则必须为 ECR 配置 VPC 终端节点，以确保托管 GuardDuty 安全代理的 ECR 存储库 URI 可通过网络访问。如果没有这些终端节点，私有子网中的任务就无法下载 GuardDuty 容器镜像。 如需查看 VPC 端点设置说明，请参阅**《Amazon Elastic Container Registry User Guide》中的 [Create the VPC endpoints for Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html#ecr-setting-up-vpc-create)。 有关启用 Fargate 下载容器的信息，请参阅[亚马逊弹性 GuardDuty 容器注册表用户指南中的将 Amazon ECR 镜像与](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ECR_on_ECS.html) *Ama* zon ECS 配合使用。 ### 安全组配置 GuardDuty 容器镜像存储在 Amazon ECR 中，需要访问 Amazon S3。此要求特定于从 Amazon ECR 下载容器映像。对于网络访问受限的任务，您必须将安全组配置为允许访问 S3。 在您的安全组中添加一条出站规则，允许流量通过端口 443 访问 [S3 托管前缀列表 (`pl-xxxxxxxx`)](https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.html#gateway-endpoint-security)。要添加出站规则，请参阅《Amazon VPC 用户指南》**中的[配置安全组规则](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html)。 要在控制台中查看您的 AWS托管前缀列表或使用 AWS Command Line Interface (AWS CLI) 对其进行描述，请参阅 Amazon *VPC 用户*[指南中的AWS托管前缀列表](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-aws-managed-prefix-lists.html)。 ## 在多账户环境中验证组织服务控制策略 本节介绍如何验证您的服务控制策略（SCP）设置，以确保运行时监控在整个组织中按预期运行。 如果您设置了一个或多个服务控制策略来管理组织中的权限，必须验证该策略不会拒绝 `guardduty:SendSecurityTelemetry` 操作。有关 SCPs 工作原理的信息，请参阅《*AWS Organizations 用户指南》*中的 [SCP 评估](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_evaluation.html)。 如果您是成员账户，则连接到关联的委派管理员。有关组织管理 SCPs 的信息，请参阅*《AWS Organizations 用户指南》*中的[服务控制策略 (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)。 对您在多账户环境中设置的所有内容执行以下步骤： SCPs **验证在 SCP 中未拒绝 `guardduty:SendSecurityTelemetry`** 1. 登录 Organizations 控制台，网址为[https://console.aws.amazon.com/organizations/](https://console.aws.amazon.com/organizations/)。您必须以 IAM 角色的身份登录，或在组织的管理账户中以根用户的身份登录（[不推荐](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)）。 1. 在左侧导航窗格中，选择**策略**。然后，在**支持的策略类型**下，选择**服务控制策略**。 1. 在**服务控制策略**页面上，选择要验证的策略的名称。 1. 在策略详情页面上，查看该策略的**内容**。确保该策略不会拒绝 `guardduty:SendSecurityTelemetry` 操作。 以下 SCP 策略是*不拒绝* `guardduty:SendSecurityTelemetry` 操作的示例： ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "guardduty:SendSecurityTelemetry" ], "Resource": "*" } ] } ``` ------ 如果您的策略拒绝此操作，则必须更新该策略。有关更多信息，请参阅《AWS Organizations User Guide》**中的 [Update a service control policy (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_policies_update.html#update_policy)。 ## 验证角色权限和策略权限边界 使用以下步骤验证与角色关联的权限边界及其策略是否**不**限制 `guardduty:SendSecurityTelemetry` 操作。 **查看角色权限边界及其策略** 1. 登录 AWS 管理控制台 并打开 IAM 控制台，网址为[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)。 1. 在左侧导航窗格中的**访问权限管理**下，选择**角色**。 1. 在**角色**页面上，选择您已创建的角色 *`TaskExecutionRole`*。 1. 在所选角色页面的**权限**选项卡下，展开与此角色关联的策略名称。然后，确认此策略不限制 `guardduty:SendSecurityTelemetry` 操作。 1. 如果设置了**权限边界**，则展开此部分。然后，展开每项策略，查看其是否不限制 `guardduty:SendSecurityTelemetry` 操作。策略应如 [Example SCP policy](#ecs-runtime-scp-not-deny-policy-example) 所示。 如有需要，执行以下操作之一： + 要修改策略，请选择**编辑**。在此策略的**修改权限**页面上，在**策略编辑器**中更新策略。确保 JSON 架构保持有效。然后选择**下一步**。然后，您可以查看并保存更改。 + 要更改此权限边界并选择其他边界，请选择**更改边界**。 + 要移除此权限边界，请选择**移除边界**。 有关管理策略的更多信息，请参阅《IAM 用户指南》**中的 [AWS Identity and Access Management中的策略与权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)。 ## CPU 和内存限制 在 Fargate 任务定义中，您必须在任务级别指定 CPU 和内存值。下表显示了任务级 CPU 和内存值的有效组合，以及容器的相应 GuardDuty 安全代理最大内存限制。 GuardDuty [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/guardduty/latest/ug/prereq-runtime-monitoring-ecs-support.html) 启用运行时监控并评估集群的覆盖率状态是否**正常**后，您可以设置和查看 Container Insights 指标。有关更多信息，请参阅 [在 Amazon ECS 集群上设置监控](runtime-monitoring-setting-cpu-mem-monitoring.md#ecs-runtime-cpu-memory-monitoring-agent)。 下一步是配置运行时监控和安全代理。 # Amazon EKS 集群支持的先决条件 本节包含监控 Amazon EKS 资源的运行时行为的先决条件。这些先决条件对于 GuardDuty 代理按预期运行至关重要。满足这些先决条件后，请参阅[启用 GuardDuty 运行时监控](runtime-monitoring-configuration.md)，开始监控您的资源。 ## 对 Amazon EKS 功能的支持 运行时监控**支持**在 Amazon EC2 实例上运行的 Amazon EKS 集群和 Amazon EKS 自动模式。 运行时监控**不支持**带有 Amazon EKS 混合节点功能的 Amazon EKS 集群以及在 AWS Fargate上运行的集群。 有关这些 Amazon EKS 功能的更多信息，请参阅《Amazon EKS 用户指南》****中的[什么是 Amazon EKS？](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) ## 验证架构要求 您使用的平台可能会影响 GuardDuty 安全代理支持 GuardDuty 从 EKS 集群接收运行时事件的方式。您必须验证自己使用的是其中一个经过验证的平台。如果您要手动管理 GuardDuty 代理，请确保 Kubernetes 版本支持当前正在使用的 GuardDuty 代理版本。 ### 经过验证的平台 操作系统分布、内核版本和 CPU 架构会影响 GuardDuty 安全代理提供的支持。内核支持包括 `eBPF`、`Tracepoints` 和 `Kprobe`。对于 CPU 架构，运行时监控支持 AMD64 (`x64`) 和 ARM64（Graviton2 及更高版本）。[1](#runtime-monitoring-eks-graviton-2-support) 下表显示了用于部署 GuardDuty 安全代理和配置 EKS 运行时监控的经过验证的配置。 | 操作系统分发 **[2](#runtime-monitoring-eks-os-support)** | 内核版本 **[3](#runtime-monitoring-eks-kernel-version-required-flag)** | 支持的 Kubernetes 版本 | | --- | --- | --- | | Bottlerocket | 5.4、5.10、5.15、6.1[4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.23-v1.35 | | Ubuntu | 5.4、5.10、5.15、6.1[4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.21-v1.35 | | Amazon Linux 2 | 5.4、5.10、5.15、6.1[4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.21-v1.35 | | 亚马逊 Linux 2023 *[5](#runtime-eks-al2023-support-v1.6.0)* | 5.4、5.10、5.15、6.1[4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.21-v1.35 | | RedHat 9.4 | 5.14 [4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.21-v1.35 | | Fedora 34 | 5.11、5,17 | v1.21-v1.35 | | Fedora 40 | 6.8 | v1.28-v1.35 | | Fedora 41 | 6.12 | v1.28-v1.35 | | CentOS Stream 9 | 5.14 | v1.21-v1.35 | 1. Amazon EKS 集群运行时监控不支持第一代 Graviton 实例，例如 A1 实例类型。 1. 对各种操作系统的支持- GuardDuty 已验证运行时监控支持上表中列出的操作发行版。虽然 GuardDuty 安全代理可以在上表中未列出的操作系统上运行，但该 GuardDuty 团队无法保证预期的安全值。 1. 对于任何内核版本，都必须将 `CONFIG_DEBUG_INFO_BTF` 标志设置为 `y`（含义为 *true*）。这是必需的，这样 GuardDuty 安全代理才能按预期运行。 1. 目前，在内核版本`6.1`中， GuardDuty 无法生成[GuardDuty 运行时监控查找类型](findings-runtime-monitoring.md)与之相关的内容[域名系统（DNS）事件](runtime-monitoring-collected-events.md#eks-runtime-dns-events)。 1. 运行时监控支持 AL2023 GuardDuty 安全代理 v1.6.0 及更高版本。有关更多信息，请参阅 [GuardDuty Amazon EKS 资源的安全代理版本](runtime-monitoring-agent-release-history.md#eks-runtime-monitoring-agent-release-history)。 #### 安全代理支持的 Kubernetes 版本 GuardDuty 下表显示了安全代理支持的 EKS 集群的 Kubernetes 版本。 GuardDuty | Amazon EKS 附加 GuardDuty 安全代理版本 | Kubernetes 版本 | | --- | --- | | v1.12.1（最新——v1.12.1-eksbuild.2） | 1.28-1.35 | | v1.11.0（最新版——v1.11.0-eksbuild.4） | 1.28-1.34 | | v1.10.0（最新 – v1.10.0-eksbuild.2） | 1.21-1.33 | | v1.9.0（最新 – v1.9.0-eksbuild.2） v1.8.1（最新 – v1.8.1-eksbuild.2） | 1.21-1.32 | | v1.7.1 v1.7.0 v1.6.1 | 1.21-1.31 | | v1.6.0 v1.5.0 v1.4.1 v1.4.0 v1.3.1 | 1.21-1.29 | | v1.3.0 v1.2.0 | 1.21-1.28 | | v1.1.0 | 1.21-1.26 | | v1.0.0 | 1.21 – 1.25 | 某些 GuardDuty 安全代理版本将终止标准支持。 有关代理发行版本的信息，请参阅[GuardDuty Amazon EKS 资源的安全代理版本](runtime-monitoring-agent-release-history.md#eks-runtime-monitoring-agent-release-history)。 ### CPU 和内存限制 下表显示了 GuardDuty (`aws-guardduty-agent`) 的 Amazon EKS 附加组件的 CPU 和内存限制。 | 参数 | 最小限制 | 最大限制 | | --- | --- | --- | | CPU | 200m | 1000m | | 内存 | 256Mi | 1024Mi | 当您使用 Amazon EKS 插件版本 1.5.0 或更高版本时， GuardDuty 可以为您的 CPU 和内存值配置插件架构。有关可配置范围的更多信息，请参阅[可配置的参数和值](guardduty-configure-security-agent-eks-addon.md#gdu-eks-addon-configure-parameters-values)。 启用 EKS 运行时监控并评测 EKS 集群的覆盖状态后，您可以设置和查看容器洞察指标。有关更多信息，请参阅 [设置 CPU 和内存监控](runtime-monitoring-setting-cpu-mem-monitoring.md)。 ## 验证组织服务控制策略 如果您设置了服务控制策略（SCP）来管理组织中的权限，请验证权限边界未限制 `guardduty:SendSecurityTelemetry`。它是支持跨不同资源类型的运行时监控所必需的。 GuardDuty 如果您是成员账户，则连接到关联的委派管理员。有关为您的组织 SCPs 进行管理的信息，请参阅[服务控制策略 (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)。