本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 啟用執行期監控的先決條件
若要啟用執行期監控和管理 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_tw/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 時
對於 Amazon ECS/Amazon EC2，我們建議您使用最新的 Amazon ECS 最佳化 AMIs (2023 年 9 月 29 日或更新版本），或使用 Amazon 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. 透過提供至少 32MB 的硬限制和軟`RLIMIT_MEMLOCK`限制來更新預設值。更新應如下所示：`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 管理，並在 [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) 主控台的 **Fleet 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%。
**Memory limit (記憶體限制)**
從與 Amazon EC2 執行個體相關聯的記憶體中，GuardDuty 安全代理程式可以使用的記憶體有限。
下表顯示記憶體限制。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/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 叢集接收執行期事件。您必須確認您使用的是經過驗證的平台之一。
**初始考量：**
Amazon 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支援各種作業系統 - 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)。如需詳細資訊，請參閱[託管 GuardDuty 代理程式的 Amazon ECR 儲存庫](runtime-monitoring-ecr-repository-gdu-agent.md)。
您可以使用 [AmazonECSTaskExecutionRolePolicy](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_execution_IAM_role.html) 受管政策，或將上述許可新增至`TaskExecutionRole`政策。
### 任務定義組態
建立或更新 Amazon ECS 服務時，您需要在任務定義中提供子網路資訊：
在 Amazon Elastic Container Service APIs 參考中執行 [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html) 和 [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) API 需要您傳遞子網路資訊。 **如需詳細資訊，請參閱《[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 使用者指南》中的為 Amazon ECR 建立 VPC 端點](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html#ecr-setting-up-vpc-create)。 **
如需有關啟用 Fargate 下載 GuardDuty 容器的資訊，請參閱[《Amazon Elastic Container Registry 使用者指南》中的搭配 Amazon ECS 使用 Amazon ECR 映像](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ECR_on_ECS.html)。 **
### 安全群組組態
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：//[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. 在左導覽窗格中，選取 **Policies (政策)**。然後，在**支援的政策類型**下，選取**服務控制政策**。
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 管理主控台 並開啟位於 https：//[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) 的 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_tw/guardduty/latest/ug/prereq-runtime-monitoring-ecs-support.html)
啟用執行期監控並評估叢集的涵蓋範圍狀態為**良好**之後，您可以設定和檢視容器洞見指標。如需詳細資訊，[在 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 Auto 模式上執行的 Amazon EKS 叢集。
執行期監控**不支援**具有 Amazon EKS 混合節點的 Amazon EKS 叢集，以及在其上執行的叢集 AWS Fargate。
如需有關這些 Amazon EKS 功能的資訊，請參閱《[Amazon EKS 使用者指南》中的什麼是](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) **Amazon EKS**？。
## 驗證架構需求
您使用的平台可能會影響 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 |
| Amazon 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 及更高版本。如需詳細資訊，請參閱[Amazon EKS 資源的 GuardDuty 安全代理程式版本](runtime-monitoring-agent-release-history.md#eks-runtime-monitoring-agent-release-history)。
#### GuardDuty 安全代理程式支援的 Kubernetes 版本
以下表格顯示 GuardDuty 安全代理程式所支援 EKS 叢集的 Kubernetes 版本。
| 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 1.7.0 版 1.6.1 版 | 1.21 - 1.31 |
| v1.6.0 1.5.0 版 1.4.1 版 1.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 安全代理程式版本將終止標準支援。
如需代理程式發行版本的資訊，請參閱 [Amazon EKS 資源的 GuardDuty 安全代理程式版本](runtime-monitoring-agent-release-history.md#eks-runtime-monitoring-agent-release-history)。
### CPU 和記憶體限制
以下表格顯示 GuardDuty (`aws-guardduty-agent`) 的 Amazon EKS 附加元件 CPU 和記憶體限制。
| 參數 | 下限 | 上限 |
| --- | --- | --- |
| CPU | 200 m | 1000 m |
| 記憶體 | 256 Mi | 1024 Mi |
當您使用 Amazon EKS 附加元件 1.5.0 版或更新版本時，GuardDuty 提供為您的 CPU 和記憶體值設定附加元件結構描述的功能。如需可設定範圍的資訊，請參閱 [可設定的參數和值](guardduty-configure-security-agent-eks-addon.md#gdu-eks-addon-configure-parameters-values)。
啟用 EKS 執行期監控並評估 EKS 叢集的涵蓋範圍狀態後，您可以設定和檢視 Container Insights 指標。如需詳細資訊，請參閱[設定 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)。