# Managing GuardDuty security agents You can manage the GuardDuty security agent for the resource that you want to monitor. If you want to monitor more than one resource type, make sure to manage the GuardDuty agent for that resource. The following topics will help you with the next steps to manage the security agent. **Topics** + [ # Enabling automated security agent for Amazon EC2 instance ](managing-gdu-agent-ec2-automated.md) + [ # Managing security agent manually for Amazon EC2 resource ](managing-gdu-agent-ec2-manually.md) + [ # Managing automated security agent for Fargate (Amazon ECS only) ](managing-gdu-agent-ecs-automated.md) + [ # Managing security agent automatically for Amazon EKS resources ](managing-gdu-agent-eks-automatically.md) + [ # Managing security agent manually for Amazon EKS cluster ](managing-gdu-agent-eks-manually.md) + [ # Configure GuardDuty security agent (add-on) parameters for Amazon EKS ](guardduty-configure-security-agent-eks-addon.md) + [ # Validating VPC endpoint configuration ](validate-vpc-endpoint-config-runtime-monitoring.md) # Enabling automated security agent for Amazon EC2 instance Automated agent on Amazon EC2 resource This section includes steps to enable GuardDuty automated agent for your Amazon EC2 resources in your standalone account or a multiple-account environment. Before you continue, make sure to follow all the [Prerequisites for Amazon EC2 instance support](prereq-runtime-monitoring-ec2-support.md). If you are migrating from managing the GuardDuty agent manually to enabling GuardDuty automated agent, then before following the steps to enable GuardDuty automated agent, see [Migrating from Amazon EC2 manual agent to automated agent](migrate-from-ec2-manual-to-automated-agent.md). # Enabling GuardDuty agent for Amazon EC2 resources in multiple-account environment Enabling GuardDuty agent in multiple-account environment In a multiple-account environments, only the delegated GuardDuty administrator account can enable or disable automated agent configuration for the resource types belonging to the member accounts in their organization. The GuardDuty member accounts can't modify this configuration from their accounts. The delegated GuardDuty administrator account account manages their member accounts using Amazon Organizations. For more information about multi-account environments, see [Managing multiple accounts](https://docs.amazonaws.cn/guardduty/latest/ug/guardduty_accounts.html). ## For delegated GuardDuty administrator account ------ #### [ Configure for all instances ] If you chose **Enable for all accounts** for Runtime Monitoring, then choose one of the following options for the delegated GuardDuty administrator account: + **Option 1** Under **Automated agent configuration**, in the **EC2** section, select **Enable for all accounts**. + **Option 2** + Under **Automated agent configuration**, in the **EC2** section, select **Configure accounts manually**. + Under **Delegated Administrator (this account)**, choose **Enable**. + Choose **Save**. If you chose **Configure accounts manually** for Runtime Monitoring, then perform the following steps: + Under **Automated agent configuration**, in the **EC2** section, select **Configure accounts manually**. + Under **Delegated Administrator (this account)**, choose **Enable**. + Choose **Save**. Regardless of which option you choose to enable the automated agent configuration for delegated GuardDuty administrator account, you can verify that the SSM association that GuardDuty creates will install and manage the security agent on all the EC2 resources belonging to this account. 1. Open the Amazon Systems Manager console at [https://console.amazonaws.cn/systems-manager/](https://console.amazonaws.cn/systems-manager/). 1. Open the **Targets** tab for the SSM association (`GuardDutyRuntimeMonitoring-do-not-delete`). Observe that the **Tag key** appears as **InstanceIds**. ------ #### [ Using inclusion tag in selected instances ] **To configure GuardDuty agent for selected Amazon EC2 instances** 1. Sign in to the Amazon Web Services Management Console and open the Amazon EC2 console at [https://console.amazonaws.cn/ec2/](https://console.amazonaws.cn/ec2/). 1. Add the `GuardDutyManaged`:`true` tag to the instances that you want GuardDuty to monitor and detect potential threats. For information about adding this tag, see [To add a tag to an individual resource](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags). Adding this tag will permit GuardDuty to install and manage the security agent for these selected EC2 instances. You **don't** need to enable automated agent configuration explicitly. 1. You can verify that the SSM association that GuardDuty creates will install and manage the security agent only on the EC2 resources that are tagged with the inclusion tags. Open the Amazon Systems Manager console at [https://console.amazonaws.cn/systems-manager/](https://console.amazonaws.cn/systems-manager/). 1. Open the **Targets** tab for the SSM association that gets created (`GuardDutyRuntimeMonitoring-do-not-delete`). The **Tag key** appears as **tag:GuardDutyManaged**. ------ #### [ Using exclusion tag in selected instances ] **Note** Ensure that you add the exclusion tag to your Amazon EC2 instances before you launch them. Once you have enabled automated agent configuration for Amazon EC2, any EC2 instance that launches without an exclusion tag will be covered under GuardDuty automated agent configuration. **To configure GuardDuty agent for selected Amazon EC2 instances** 1. Sign in to the Amazon Web Services Management Console and open the Amazon EC2 console at [https://console.amazonaws.cn/ec2/](https://console.amazonaws.cn/ec2/). 1. Add the `GuardDutyManaged`:`false` tag to the instances that you **don't** want GuardDuty to monitor and detect potential threats. For information about adding this tag, see [To add a tag to an individual resource](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags). 1. **For the [exclusion tags to be available](https://docs.amazonaws.cn/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html#general-runtime-monitoring-prereq-ec2) in the instance metadata, perform the following steps:** 1. Under the **Details** tab of your instance, view the status for **Allow tags in instance metadata**. If it is currently **Disabled**, use the following steps to change the status to **Enabled**. Otherwise, skip this step. 1. Under the **Actions** menu, choose **Instance settings**. 1. Choose **Allow tags in instance metadata**. 1. After you have added the exclusion tag, perform the same steps as specified in the **Configure for all instances** tab. ------ You can now assess the runtime [Runtime coverage and troubleshooting for Amazon EC2 instance](gdu-assess-coverage-ec2.md). ## Auto-enable for all member accounts **Note** It may take up to 24 hours to update the configuration for the member accounts. ------ #### [ Configure for all instances ] The following steps assume that you chose **Enable for all accounts** in the Runtime Monitoring section: 1. Choose **Enable for all accounts** in the **Automated agent configuration** section for **Amazon EC2**. 1. You can verify that the SSM association that GuardDuty creates (`GuardDutyRuntimeMonitoring-do-not-delete`) will install and manage the security agent on all the EC2 resources belonging to this account. 1. Open the Amazon Systems Manager console at [https://console.amazonaws.cn/systems-manager/](https://console.amazonaws.cn/systems-manager/). 1. Open the **Targets** tab for the SSM association. Observe that the **Tag key** appears as **InstanceIds**. ------ #### [ Using inclusion tag in selected instances ] **To configure GuardDuty agent for selected Amazon EC2 instances** 1. Sign in to the Amazon Web Services Management Console and open the Amazon EC2 console at [https://console.amazonaws.cn/ec2/](https://console.amazonaws.cn/ec2/). 1. Add the `GuardDutyManaged`:`true` tag to the EC2 instances that you want GuardDuty to monitor and detect potential threats. For information about adding this tag, see [To add a tag to an individual resource](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags). Adding this tag will permit GuardDuty to install and manage the security agent for these selected EC2 instances. You **don't ** need to enable automated agent configuration explicitly. 1. You can verify that the SSM association that GuardDuty creates will install and manage the security agent on all the EC2 resources belonging to your account. 1. Open the Amazon Systems Manager console at [https://console.amazonaws.cn/systems-manager/](https://console.amazonaws.cn/systems-manager/). 1. Open the **Targets** tab for the SSM association (`GuardDutyRuntimeMonitoring-do-not-delete`). Observe that the **Tag key** appears as **InstanceIds**. ------ #### [ Using exclusion tag in selected instances ] **Note** Ensure that you add the exclusion tag to your Amazon EC2 instances before you launch them. Once you have enabled automated agent configuration for Amazon EC2, any EC2 instance that launches without an exclusion tag will be covered under GuardDuty automated agent configuration. **To configure GuardDuty security agent for selected Amazon EC2 instances** 1. Sign in to the Amazon Web Services Management Console and open the Amazon EC2 console at [https://console.amazonaws.cn/ec2/](https://console.amazonaws.cn/ec2/). 1. Add the `GuardDutyManaged`:`false` tag to the instances that you **don't** want GuardDuty to monitor and detect potential threats. For information about adding this tag, see [To add a tag to an individual resource](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags). 1. **For the [exclusion tags to be available](https://docs.amazonaws.cn/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html#general-runtime-monitoring-prereq-ec2) in the instance metadata, perform the following steps:** 1. Under the **Details** tab of your instance, view the status for **Allow tags in instance metadata**. If it is currently **Disabled**, use the following steps to change the status to **Enabled**. Otherwise, skip this step. 1. Under the **Actions** menu, choose **Instance settings**. 1. Choose **Allow tags in instance metadata**. 1. After you have added the exclusion tag, perform the same steps as specified in the **Configure for all instances** tab. ------ You can now assess the runtime [Runtime coverage and troubleshooting for Amazon EC2 instance](gdu-assess-coverage-ec2.md). ## Auto-enable for new member accounts only The delegated GuardDuty administrator account can set the automated agent configuration for Amazon EC2 resource to enable automatically for the new member accounts as they join the organization. ------ #### [ Configure for all instances ] The following steps assume that you selected **Automatically enable for new member accounts** under the **Runtime Monitoring** section: 1. In the navigation pane, choose **Runtime Monitoring**. 1. On the **Runtime Monitoring** page, choose **Edit**. 1. Select **Automatically enable for new member accounts**. This step ensures that whenever a new account joins your organization, automated agent configuration for Amazon EC2 will be automatically enabled for their account. Only the delegated GuardDuty administrator account of the organization can modify this selection. 1. Choose **Save**. When a new member account joins the organization, this configuration will be enabled for them automatically. For GuardDuty to manage the security agent for the Amazon EC2 instances that belong to this new member account, make sure that all the prerequisites [For EC2 instance](prereq-runtime-monitoring-ec2-support.md) are met. When an SSM association gets created (`GuardDutyRuntimeMonitoring-do-not-delete`), you can verify that the SSM association will install and manage the security agent on all the EC2 instances belonging to the new member account. + Open the Amazon Systems Manager console at [https://console.amazonaws.cn/systems-manager/](https://console.amazonaws.cn/systems-manager/). + Open the **Targets** tab for the SSM association. Observe that the **Tag key** appears as **InstanceIds**. ------ #### [ Using inclusion tag in selected instances ] **To configure GuardDuty security agent for selected instances in your account** 1. Sign in to the Amazon Web Services Management Console and open the Amazon EC2 console at [https://console.amazonaws.cn/ec2/](https://console.amazonaws.cn/ec2/). 1. Add the `GuardDutyManaged`:`true` tag to the instances that you want GuardDuty to monitor and detect potential threats. For information about adding this tag, see [To add a tag to an individual resource](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags). Adding this tag will permit GuardDuty to install and manage the security agent for these selected instances. You don't need to enable automated agent configuration explicitly. 1. You can verify that the SSM association that GuardDuty creates will install and manage the security agent only on the EC2 resources that are tagged with the inclusion tags. 1. Open the Amazon Systems Manager console at [https://console.amazonaws.cn/systems-manager/](https://console.amazonaws.cn/systems-manager/). 1. Open the **Targets** tab for the SSM association that gets created. The **Tag key** appears as **tag:GuardDutyManaged**. ------ #### [ Using exclusion tag in selected instances ] **Note** Ensure that you add the exclusion tag to your Amazon EC2 instances before you launch them. Once you have enabled automated agent configuration for Amazon EC2, any EC2 instance that launches without an exclusion tag will be covered under GuardDuty automated agent configuration. **To configure GuardDuty security agent for specific instances in your standalone account** 1. Sign in to the Amazon Web Services Management Console and open the Amazon EC2 console at [https://console.amazonaws.cn/ec2/](https://console.amazonaws.cn/ec2/). 1. Add the `GuardDutyManaged`:`false` tag to the instances that you **don't** want GuardDuty to monitor and detect potential threats. For information about adding this tag, see [To add a tag to an individual resource](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags). 1. **For the [exclusion tags to be available](https://docs.amazonaws.cn/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html#general-runtime-monitoring-prereq-ec2) in the instance metadata, perform the following steps:** 1. Under the **Details** tab of your instance, view the status for **Allow tags in instance metadata**. If it is currently **Disabled**, use the following steps to change the status to **Enabled**. Otherwise, skip this step. 1. Under the **Actions** menu, choose **Instance settings**. 1. Choose **Allow tags in instance metadata**. 1. After you have added the exclusion tag, perform the same steps as specified in the **Configure for all instances** tab. ------ You can now assess the runtime [Runtime coverage and troubleshooting for Amazon EC2 instance](gdu-assess-coverage-ec2.md). ## Selective member accounts only ------ #### [ Configure for all instances ] 1. On the **Accounts** page, select one or more accounts for which you want to enable **Runtime Monitoring-Automated agent configuration (Amazon EC2)**. Make sure that the accounts that you select in this step already have Runtime Monitoring enabled. 1. From **Edit protection plans**, choose the appropriate option to enable **Runtime Monitoring-Automated agent configuration (Amazon EC2)**. 1. Choose **Confirm**. ------ #### [ Using inclusion tag in selected instances ] **To configure GuardDuty security agent for selected instances** 1. Sign in to the Amazon Web Services Management Console and open the Amazon EC2 console at [https://console.amazonaws.cn/ec2/](https://console.amazonaws.cn/ec2/). 1. Add the `GuardDutyManaged`:`true` tag to the instances that you want GuardDuty to monitor and detect potential threats. For information about adding this tag, see [To add a tag to an individual resource](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags). Adding this tag will permit GuardDuty to manage the security agent for your tagged Amazon EC2 instances. You don't need to explicitly enable automated agent configuration (**Runtime Monitoring - Automated agent configuration (EC2)**. ------ #### [ Using exclusion tag in selected instances ] **Note** Ensure that you add the exclusion tag to your Amazon EC2 instances before you launch them. Once you have enabled automated agent configuration for Amazon EC2, any EC2 instance that launches without an exclusion tag will be covered under GuardDuty automated agent configuration. **To configure GuardDuty security agent for selected instances** 1. Sign in to the Amazon Web Services Management Console and open the Amazon EC2 console at [https://console.amazonaws.cn/ec2/](https://console.amazonaws.cn/ec2/). 1. Add the `GuardDutyManaged`:`false` tag to the EC2 instances that you **don't** want GuardDuty to monitor or detect potential threats. For information about adding this tag, see [To add a tag to an individual resource](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags). 1. **For the [exclusion tags to be available](https://docs.amazonaws.cn/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html#general-runtime-monitoring-prereq-ec2) in the instance metadata, perform the following steps:** 1. Under the **Details** tab of your instance, view the status for **Allow tags in instance metadata**. If it is currently **Disabled**, use the following steps to change the status to **Enabled**. Otherwise, skip this step. 1. Under the **Actions** menu, choose **Instance settings**. 1. Choose **Allow tags in instance metadata**. 1. After you have added the exclusion tag, perform the same steps as specified in the **Configure for all instances** tab. ------ You can now assess [Runtime coverage and troubleshooting for Amazon EC2 instance](gdu-assess-coverage-ec2.md). # Enabling GuardDuty automated agent for Amazon EC2 resources in a standalone account Enabling GuardDuty automated agent in a standalone account A standalone account owns the decision to enable or disable a protection plan in their Amazon Web Services account in a specific Amazon Web Services Region. If your account is associated with a GuardDuty administrator account through Amazon Organizations, or by the method of invitation, this section doesn't apply to your account. For more information, see [Enabling Runtime Monitoring for multiple-account environments](enable-runtime-monitoring-multiple-acc-env.md). After you enable Runtime Monitoring, ensure to install GuardDuty security agent through automated configuration or manual deployment. As a part of completing all the steps listed in the following procedure, make sure to install the security agent. Based on your preference to monitor all or selective Amazon EC2 resources, choose a preferred method and follow the steps in the following table. ------ #### [ Configure for all instances ] **To configure Runtime Monitoring for all instances in your standalone account** 1. Sign in to the Amazon Web Services Management Console and open the GuardDuty console at [https://console.amazonaws.cn/guardduty/](https://console.amazonaws.cn/guardduty/). 1. In the navigation pane, choose **Runtime Monitoring**. 1. Under the **Configuration** tab, choose **Edit**. 1. In the **EC2** section, choose **Enable**. 1. Choose **Save**. 1. You can verify that the SSM association that GuardDuty creates will install and manage the security agent on all the EC2 resources belonging to your account. 1. Open the Amazon Systems Manager console at [https://console.amazonaws.cn/systems-manager/](https://console.amazonaws.cn/systems-manager/). 1. Open the **Targets** tab for the SSM association (`GuardDutyRuntimeMonitoring-do-not-delete`). Observe that the **Tag key** appears as **InstanceIds**. ------ #### [ Using inclusion tag in selected instances ] **To configure GuardDuty security agent for selected Amazon EC2 instances** 1. Sign in to the Amazon Web Services Management Console and open the Amazon EC2 console at [https://console.amazonaws.cn/ec2/](https://console.amazonaws.cn/ec2/). 1. Add the `GuardDutyManaged`:`true` tag to the instances that you want GuardDuty to monitor and detect potential threats. For information about adding this tag, see [To add a tag to an individual resource](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags). 1. You can verify that the SSM association that GuardDuty creates will install and manage the security agent only on the EC2 resources that are tagged with the inclusion tags. Open the Amazon Systems Manager console at [https://console.amazonaws.cn/systems-manager/](https://console.amazonaws.cn/systems-manager/). 1. Open the **Targets** tab for the SSM association that gets created (`GuardDutyRuntimeMonitoring-do-not-delete`). The **Tag key** appears as **tag:GuardDutyManaged**. ------ #### [ Using exclusion tag in selected instances ] **Note** Ensure that you add the exclusion tag to your Amazon EC2 instances before you launch them. Once you have enabled automated agent configuration for Amazon EC2, any EC2 instance that launches without an exclusion tag will be covered under GuardDuty automated agent configuration. **To configure GuardDuty security agent for selected Amazon EC2 instances** 1. Sign in to the Amazon Web Services Management Console and open the Amazon EC2 console at [https://console.amazonaws.cn/ec2/](https://console.amazonaws.cn/ec2/). 1. Add the `GuardDutyManaged`:`false` tag to the instances that you **don't** want GuardDuty to monitor and detect potential threats. For information about adding this tag, see [To add a tag to an individual resource](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags). 1. **For the [exclusion tags to be available](https://docs.amazonaws.cn/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html#general-runtime-monitoring-prereq-ec2) in the instance metadata, perform the following steps:** 1. Under the **Details** tab of your instance, view the status for **Allow tags in instance metadata**. If it is currently **Disabled**, use the following steps to change the status to **Enabled**. Otherwise, skip this step. 1. Select the instance for which you want to allow tags. 1. Under the **Actions** menu, choose **Instance settings**. 1. Choose **Allow tags in instance metadata**. 1. Under **Access to tags in instance metadata**, select **Allow**. 1. Choose **Save**. 1. After you have added the exclusion tag perform the same steps as sepcified in the **Configure for all instances** tab. ------ You can now assess runtime [Runtime coverage and troubleshooting for Amazon EC2 instance](gdu-assess-coverage-ec2.md). # Migrating from Amazon EC2 manual agent to automated agent This section applies to your Amazon Web Services account if you were previously managing the security agent manually and now want to use the GuardDuty automated agent configuration. If this doesn't apply to you, continue with configuring the security agent for your account. When you enable GuardDuty automated agent, GuardDuty manages the security agent on your behalf. For information about what steps does GuardDuty take, see [Use automated agent configuration (recommended)](how-runtime-monitoring-works-ec2.md#use-automated-agent-config-ec2). ## Clean up resources **Delete SSM association** + Delete any SSM association that you may have created when you were managing the security agent for Amazon EC2 manually. For more information, see [Deleting associations](https://docs.amazonaws.cn/systems-manager/latest/userguide/systems-manager-state-manager-delete-association.html). + This is done so that GuardDuty can take over the management of SSM actions whether you use automated agents at the account level or instance level (by using inclusion or exclusion tags). For more information about what SSM actions can GuardDuty take, see [Service-linked role permissions for GuardDuty](slr-permissions.md). + When you delete an SSM association that was previously created for managing the security agent manually, there might be a brief period of overlap when GuardDuty creates an SSM association for managing the security agent automatically. During this period, you could experience conflicts based on SSM scheduling. For more information, see [Amazon EC2 SSM scheduling](https://docs.amazonaws.cn/systems-manager/latest/userguide/quick-setup-scheduler.html). **Manage inclusion and exclusion tags for your Amazon EC2 instances** + **Inclusion tags** – When you don't enable GuardDuty automated agent configuration but tag any of your Amazon EC2 instances with an inclusion tag (`GuardDutyManaged`:`true`), GuardDuty creates an SSM association that will install and manage the security agent on the selected EC2 instances. This is an expected behavior that helps you manage the security agent on selected EC2 instances only. For more information, see [How Runtime Monitoring works with Amazon EC2 instances](how-runtime-monitoring-works-ec2.md). To prevent GuardDuty from installing and managing the security agent, remove the inclusion tag from these EC2 instances. For more information, see [Add and delete tags](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags) in the *Amazon EC2 User Guide*. + **Exclusion tags** – When you want to enable GuardDuty automated agent configuration for all the EC2 instances in your account, make sure that no EC2 instance is tagged with an exclusion tag (`GuardDutyManaged`:`false`). # Managing security agent manually for Amazon EC2 resource Manual agent management for Amazon EC2 resource This section provides the steps to manually install and update the security agent for your Amazon EC2 resources. After you enable Runtime Monitoring, you will need to install the GuardDuty security agent manually. To manage the GuardDuty security agent manually, you must first create an Amazon VPC endpoint manually. After this, you can install the security agent so that GuardDuty will start receiving the runtime events from the Amazon EC2 instances. When GuardDuty releases a new agent version for this resource, you can update the agent version in your account. The following topics include the steps to continuously manage the security agent for your Amazon EC2 resources. **Topics** + [ # Prerequisite – Creating Amazon VPC endpoint manually ](creating-vpc-endpoint-ec2-agent-manually.md) + [ # Installing the security agent manually ](installing-gdu-security-agent-ec2-manually.md) + [ # Updating the GuardDuty security agent for Amazon EC2 instance manually ](gdu-update-security-agent-ec2.md) # Prerequisite – Creating Amazon VPC endpoint manually Before you can install the GuardDuty security agent, you must create an Amazon Virtual Private Cloud (Amazon VPC) endpoint. This will help GuardDuty receive the runtime events of your Amazon EC2 instances. **Note** There is no additional cost for the usage of the VPC endpoint. **To create a Amazon VPC endpoint** 1. Sign in to the Amazon Web Services Management Console and open the Amazon VPC console at [https://console.amazonaws.cn/vpc/](https://console.amazonaws.cn/vpc/). 1. In the navigation pane, under **VPC private cloud**, choose **Endpoints**. 1. Choose **Create Endpoint**. 1. On the **Create endpoint** page, for **Service category**, choose **Other endpoint services**. 1. For **Service name**, enter **com.amazonaws.*us-east-1*.guardduty-data**. Make sure to replace *us-east-1* with your Amazon Web Services Region. This must be the same Region as the Amazon EC2 instance that belongs to your Amazon account ID. 1. Choose **Verify service**. 1. After the service name is successfully verified, choose the **VPC** where your instance resides. Add the following policy to restrict Amazon VPC endpoint usage to the specified account only. With the organization `Condition` provided below this policy, you can update the following policy to restrict access to your endpoint. To provide the Amazon VPC endpoint support to specific account IDs in your organization, see [Organization condition to restrict access to your endpoint](#gdu-runtime-ec2-organization-restrict-access-vpc-endpoint). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": "*", "Resource": "*", "Effect": "Allow", "Principal": "*" }, { "Condition": { "StringNotEquals": { "aws:PrincipalAccount": "111122223333" } }, "Action": "*", "Resource": "*", "Effect": "Deny", "Principal": "*" } ] } ``` ------ The `aws:PrincipalAccount` account ID must match the account containing the VPC and VPC endpoint. The following list shows how to share the VPC endpoint with other Amazon account IDs: + To specify multiple accounts to access the VPC endpoint, replace `"aws:PrincipalAccount: "111122223333"` with the following block: ``` "aws:PrincipalAccount": [ "666666666666", "555555555555" ] ``` Make sure to replace the Amazon account IDs with the account IDs of those accounts that need to access the VPC endpoint. + To allow all the members from an organization to access the VPC endpoint, replace `"aws:PrincipalAccount: "111122223333"` with the following line: ``` "aws:PrincipalOrgID": "o-abcdef0123" ``` Make sure to replace the organization *o-abcdef0123* with your organization ID. + To restrict accessing a resource by an organization ID, add your `ResourceOrgID` to the policy. For more information, see [https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceorgid](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceorgid) in the *IAM User Guide*. ``` "aws:ResourceOrgID": "o-abcdef0123" ``` 1. Under **Additional settings**, choose **Enable DNS name**. 1. Under **Subnets**, choose the subnets in which your instance resides. 1. Under **Security groups**, choose a security group that has the in-bound port 443 enabled from your VPC (or your Amazon EC2 instance). If you don't already have a security group that has an in-bound port 443 enabled, see [Create a security group for your VPC](https://docs.amazonaws.cn/vpc/latest/userguide/creating-security-groups.html) in the *Amazon VPC User Guide*. If there is an issue while restricting the in-bound permissions to your VPC (or instance), you can the in-bound 443 port from any IP address `(0.0.0.0/0)`. However, GuardDuty recommends using IP addresses that matches the CIDR block for your VPC. For more information, see [VPC CIDR blocks](https://docs.amazonaws.cn//vpc/latest/userguide/vpc-cidr-blocks.html) in the *Amazon VPC User Guide*. After you have followed the steps, see [Validating VPC endpoint configuration](validate-vpc-endpoint-config-runtime-monitoring.md) to ensure that the VPC endpoint was set up correctly. # Installing the security agent manually GuardDuty provides the following two methods to install the GuardDuty security agent on your Amazon EC2 instances. Before proceeding, make sure to follow the steps under [Prerequisite – Creating Amazon VPC endpoint manually](creating-vpc-endpoint-ec2-agent-manually.md). Choose a preferred access method to install the security agent in your Amazon EC2 resources. + [Method 1 - Using Amazon Systems Manager](#install-gdu-by-using-sys-runtime-monitoring) – This method requires your Amazon EC2 instance to be Amazon Systems Manager managed. + [Method 2 - Using Linux Package Managers](#install-gdu-by-rpm-scripts-runtime-monitoring) – You can use this method whether or not your Amazon EC2 instances are Amazon Systems Manager managed. Based on your [OS distributions](https://docs.amazonaws.cn/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html#validating-architecture-req-ec2), you can choose an appropriate method to install either RPM scripts or Debian scripts. If you use *Fedora* platform, then you must use this method to install the agent. ## Method 1 - Using Amazon Systems Manager To use this method, make sure that your Amazon EC2 instances are Amazon Systems Manager managed and then install the agent. ### Amazon Systems Manager managed Amazon EC2 instance Use the following steps to make your Amazon EC2 instances Amazon Systems Manager managed. + [Amazon Systems Manager](https://docs.amazonaws.cn/systems-manager/latest/userguide/what-is-systems-manager.html) helps you manage your Amazon applications and resources end-to-end and enable secure operations at scale. To manage your Amazon EC2 instances with Amazon Systems Manager, see [Setting up Systems Manager for Amazon EC2 instances](https://docs.amazonaws.cn/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html) in the *Amazon Systems Manager User Guide*. + The following table shows the new GuardDuty managed Amazon Systems Manager documents: [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/guardduty/latest/ug/installing-gdu-security-agent-ec2-manually.html) For more information about Amazon Systems Manager, see [Amazon EC2 Systems Manager Documents](https://docs.amazonaws.cn/systems-manager/latest/userguide/documents.html) in the *Amazon Systems Manager User Guide*. **For Debian Servers** The Amazon Machine Images (AMIs) for Debian Server provided by Amazon require you to install the Amazon Systems Manager agent (SSM agent). You will need to perform an additional step to install the SSM agent to make your Amazon EC2 Debian Server instances SSM managed. For information about steps that you need to take, see [Manually installing SSM agent on Debian Server instances](https://docs.amazonaws.cn/systems-manager/latest/userguide/agent-install-deb.html) in the *Amazon Systems Manager User Guide*. **To install the GuardDuty agent for Amazon EC2 instance by using Amazon Systems Manager** 1. Open the Amazon Systems Manager console at [https://console.amazonaws.cn/systems-manager/](https://console.amazonaws.cn/systems-manager/). 1. In the navigation pane, choose **Documents** 1. In **Owned by Amazon**, choose `AmazonGuardDuty-ConfigureRuntimeMonitoringSsmPlugin`. 1. Choose **Run Command**. 1. Enter the following Run Command parameters + Action: Choose **Install**. + Installation Type: Choose **Install or Uninstall.** + Name: `AmazonGuardDuty-RuntimeMonitoringSsmPlugin` + Version: If this remains empty, you'll get latest version of the GuardDuty security agent. For more information about the release versions, [GuardDuty security agent versions for Amazon EC2 instances](runtime-monitoring-agent-release-history.md#ec2-gdu-agent-release-history). 1. Select the targeted Amazon EC2 instance. You can select one or more Amazon EC2 instances. For more information, see [Amazon Systems Manager Running commands from the console](https://docs.amazonaws.cn/systems-manager/latest/userguide/running-commands-console.html) in the *Amazon Systems Manager User Guide* 1. Validate if the GuardDuty agent installation is healthy. For more information, see [Validating GuardDuty security agent installation status](#validate-ec2-gdu-agent-installation-healthy). ## Method 2 - Using Linux Package Managers With this method, you can install the GuardDuty security agent by running RPM scripts or Debian scripts. Based on the operating systems, you can choose a preferred method: + Use RPM scripts to install the security agent on OS distributions AL2, AL2023, RedHat, CentOS, or Fedora. + Use Debian scripts to install the security agent on OS distributions Ubuntu or Debian. For information about supported Ubuntu and Debian OS distributions, see [Validate architectural requirements](prereq-runtime-monitoring-ec2-support.md#validating-architecture-req-ec2). ------ #### [ RPM installation ] **Important** We recommend verifying the GuardDuty security agent RPM signature before installing it on your machine. 1. Verify the GuardDuty security agent RPM signature 1. **Prepare the template** Prepare the commands with appropriate public key, signature of x86\$164 RPM, signature of arm64 RPM, and the corresponding access link to the RPM scripts hosted in Amazon S3 buckets. Replace the value of the Amazon Web Services Region, Amazon account ID, and the GuardDuty agent version to access the RPM scripts. + **Public key**: ``` s3://694911143906-eu-west-1-guardduty-agent-rpm-artifacts/1.9.2/publickey.pem ``` + **GuardDuty security agent RPM signature**: Signature of x86\$164 RPM ``` s3://694911143906-eu-west-1-guardduty-agent-rpm-artifacts/1.9.2/x86_64/amazon-guardduty-agent-1.9.2.x86_64.sig ``` Signature of arm64 RPM ``` s3://694911143906-eu-west-1-guardduty-agent-rpm-artifacts/1.9.2/arm64/amazon-guardduty-agent-1.9.2.arm64.sig ``` + **Access links to the RPM scripts in Amazon S3 bucket**: Access link for x86\$164 RPM ``` s3://694911143906-eu-west-1-guardduty-agent-rpm-artifacts/1.9.2/x86_64/amazon-guardduty-agent-1.9.2.x86_64.rpm ``` Access link for arm64 RPM ``` s3://694911143906-eu-west-1-guardduty-agent-rpm-artifacts/1.9.2/arm64/amazon-guardduty-agent-1.9.2.arm64.rpm ``` [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/guardduty/latest/ug/installing-gdu-security-agent-ec2-manually.html) 1. **Download the template** In the following command to download appropriate public key, signature of x86\$164 RPM, signature of arm64 RPM, and the corresponding access link to the RPM scripts hosted in Amazon S3 buckets, make sure to replace the account ID with the appropriate Amazon Web Services account ID and the Region with your current Region. ``` aws s3 cp s3://694911143906-eu-west-1-guardduty-agent-rpm-artifacts/1.9.2/x86_64/amazon-guardduty-agent-1.9.2.x86_64.rpm ./amazon-guardduty-agent-1.9.2.x86_64.rpm aws s3 cp s3://694911143906-eu-west-1-guardduty-agent-rpm-artifacts/1.9.2/x86_64/amazon-guardduty-agent-1.9.2.x86_64.sig ./amazon-guardduty-agent-1.9.2.x86_64.sig aws s3 cp s3://694911143906-eu-west-1-guardduty-agent-rpm-artifacts/1.9.2/publickey.pem ./publickey.pem ``` 1. **Import the public key** Use the following command to import the public key to the database: ``` gpg --import publickey.pem ``` gpg shows import successfully ``` gpg: key 093FF49D: public key "AwsGuardDuty" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) ``` 1. **Verify the signature** Use the following command to verify the signature ``` gpg --verify amazon-guardduty-agent-1.9.2.x86_64.sig amazon-guardduty-agent-1.9.2.x86_64.rpm ``` If verification passes, you will see a message similar to the result below. You can now proceed to install the GuardDuty security agent using RPM. Example output: ``` gpg: Signature made Fri 17 Nov 2023 07:58:11 PM UTC using ? key ID 093FF49D gpg: Good signature from "AwsGuardDuty" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 7478 91EF 5378 1334 4456 7603 06C9 06A7 093F F49D ``` If verification fails, it means the signature on RPM has been potentially tampered. You must remove the public key from the database and retry the verification process. Example: ``` gpg: Signature made Fri 17 Nov 2023 07:58:11 PM UTC using ? key ID 093FF49D gpg: BAD signature from "AwsGuardDuty" ``` Use the following command to remove the public key from the database: ``` gpg --delete-keys AwsGuardDuty ``` Now, try the verification process again. 1. [Connect with SSH from Linux or macOS](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/connect-linux-inst-ssh.html). 1. Install the GuardDuty security agent by using the following command: ``` sudo rpm -ivh amazon-guardduty-agent-1.9.2.x86_64.rpm ``` 1. Validate if the GuardDuty agent installation is healthy. For more information about the steps, see [Validating GuardDuty security agent installation status](#validate-ec2-gdu-agent-installation-healthy). ------ #### [ Debian installation ] **Important** We recommend verifying the GuardDuty security agent Debian signature before installing it on your machine. 1. Verify the GuardDuty security agent Debian signature 1. **Prepare templates for the appropriate public key, signature of amd64 Debian package, signature of arm64 Debian package, and the corresponding access link to the Debian scripts hosted in Amazon S3 buckets** In the following templates, replace the value of the Amazon Web Services Region, Amazon account ID, and the GuardDuty agent version to access the Debian package scripts. + **Public key**: ``` s3://694911143906-eu-west-1-guardduty-agent-deb-artifacts/1.9.2/publickey.pem ``` + **GuardDuty security agent Debian signature**: Signature of amd64 ``` s3://694911143906-eu-west-1-guardduty-agent-deb-artifacts/1.9.2/amd64/amazon-guardduty-agent-1.9.2.amd64.sig ``` Signature of arm64 ``` s3://694911143906-eu-west-1-guardduty-agent-deb-artifacts/1.9.2/arm64/amazon-guardduty-agent-1.9.2.arm64.sig ``` + **Access links to the Debian scripts in Amazon S3 bucket**: Access link for amd64 ``` s3://694911143906-eu-west-1-guardduty-agent-deb-artifacts/1.9.2/amd64/amazon-guardduty-agent-1.9.2.amd64.deb ``` Access link for arm64 ``` s3://694911143906-eu-west-1-guardduty-agent-deb-artifacts/1.9.2/arm64/amazon-guardduty-agent-1.9.2.arm64.deb ``` [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/guardduty/latest/ug/installing-gdu-security-agent-ec2-manually.html) 1. **Download the appropriate public key, signature of amd64, signature of arm64, and the corresponding access link to the Debian scripts hosted in Amazon S3 buckets** In the following commands, replace the account ID with the appropriate Amazon Web Services account ID, and the Region with your current Region. ``` aws s3 cp s3://694911143906-eu-west-1-guardduty-agent-deb-artifacts/1.9.2/amd64/amazon-guardduty-agent-1.9.2.amd64.deb ./amazon-guardduty-agent-1.9.2.amd64.deb aws s3 cp s3://694911143906-eu-west-1-guardduty-agent-deb-artifacts/1.9.2/amd64/amazon-guardduty-agent-1.9.2.amd64.sig ./amazon-guardduty-agent-1.9.2.amd64.sig aws s3 cp s3://694911143906-eu-west-1-guardduty-agent-deb-artifacts/1.9.2/publickey.pem ./publickey.pem ``` 1. Import the public key to the database ``` gpg --import publickey.pem ``` gpg shows import successfully ``` gpg: key 093FF49D: public key "AwsGuardDuty" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) ``` 1. Verify the signature ``` gpg --verify amazon-guardduty-agent-1.9.2.amd64.sig amazon-guardduty-agent-1.9.2.amd64.deb ``` After a successful verification, you will see a message similar to the following result: Example output: ``` gpg: Signature made Fri 17 Nov 2023 07:58:11 PM UTC using ? key ID 093FF49D gpg: Good signature from "AwsGuardDuty" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 7478 91EF 5378 1334 4456 7603 06C9 06A7 093F F49D ``` You can now proceed to install the GuardDuty security agent using Debian. However, if verification fails, it means the signature in Debian package has been potentially tampered. Example: ``` gpg: Signature made Fri 17 Nov 2023 07:58:11 PM UTC using ? key ID 093FF49D gpg: BAD signature from "AwsGuardDuty" ``` Use the following command to remove the public key from the database: ``` gpg --delete-keys AwsGuardDuty ``` Now, retry the verification process. 1. [Connect with SSH from Linux or macOS](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/connect-linux-inst-ssh.html). 1. Install the GuardDuty security agent by using the following command: ``` sudo dpkg -i amazon-guardduty-agent-1.9.2.amd64.deb ``` 1. Validate if the GuardDuty agent installation is healthy. For more information about the steps, see [Validating GuardDuty security agent installation status](#validate-ec2-gdu-agent-installation-healthy). ------ ## Out of memory error If you experience an `out-of-memory` error while installing or updating the GuardDuty security agent for Amazon EC2 manually, see [Troubleshooting out of memory error](troubleshooting-guardduty-runtime-monitoring.md#troubleshoot-ec2-cpu-out-of-memory-error). ## Validating GuardDuty security agent installation status After you have performed the steps to install the GuardDuty security agent, use the following steps to validate the status of the agent: **To validate if the GuardDuty security agent is healthy** 1. [Connect with SSH from Linux or macOS](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/connect-linux-inst-ssh.html). 1. Run the following command to check the status of the GuardDuty security agent: ``` sudo systemctl status amazon-guardduty-agent ``` If you want to view the security agent installation logs, they are available under `/var/log/amzn-guardduty-agent/`. To view the logs, do `sudo journalctl -u amazon-guardduty-agent`. # Updating the GuardDuty security agent for Amazon EC2 instance manually Updating security agent manually GuardDuty releases updates to the security agent versions. When you manage the security agent manually, you're responsible to update the agent for your Amazon EC2 instances. For information about new agent versions, see [GuardDuty security agent release versions](runtime-monitoring-agent-release-history.md) for Amazon EC2 instances. To receive notifications about a new agent version release, see [Subscribing to Amazon SNS GuardDuty announcements](guardduty_sns.md). **To update the security agent for Amazon EC2 instance manually** The process to update the security agent is the same as installing the security agent. Depending on the method that you used to install the agent, you can perform the steps in [Installing the security agent manually](installing-gdu-security-agent-ec2-manually.md) for Amazon EC2 instances. If you use [Method 1 - By using Amazon Systems Manager](https://docs.amazonaws.cn/guardduty/latest/ug/managing-gdu-agent-ec2-manually.html#manage-ssm-ec2-instance-runtime-monitoring), then you can update the security agent by using the **Run command**. Use the agent version to which you want to update. If you use [Method 2 - By using Linux Package Managers](https://docs.amazonaws.cn/guardduty/latest/ug/managing-gdu-agent-ec2-manually.html#heading:r2l:), you can use the scripts as specified in the [Installing the security agent manually](installing-gdu-security-agent-ec2-manually.md) section. The scripts already include the latest agent release version. For information about recently released agent versions, see [GuardDuty security agent versions for Amazon EC2 instances](runtime-monitoring-agent-release-history.md#ec2-gdu-agent-release-history). After you update the security agent, you can check the installation status by looking at the logs. For more information, see [Validating GuardDuty security agent installation status](installing-gdu-security-agent-ec2-manually.md#validate-ec2-gdu-agent-installation-healthy). # Managing automated security agent for Fargate (Amazon ECS only) Automated agent on Fargate (Amazon ECS only) Runtime Monitoring supports managing the security agent for your Amazon ECS clusters (Amazon Fargate) only through GuardDuty. There is no support for managing the security agent manually on Amazon ECS clusters. Before proceeding with the steps in this section, make sure to follow [Prerequisites for Amazon Fargate (Amazon ECS only) support](prereq-runtime-monitoring-ecs-support.md). Based on the [Approaches to manage GuardDuty security agent in Amazon ECS-Fargate resources](how-runtime-monitoring-works-ecs-fargate.md#gdu-runtime-approaches-agent-deployment-ecs-clusters), choose a preferred method to enable GuardDuty automated agent for your resources. **Topics** ## Configuring GuardDuty agent for multi-account environment In a multiple-account environment, only the delegated GuardDuty administrator account can enable or disable automated agent configuration for the member accounts, and manage automated agent configuration for Amazon ECS clusters that belong to the member accounts in their organization. A GuardDuty member account can't modify this configuration. The delegated GuardDuty administrator account manages their member accounts using Amazon Organizations. For more information about multi-account environments, see [Managing multiple accounts in GuardDuty](https://docs.amazonaws.cn/guardduty/latest/ug/guardduty_accounts.html). ### Enabling automated agent configuration for delegated GuardDuty administrator account ------ #### [ Manage for all Amazon ECS clusters (account level) ] If you chose **Enable for all accounts** for Runtime Monitoring, then you have the following options: + Choose **Enable for all accounts** in the Automated agent configuration section. GuardDuty will deploy and manage the security agent for all the Amazon ECS tasks that get launched. + Choose **Configure accounts manually**. If you chose **Configure accounts manually** in the Runtime Monitoring section, then do the following: 1. Choose **Configure accounts manually** in the Automated agent configuration section. 1. Choose **Enable** in the **delegated GuardDuty administrator account (this account)** section. Choose **Save**. When you want GuardDuty to monitor tasks that are part of a service, it requires a new service deployment after you enable Runtime Monitoring. If the last deployment for a specific ECS service was started before you enabled Runtime Monitoring, you can either restart the service, or update the service by using `forceNewDeployment`. For steps to update the service, see the following resources: + [Updating an Amazon ECS service using the console](https://docs.amazonaws.cn/AmazonECS/latest/developerguide/update-service-console-v2.html) in the *Amazon Elastic Container Service Developer Guide*. + [UpdateService](https://docs.amazonaws.cn/AmazonECS/latest/APIReference/API_UpdateService.html) in the *Amazon Elastic Container Service API Reference*. + [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in the *Amazon CLI Command Reference*. ------ #### [ Manage for all Amazon ECS clusters but exclude some of the clusters (cluster level) ] 1. Add a tag to this Amazon ECS cluster with the key-value pair as `GuardDutyManaged`-`false`. 1. Prevent modification of tags, except by the trusted entities. The policy provided in [Prevent tags from being modified except by authorized principles](https://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin) in the *Amazon Organizations User Guide* has been modified to be applicable here. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch", "Effect": "Deny", "Action": [ "ecs:TagResource", "ecs:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}", "aws:PrincipalArn": "arn:aws-cn:iam::123456789012:role/org-admins/iam-admin" }, "Null": { "ecs:ResourceTag/GuardDutyManaged": false } } }, { "Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch", "Effect": "Deny", "Action": [ "ecs:TagResource", "ecs:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}", "aws:PrincipalArn": "arn:aws-cn:iam::123456789012:role/org-admins/iam-admin" }, "ForAnyValue:StringEquals": { "aws:TagKeys": [ "GuardDutyManaged" ] } } }, { "Sid": "DenyModifyTagsIfPrinTagNotExists", "Effect": "Deny", "Action": [ "ecs:TagResource", "ecs:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "aws:PrincipalArn": "arn:aws-cn:iam::123456789012:role/org-admins/iam-admin" }, "Null": { "aws:PrincipalTag/GuardDutyManaged": true } } } ] } ``` ------ 1. Open the GuardDuty console at [https://console.amazonaws.cn/guardduty/](https://console.amazonaws.cn/guardduty/). 1. In the navigation pane, choose **Runtime Monitoring**. 1. **Note** Always add the exclusion tag to your Amazon ECS clusters before enabling Automated agent configuration for your account; otherwise the GuardDuty sidecar container will be attached to all the containers in the Amazon ECS tasks that get launched. Under the **Configuration** tab, choose **Enable** in the **Automated agent configuration**. For the Amazon ECS clusters that have not been excluded, GuardDuty will manage the deployment of the security agent in the sidecar container. 1. Choose **Save**. 1. When you want GuardDuty to monitor tasks that are part of a service, it requires a new service deployment after you enable Runtime Monitoring. If the last deployment for a specific ECS service was started before you enabled Runtime Monitoring, you can either restart the service, or update the service by using `forceNewDeployment`. For steps to update the service, see the following resources: + [Updating an Amazon ECS service using the console](https://docs.amazonaws.cn/AmazonECS/latest/developerguide/update-service-console-v2.html) in the *Amazon Elastic Container Service Developer Guide*. + [UpdateService](https://docs.amazonaws.cn/AmazonECS/latest/APIReference/API_UpdateService.html) in the *Amazon Elastic Container Service API Reference*. + [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in the *Amazon CLI Command Reference*. ------ #### [ Manage for selective (inclusion only) Amazon ECS clusters (cluster level) ] 1. Add a tag to an Amazon ECS cluster for which you want to include all of the tasks. The key-value pair must be `GuardDutyManaged`-`true`. 1. Prevent modification of these tags, except by trusted entities. The policy provided in [Prevent tags from being modified except by authorized principles](https://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin) in the *Amazon Organizations User Guide* has been modified to be applicable here. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch", "Effect": "Deny", "Action": [ "ecs:TagResource", "ecs:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}", "aws:PrincipalArn": "arn:aws-cn:iam::123456789012:role/org-admins/iam-admin" }, "Null": { "ecs:ResourceTag/GuardDutyManaged": false } } }, { "Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch", "Effect": "Deny", "Action": [ "ecs:TagResource", "ecs:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}", "aws:PrincipalArn": "arn:aws-cn:iam::123456789012:role/org-admins/iam-admin" }, "ForAnyValue:StringEquals": { "aws:TagKeys": [ "GuardDutyManaged" ] } } }, { "Sid": "DenyModifyTagsIfPrinTagNotExists", "Effect": "Deny", "Action": [ "ecs:TagResource", "ecs:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "aws:PrincipalArn": "arn:aws-cn:iam::123456789012:role/org-admins/iam-admin" }, "Null": { "aws:PrincipalTag/GuardDutyManaged": true } } } ] } ``` ------ **Note** When using inclusion tags for your Amazon ECS clusters, you don't need to enable GuardDuty agent through automated agent congifuration explicitly. 1. When you want GuardDuty to monitor tasks that are part of a service, it requires a new service deployment after you enable Runtime Monitoring. If the last deployment for a specific ECS service was started before you enabled Runtime Monitoring, you can either restart the service, or update the service by using `forceNewDeployment`. For steps to update the service, see the following resources: + [Updating an Amazon ECS service using the console](https://docs.amazonaws.cn/AmazonECS/latest/developerguide/update-service-console-v2.html) in the *Amazon Elastic Container Service Developer Guide*. + [UpdateService](https://docs.amazonaws.cn/AmazonECS/latest/APIReference/API_UpdateService.html) in the *Amazon Elastic Container Service API Reference*. + [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in the *Amazon CLI Command Reference*. ------ ### Auto-enable for all member accounts ------ #### [ Manage for all Amazon ECS clusters (account level) ] The following steps assume that you chose **Enable for all accounts** in the Runtime Monitoring section. 1. Choose **Enable for all accounts** in the Automated agent configuration section. GuardDuty will deploy and manage the security agent for all the Amazon ECS tasks that get launched. 1. Choose **Save**. 1. When you want GuardDuty to monitor tasks that are part of a service, it requires a new service deployment after you enable Runtime Monitoring. If the last deployment for a specific ECS service was started before you enabled Runtime Monitoring, you can either restart the service, or update the service by using `forceNewDeployment`. For steps to update the service, see the following resources: + [Updating an Amazon ECS service using the console](https://docs.amazonaws.cn/AmazonECS/latest/developerguide/update-service-console-v2.html) in the *Amazon Elastic Container Service Developer Guide*. + [UpdateService](https://docs.amazonaws.cn/AmazonECS/latest/APIReference/API_UpdateService.html) in the *Amazon Elastic Container Service API Reference*. + [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in the *Amazon CLI Command Reference*. ------ #### [ Manage for all Amazon ECS clusters but exclude some of the clusters (cluster level) ] 1. Add a tag to this Amazon ECS cluster with the key-value pair as `GuardDutyManaged`-`false`. 1. Prevent modification of tags, except by the trusted entities. The policy provided in [Prevent tags from being modified except by authorized principles](https://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin) in the *Amazon Organizations User Guide* has been modified to be applicable here. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch", "Effect": "Deny", "Action": [ "ecs:TagResource", "ecs:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}", "aws:PrincipalArn": "arn:aws-cn:iam::123456789012:role/org-admins/iam-admin" }, "Null": { "ecs:ResourceTag/GuardDutyManaged": false } } }, { "Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch", "Effect": "Deny", "Action": [ "ecs:TagResource", "ecs:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}", "aws:PrincipalArn": "arn:aws-cn:iam::123456789012:role/org-admins/iam-admin" }, "ForAnyValue:StringEquals": { "aws:TagKeys": [ "GuardDutyManaged" ] } } }, { "Sid": "DenyModifyTagsIfPrinTagNotExists", "Effect": "Deny", "Action": [ "ecs:TagResource", "ecs:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "aws:PrincipalArn": "arn:aws-cn:iam::123456789012:role/org-admins/iam-admin" }, "Null": { "aws:PrincipalTag/GuardDutyManaged": true } } } ] } ``` ------ 1. Open the GuardDuty console at [https://console.amazonaws.cn/guardduty/](https://console.amazonaws.cn/guardduty/). 1. In the navigation pane, choose **Runtime Monitoring**. 1. **Note** Always add the exclusion tag to your Amazon ECS clusters before enabling Automated agent configuration for your account; otherwise the GuardDuty sidecar container will be attached to all the containers in the Amazon ECS tasks that get launched. Under the **Configuration** tab, choose **Edit**. 1. Choose **Enable for all accounts** in the **Automated agent configuration** section For the Amazon ECS clusters that have not been excluded, GuardDuty will manage the deployment of the security agent in the sidecar container. 1. Choose **Save**. 1. When you want GuardDuty to monitor tasks that are part of a service, it requires a new service deployment after you enable Runtime Monitoring. If the last deployment for a specific ECS service was started before you enabled Runtime Monitoring, you can either restart the service, or update the service by using `forceNewDeployment`. For steps to update the service, see the following resources: + [Updating an Amazon ECS service using the console](https://docs.amazonaws.cn/AmazonECS/latest/developerguide/update-service-console-v2.html) in the *Amazon Elastic Container Service Developer Guide*. + [UpdateService](https://docs.amazonaws.cn/AmazonECS/latest/APIReference/API_UpdateService.html) in the *Amazon Elastic Container Service API Reference*. + [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in the *Amazon CLI Command Reference*. ------ #### [ Manage for selective (inclusion-only) Amazon ECS clusters (cluster level) ] Regardless of how you choose to enable Runtime Monitoring, the following steps will help you monitor selective Amazon ECS Fargate tasks for all of the member accounts in your organization. 1. Do not enable any configuration in the Automated agent configuration section. Keep the Runtime Monitoring configuration the same as you selected in the previous step. 1. Choose **Save**. 1. Prevent modification of these tags, except by trusted entities. The policy provided in [Prevent tags from being modified except by authorized principles](https://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin) in the *Amazon Organizations User Guide* has been modified to be applicable here. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch", "Effect": "Deny", "Action": [ "ecs:TagResource", "ecs:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}", "aws:PrincipalArn": "arn:aws-cn:iam::123456789012:role/org-admins/iam-admin" }, "Null": { "ecs:ResourceTag/GuardDutyManaged": false } } }, { "Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch", "Effect": "Deny", "Action": [ "ecs:TagResource", "ecs:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}", "aws:PrincipalArn": "arn:aws-cn:iam::123456789012:role/org-admins/iam-admin" }, "ForAnyValue:StringEquals": { "aws:TagKeys": [ "GuardDutyManaged" ] } } }, { "Sid": "DenyModifyTagsIfPrinTagNotExists", "Effect": "Deny", "Action": [ "ecs:TagResource", "ecs:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "aws:PrincipalArn": "arn:aws-cn:iam::123456789012:role/org-admins/iam-admin" }, "Null": { "aws:PrincipalTag/GuardDutyManaged": true } } } ] } ``` ------ **Note** When using inclusion tags for your Amazon ECS clusters, you don't need to enable **GuardDuty agent auto-management** explicitly. 1. When you want GuardDuty to monitor tasks that are part of a service, it requires a new service deployment after you enable Runtime Monitoring. If the last deployment for a specific ECS service was started before you enabled Runtime Monitoring, you can either restart the service, or update the service by using `forceNewDeployment`. For steps to update the service, see the following resources: + [Updating an Amazon ECS service using the console](https://docs.amazonaws.cn/AmazonECS/latest/developerguide/update-service-console-v2.html) in the *Amazon Elastic Container Service Developer Guide*. + [UpdateService](https://docs.amazonaws.cn/AmazonECS/latest/APIReference/API_UpdateService.html) in the *Amazon Elastic Container Service API Reference*. + [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in the *Amazon CLI Command Reference*. ------ ### Enabling automated agent configuration for existing active member accounts ------ #### [ Manage for all Amazon ECS clusters (account level) ] 1. On the Runtime Monitoring page, under the **Configuration** tab, you can view the current status of Automated agent configuration. 1. Within the Automated agent configuration pane, under the **Active member accounts** section, choose **Actions**. 1. From **Actions**, choose **Enable for all existing active member accounts**. 1. Choose **Confirm**. 1. When you want GuardDuty to monitor tasks that are part of a service, it requires a new service deployment after you enable Runtime Monitoring. If the last deployment for a specific ECS service was started before you enabled Runtime Monitoring, you can either restart the service, or update the service by using `forceNewDeployment`. For steps to update the service, see the following resources: + [Updating an Amazon ECS service using the console](https://docs.amazonaws.cn/AmazonECS/latest/developerguide/update-service-console-v2.html) in the *Amazon Elastic Container Service Developer Guide*. + [UpdateService](https://docs.amazonaws.cn/AmazonECS/latest/APIReference/API_UpdateService.html) in the *Amazon Elastic Container Service API Reference*. + [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in the *Amazon CLI Command Reference*. ------ #### [ Manage for all Amazon ECS clusters but exclude some of the clusters (cluster level) ] 1. Add a tag to this Amazon ECS cluster with the key-value pair as `GuardDutyManaged`-`false`. 1. Prevent modification of tags, except by the trusted entities. The policy provided in [Prevent tags from being modified except by authorized principles](https://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin) in the *Amazon Organizations User Guide* has been modified to be applicable here. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch", "Effect": "Deny", "Action": [ "ecs:TagResource", "ecs:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}", "aws:PrincipalArn": "arn:aws-cn:iam::123456789012:role/org-admins/iam-admin" }, "Null": { "ecs:ResourceTag/GuardDutyManaged": false } } }, { "Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch", "Effect": "Deny", "Action": [ "ecs:TagResource", "ecs:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}", "aws:PrincipalArn": "arn:aws-cn:iam::123456789012:role/org-admins/iam-admin" }, "ForAnyValue:StringEquals": { "aws:TagKeys": [ "GuardDutyManaged" ] } } }, { "Sid": "DenyModifyTagsIfPrinTagNotExists", "Effect": "Deny", "Action": [ "ecs:TagResource", "ecs:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "aws:PrincipalArn": "arn:aws-cn:iam::123456789012:role/org-admins/iam-admin" }, "Null": { "aws:PrincipalTag/GuardDutyManaged": true } } } ] } ``` ------ 1. Open the GuardDuty console at [https://console.amazonaws.cn/guardduty/](https://console.amazonaws.cn/guardduty/). 1. In the navigation pane, choose **Runtime Monitoring**. 1. **Note** Always add the exclusion tag to your Amazon ECS clusters before enabling Automated agent configuration for your account; otherwise the GuardDuty sidecar container will be attached to all the containers in the Amazon ECS tasks that get launched. Under the **Configuration** tab, in the Automated agent configuration section, under **Active member accounts**, choose **Actions**. 1. From **Actions**, choose **Enable for all active member accounts**. For the Amazon ECS clusters that have not been excluded, GuardDuty will manage the deployment of the security agent in the sidecar container. 1. Choose **Confirm**. 1. When you want GuardDuty to monitor tasks that are part of a service, it requires a new service deployment after you enable Runtime Monitoring. If the last deployment for a specific ECS service was started before you enabled Runtime Monitoring, you can either restart the service, or update the service by using `forceNewDeployment`. For steps to update the service, see the following resources: + [Updating an Amazon ECS service using the console](https://docs.amazonaws.cn/AmazonECS/latest/developerguide/update-service-console-v2.html) in the *Amazon Elastic Container Service Developer Guide*. + [UpdateService](https://docs.amazonaws.cn/AmazonECS/latest/APIReference/API_UpdateService.html) in the *Amazon Elastic Container Service API Reference*. + [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in the *Amazon CLI Command Reference*. ------ #### [ Manage for selective (inclusion only) Amazon ECS clusters (cluster level) ] 1. Add a tag to an Amazon ECS cluster for which you want to include all of the tasks. The key-value pair must be `GuardDutyManaged`-`true`. 1. Prevent modification of these tags, except by trusted entities. The policy provided in [Prevent tags from being modified except by authorized principles](https://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin) in the *Amazon Organizations User Guide* has been modified to be applicable here. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch", "Effect": "Deny", "Action": [ "ecs:TagResource", "ecs:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}", "aws:PrincipalArn": "arn:aws-cn:iam::123456789012:role/org-admins/iam-admin" }, "Null": { "ecs:ResourceTag/GuardDutyManaged": false } } }, { "Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch", "Effect": "Deny", "Action": [ "ecs:TagResource", "ecs:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}", "aws:PrincipalArn": "arn:aws-cn:iam::123456789012:role/org-admins/iam-admin" }, "ForAnyValue:StringEquals": { "aws:TagKeys": [ "GuardDutyManaged" ] } } }, { "Sid": "DenyModifyTagsIfPrinTagNotExists", "Effect": "Deny", "Action": [ "ecs:TagResource", "ecs:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "aws:PrincipalArn": "arn:aws-cn:iam::123456789012:role/org-admins/iam-admin" }, "Null": { "aws:PrincipalTag/GuardDutyManaged": true } } } ] } ``` ------ **Note** When using inclusion tags for your Amazon ECS clusters, you don't need to enable **Automated agent configuration** explicitly. 1. When you want GuardDuty to monitor tasks that are part of a service, it requires a new service deployment after you enable Runtime Monitoring. If the last deployment for a specific ECS service was started before you enabled Runtime Monitoring, you can either restart the service, or update the service by using `forceNewDeployment`. For steps to update the service, see the following resources: + [Updating an Amazon ECS service using the console](https://docs.amazonaws.cn/AmazonECS/latest/developerguide/update-service-console-v2.html) in the *Amazon Elastic Container Service Developer Guide*. + [UpdateService](https://docs.amazonaws.cn/AmazonECS/latest/APIReference/API_UpdateService.html) in the *Amazon Elastic Container Service API Reference*. + [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in the *Amazon CLI Command Reference*. ------ ### Auto-enable Automated agent configuration for new members ------ #### [ Manage for all Amazon ECS clusters (account level) ] 1. On the Runtime Monitoring page, choose **Edit** to update the existing configuration. 1. In the Automated agent configuration section, select **Automatically enable for new member accounts**. 1. Choose **Save**. 1. When you want GuardDuty to monitor tasks that are part of a service, it requires a new service deployment after you enable Runtime Monitoring. If the last deployment for a specific ECS service was started before you enabled Runtime Monitoring, you can either restart the service, or update the service by using `forceNewDeployment`. For steps to update the service, see the following resources: + [Updating an Amazon ECS service using the console](https://docs.amazonaws.cn/AmazonECS/latest/developerguide/update-service-console-v2.html) in the *Amazon Elastic Container Service Developer Guide*. + [UpdateService](https://docs.amazonaws.cn/AmazonECS/latest/APIReference/API_UpdateService.html) in the *Amazon Elastic Container Service API Reference*. + [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in the *Amazon CLI Command Reference*. ------ #### [ Manage for all Amazon ECS clusters but exclude some of the clusters (cluster level) ] 1. Add a tag to this Amazon ECS cluster with the key-value pair as `GuardDutyManaged`-`false`. 1. Prevent modification of tags, except by the trusted entities. The policy provided in [Prevent tags from being modified except by authorized principles](https://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin) in the *Amazon Organizations User Guide* has been modified to be applicable here. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch", "Effect": "Deny", "Action": [ "ecs:TagResource", "ecs:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}", "aws:PrincipalArn": "arn:aws-cn:iam::123456789012:role/org-admins/iam-admin" }, "Null": { "ecs:ResourceTag/GuardDutyManaged": false } } }, { "Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch", "Effect": "Deny", "Action": [ "ecs:TagResource", "ecs:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}", "aws:PrincipalArn": "arn:aws-cn:iam::123456789012:role/org-admins/iam-admin" }, "ForAnyValue:StringEquals": { "aws:TagKeys": [ "GuardDutyManaged" ] } } }, { "Sid": "DenyModifyTagsIfPrinTagNotExists", "Effect": "Deny", "Action": [ "ecs:TagResource", "ecs:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "aws:PrincipalArn": "arn:aws-cn:iam::123456789012:role/org-admins/iam-admin" }, "Null": { "aws:PrincipalTag/GuardDutyManaged": true } } } ] } ``` ------ 1. Open the GuardDuty console at [https://console.amazonaws.cn/guardduty/](https://console.amazonaws.cn/guardduty/). 1. In the navigation pane, choose **Runtime Monitoring**. 1. **Note** Always add the exclusion tag to your Amazon ECS clusters before enabling Automated agent configuration for your account; otherwise the GuardDuty sidecar container will be attached to all the containers in the Amazon ECS tasks that get launched. Under the **Configuration** tab, select **Automatically enable for new member accounts** in the **Automated agent configuration** section. For the Amazon ECS clusters that have not been excluded, GuardDuty will manage the deployment of the security agent in the sidecar container. 1. Choose **Save**. 1. When you want GuardDuty to monitor tasks that are part of a service, it requires a new service deployment after you enable Runtime Monitoring. If the last deployment for a specific ECS service was started before you enabled Runtime Monitoring, you can either restart the service, or update the service by using `forceNewDeployment`. For steps to update the service, see the following resources: + [Updating an Amazon ECS service using the console](https://docs.amazonaws.cn/AmazonECS/latest/developerguide/update-service-console-v2.html) in the *Amazon Elastic Container Service Developer Guide*. + [UpdateService](https://docs.amazonaws.cn/AmazonECS/latest/APIReference/API_UpdateService.html) in the *Amazon Elastic Container Service API Reference*. + [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in the *Amazon CLI Command Reference*. ------ #### [ Manage for selective (inclusion only) Amazon ECS clusters (cluster level) ] 1. Add a tag to an Amazon ECS cluster for which you want to include all of the tasks. The key-value pair must be `GuardDutyManaged`-`true`. 1. Prevent modification of these tags, except by trusted entities. The policy provided in [Prevent tags from being modified except by authorized principles](https://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin) in the *Amazon Organizations User Guide* has been modified to be applicable here. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch", "Effect": "Deny", "Action": [ "ecs:TagResource", "ecs:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}", "aws:PrincipalArn": "arn:aws-cn:iam::123456789012:role/org-admins/iam-admin" }, "Null": { "ecs:ResourceTag/GuardDutyManaged": false } } }, { "Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch", "Effect": "Deny", "Action": [ "ecs:TagResource", "ecs:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}", "aws:PrincipalArn": "arn:aws-cn:iam::123456789012:role/org-admins/iam-admin" }, "ForAnyValue:StringEquals": { "aws:TagKeys": [ "GuardDutyManaged" ] } } }, { "Sid": "DenyModifyTagsIfPrinTagNotExists", "Effect": "Deny", "Action": [ "ecs:TagResource", "ecs:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "aws:PrincipalArn": "arn:aws-cn:iam::123456789012:role/org-admins/iam-admin" }, "Null": { "aws:PrincipalTag/GuardDutyManaged": true } } } ] } ``` ------ **Note** When using inclusion tags for your Amazon ECS clusters, you don't need to enable **Automated agent configuration** explicitly. 1. When you want GuardDuty to monitor tasks that are part of a service, it requires a new service deployment after you enable Runtime Monitoring. If the last deployment for a specific ECS service was started before you enabled Runtime Monitoring, you can either restart the service, or update the service by using `forceNewDeployment`. For steps to update the service, see the following resources: + [Updating an Amazon ECS service using the console](https://docs.amazonaws.cn/AmazonECS/latest/developerguide/update-service-console-v2.html) in the *Amazon Elastic Container Service Developer Guide*. + [UpdateService](https://docs.amazonaws.cn/AmazonECS/latest/APIReference/API_UpdateService.html) in the *Amazon Elastic Container Service API Reference*. + [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in the *Amazon CLI Command Reference*. ------ ### Enabling Automated agent configuration for active member accounts selectively ------ #### [ Manage for all Amazon ECS (account level) ] 1. On the Accounts page, select the accounts for which you want to enable Runtime Monitoring-Automated agent configuration (ECS-Fargate). You can select multiple accounts. Make sure that the accounts that you select in this step are already enabled with Runtime Monitoring. 1. From **Edit protection plans**, choose the appropriate option to enable **Runtime Monitoring-Automated agent configuration (ECS-Fargate)**. 1. Choose **Confirm**. 1. When you want GuardDuty to monitor tasks that are part of a service, it requires a new service deployment after you enable Runtime Monitoring. If the last deployment for a specific ECS service was started before you enabled Runtime Monitoring, you can either restart the service, or update the service by using `forceNewDeployment`. For steps to update the service, see the following resources: + [Updating an Amazon ECS service using the console](https://docs.amazonaws.cn/AmazonECS/latest/developerguide/update-service-console-v2.html) in the *Amazon Elastic Container Service Developer Guide*. + [UpdateService](https://docs.amazonaws.cn/AmazonECS/latest/APIReference/API_UpdateService.html) in the *Amazon Elastic Container Service API Reference*. + [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in the *Amazon CLI Command Reference*. ------ #### [ Manage for all Amazon ECS clusters but exclude some of the clusters (cluster level) ] 1. Add a tag to this Amazon ECS cluster with the key-value pair as `GuardDutyManaged`-`false`. 1. Prevent modification of tags, except by the trusted entities. The policy provided in [Prevent tags from being modified except by authorized principles](https://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin) in the *Amazon Organizations User Guide* has been modified to be applicable here. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch", "Effect": "Deny", "Action": [ "ecs:TagResource", "ecs:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}", "aws:PrincipalArn": "arn:aws-cn:iam::123456789012:role/org-admins/iam-admin" }, "Null": { "ecs:ResourceTag/GuardDutyManaged": false } } }, { "Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch", "Effect": "Deny", "Action": [ "ecs:TagResource", "ecs:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}", "aws:PrincipalArn": "arn:aws-cn:iam::123456789012:role/org-admins/iam-admin" }, "ForAnyValue:StringEquals": { "aws:TagKeys": [ "GuardDutyManaged" ] } } }, { "Sid": "DenyModifyTagsIfPrinTagNotExists", "Effect": "Deny", "Action": [ "ecs:TagResource", "ecs:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "aws:PrincipalArn": "arn:aws-cn:iam::123456789012:role/org-admins/iam-admin" }, "Null": { "aws:PrincipalTag/GuardDutyManaged": true } } } ] } ``` ------ 1. Open the GuardDuty console at [https://console.amazonaws.cn/guardduty/](https://console.amazonaws.cn/guardduty/). 1. In the navigation pane, choose **Runtime Monitoring**. 1. **Note** Always add the exclusion tag to your Amazon ECS clusters before enabling GuardDuty agent auto-management for your account; otherwise the GuardDuty sidecar container will be attached to all the containers in the Amazon ECS tasks that get launched. On the Accounts page, select the accounts for which you want to enable Runtime Monitoring-Automated agent configuration (ECS-Fargate). You can select multiple accounts. Make sure that the accounts that you select in this step are already enabled with Runtime Monitoring. For the Amazon ECS clusters that have not been excluded, GuardDuty will manage the deployment of the security agent in the sidecar container. 1. From **Edit protection plans**, choose the appropriate option to enable **Runtime Monitoring-Automated agent configuration (ECS-Fargate)**. 1. Choose **Save**. 1. When you want GuardDuty to monitor tasks that are part of a service, it requires a new service deployment after you enable Runtime Monitoring. If the last deployment for a specific ECS service was started before you enabled Runtime Monitoring, you can either restart the service, or update the service by using `forceNewDeployment`. For steps to update the service, see the following resources: + [Updating an Amazon ECS service using the console](https://docs.amazonaws.cn/AmazonECS/latest/developerguide/update-service-console-v2.html) in the *Amazon Elastic Container Service Developer Guide*. + [UpdateService](https://docs.amazonaws.cn/AmazonECS/latest/APIReference/API_UpdateService.html) in the *Amazon Elastic Container Service API Reference*. + [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in the *Amazon CLI Command Reference*. ------ #### [ Manage for selective (inclusion only) Amazon ECS clusters (cluster level) ] 1. Make sure you don't enable **Automated agent configuration** (or **Runtime Monitoring-Automated agent configuration (ECS-Fargate)**) for the selected accounts that have the Amazon ECS clusters that you want to monitor. 1. Add a tag to an Amazon ECS cluster for which you want to include all of the tasks. The key-value pair must be `GuardDutyManaged`-`true`. 1. Prevent modification of these tags, except by trusted entities. The policy provided in [Prevent tags from being modified except by authorized principles](https://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin) in the *Amazon Organizations User Guide* has been modified to be applicable here. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch", "Effect": "Deny", "Action": [ "ecs:TagResource", "ecs:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}", "aws:PrincipalArn": "arn:aws-cn:iam::123456789012:role/org-admins/iam-admin" }, "Null": { "ecs:ResourceTag/GuardDutyManaged": false } } }, { "Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch", "Effect": "Deny", "Action": [ "ecs:TagResource", "ecs:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}", "aws:PrincipalArn": "arn:aws-cn:iam::123456789012:role/org-admins/iam-admin" }, "ForAnyValue:StringEquals": { "aws:TagKeys": [ "GuardDutyManaged" ] } } }, { "Sid": "DenyModifyTagsIfPrinTagNotExists", "Effect": "Deny", "Action": [ "ecs:TagResource", "ecs:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "aws:PrincipalArn": "arn:aws-cn:iam::123456789012:role/org-admins/iam-admin" }, "Null": { "aws:PrincipalTag/GuardDutyManaged": true } } } ] } ``` ------ **Note** When using inclusion tags for your Amazon ECS clusters, you don't need to enable **Automated agent configuration** explicitly. 1. When you want GuardDuty to monitor tasks that are part of a service, it requires a new service deployment after you enable Runtime Monitoring. If the last deployment for a specific ECS service was started before you enabled Runtime Monitoring, you can either restart the service, or update the service by using `forceNewDeployment`. For steps to update the service, see the following resources: + [Updating an Amazon ECS service using the console](https://docs.amazonaws.cn/AmazonECS/latest/developerguide/update-service-console-v2.html) in the *Amazon Elastic Container Service Developer Guide*. + [UpdateService](https://docs.amazonaws.cn/AmazonECS/latest/APIReference/API_UpdateService.html) in the *Amazon Elastic Container Service API Reference*. + [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in the *Amazon CLI Command Reference*. ------ ## Configuring GuardDuty agent for a standalone account 1. Sign in to the Amazon Web Services Management Console and open the GuardDuty console at [https://console.amazonaws.cn/guardduty/](https://console.amazonaws.cn/guardduty/). 1. In the navigation pane, choose **Runtime Monitoring**. 1. Under the **Configuration** tab: 1. **To manage Automated agent configuration for all Amazon ECS clusters (account level)** Choose **Enable** in the **Automated agent configuration** section for **Amazon Fargate (ECS only)**. When a new Fargate Amazon ECS task launches, GuardDuty will manage the deployment of the security agent. 1. Choose **Save**. 1. **To manage Automated agent configuration by excluding some of the Amazon ECS clusters (cluster level)** 1. Add a tag to the Amazon ECS cluster for which you want to exclude all of the tasks. The key-value pair must be `GuardDutyManaged`-`false`. 1. Prevent modification of these tags, except by trusted entities. The policy provided in [Prevent tags from being modified except by authorized principles](https://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin) in the *Amazon Organizations User Guide* has been modified to be applicable here. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch", "Effect": "Deny", "Action": [ "ecs:TagResource", "ecs:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}", "aws:PrincipalArn": "arn:aws-cn:iam::123456789012:role/org-admins/iam-admin" }, "Null": { "ecs:ResourceTag/GuardDutyManaged": false } } }, { "Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch", "Effect": "Deny", "Action": [ "ecs:TagResource", "ecs:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}", "aws:PrincipalArn": "arn:aws-cn:iam::123456789012:role/org-admins/iam-admin" }, "ForAnyValue:StringEquals": { "aws:TagKeys": [ "GuardDutyManaged" ] } } }, { "Sid": "DenyModifyTagsIfPrinTagNotExists", "Effect": "Deny", "Action": [ "ecs:TagResource", "ecs:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "aws:PrincipalArn": "arn:aws-cn:iam::123456789012:role/org-admins/iam-admin" }, "Null": { "aws:PrincipalTag/GuardDutyManaged": true } } } ] } ``` ------ 1. Under the **Configuration** tab, choose **Enable** in the **Automated agent configuration** section. **Note** Always add the exclusion tag to your Amazon ECS cluster before enabling GuardDuty agent auto-management for your account; otherwise, the security agent will be deployed in all the tasks that are launched within the corresponding Amazon ECS cluster. For the Amazon ECS clusters that have not been excluded, GuardDuty will manage the deployment of the security agent in the sidecar container. 1. Choose **Save**. 1. **To manage Automated agent configuration by including some of the Amazon ECS clusters (cluster level)** 1. Add a tag to an Amazon ECS cluster for which you want to include all of the tasks. The key-value pair must be `GuardDutyManaged`-`true`. 1. Prevent modification of these tags, except by trusted entities. The policy provided in [Prevent tags from being modified except by authorized principles](https://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin) in the *Amazon Organizations User Guide* has been modified to be applicable here. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch", "Effect": "Deny", "Action": [ "ecs:TagResource", "ecs:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}", "aws:PrincipalArn": "arn:aws-cn:iam::123456789012:role/org-admins/iam-admin" }, "Null": { "ecs:ResourceTag/GuardDutyManaged": false } } }, { "Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch", "Effect": "Deny", "Action": [ "ecs:TagResource", "ecs:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}", "aws:PrincipalArn": "arn:aws-cn:iam::123456789012:role/org-admins/iam-admin" }, "ForAnyValue:StringEquals": { "aws:TagKeys": [ "GuardDutyManaged" ] } } }, { "Sid": "DenyModifyTagsIfPrinTagNotExists", "Effect": "Deny", "Action": [ "ecs:TagResource", "ecs:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "aws:PrincipalArn": "arn:aws-cn:iam::123456789012:role/org-admins/iam-admin" }, "Null": { "aws:PrincipalTag/GuardDutyManaged": true } } } ] } ``` ------ 1. When you want GuardDuty to monitor tasks that are part of a service, it requires a new service deployment after you enable Runtime Monitoring. If the last deployment for a specific ECS service was started before you enabled Runtime Monitoring, you can either restart the service, or update the service by using `forceNewDeployment`. For steps to update the service, see the following resources: + [Updating an Amazon ECS service using the console](https://docs.amazonaws.cn/AmazonECS/latest/developerguide/update-service-console-v2.html) in the *Amazon Elastic Container Service Developer Guide*. + [UpdateService](https://docs.amazonaws.cn/AmazonECS/latest/APIReference/API_UpdateService.html) in the *Amazon Elastic Container Service API Reference*. + [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in the *Amazon CLI Command Reference*. # Managing security agent automatically for Amazon EKS resources Automated agent on Amazon EKS resource Runtime Monitoring supports enabling the security agent through GuardDuty automated configuration and manually. This section provides the steps to enable automated agent configuration for Amazon EKS clusters. Before proceeding, make sure that you have followed the [Prerequisites for Amazon EKS cluster support](prereq-runtime-monitoring-eks-support.md). Based on your preferred approach on how to [Manage security agent through GuardDuty](how-runtime-monitoring-works-eks.md#eks-runtime-using-gdu-agent-management-auto), choose the steps in the following sections accordingly. ## Configuring Automated agent for multi-account environments In a multiple-account environments, only the delegated GuardDuty administrator account can enable or disable Automated agent configuration for the member accounts, and manage Automated agent for the EKS clusters belonging to the member accounts in their organization. The GuardDuty member accounts can't modify this configuration from their accounts. The delegated GuardDuty administrator account account manages their member accounts using Amazon Organizations. For more information about multi-account environments, see [Managing multiple accounts](https://docs.amazonaws.cn/guardduty/latest/ug/guardduty_accounts.html). ### Configuring Automated agent configuration for delegated GuardDuty administrator account | **Preferred approach to manage GuardDuty security agent** | **Steps** | | --- | --- | | Manage security agent through GuardDuty (Monitor all EKS clusters) | If you chose **Enable for all accounts** in the Runtime Monitoring section, then you have the following options: [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) If you chose **Configure accounts manually** in the Runtime Monitoring section, then do the following: [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) Choose **Save**. | | Monitor all EKS clusters but exclude some of them (using exclusion tags) | From the following procedures, choose one of the scenarios that apply to you. [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) | | Monitor selective EKS clusters using inclusion tags | Regardless of how you chose to enable Runtime Monitoring, the following steps will help you monitor selective EKS clusters in your account: [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) | | Manage the GuardDuty security agent manually | Regardless of how you chose to enable Runtime Monitoring, you can manage the security agent manually for your EKS clusters. [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) | ### Auto-enable Automated agent for all member accounts **Note** It may take up to 24 hours to update the configuration for the member accounts. | **Preferred approach to manage GuardDuty security agent** | **Steps** | | --- | --- | | Manage security agent through GuardDuty (Monitor all EKS clusters) | This topic is to enable Runtime Monitoring for all member accounts and therefore, the following steps assume that you must have chosen **Enable for all accounts** in the Runtime Monitoring section. [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) | | Monitor all EKS clusters but exclude some of them (using exclusion tags) | From the following procedures, choose one of the scenarios that apply to you. [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) | | Monitor selective EKS clusters using inclusion tags | Regardless of how you chose to enable Runtime Monitoring, the following steps will help you monitor selective EKS clusters for all member accounts in your organization: [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) | | Manage the GuardDuty security agent manually | Regardless of how you chose to enable Runtime Monitoring, you can manage the security agent manually for your EKS clusters. [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) | ### Enabling automated agent for all existing active member accounts **Note** It may take up to 24 hours to update the configuration for the member accounts. **To manage GuardDuty security agent for existing active member accounts in your organization** + For GuardDuty to receive the runtime events from the EKS clusters that belong to the existing active member accounts in the organization, you must choose a preferred approach to manage the GuardDuty security agent for these EKS clusters. For more information about each of these approaches, see [Approaches to manage GuardDuty security agent in Amazon EKS clusters](how-runtime-monitoring-works-eks.md#eksrunmon-approach-to-monitor-eks-clusters). [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) ### Auto-enable automated agent configuration for new members | **Preferred approach to manage GuardDuty security agent** | **Steps** | | --- | --- | | Manage security agent through GuardDuty (Monitor all EKS clusters) | [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) | | Monitor all EKS clusters but exclude some of them (using exclusion tags) | From the following procedures, choose one of the scenarios that apply to you. [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) | | Monitor selective EKS clusters using inclusion tags | Regardless of how you chose to enable Runtime Monitoring, the following steps will help you monitor selective EKS clusters for the new member accounts in your organization. [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) | | Manage the GuardDuty security agent manually | Regardless of how you chose to enable Runtime Monitoring, you can manage the security agent manually for your EKS clusters. [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) | ### Configuring Automated agent for active member accounts selectively | **Preferred approach to manage GuardDuty security agent** | **Steps** | | --- | --- | | Manage security agent through GuardDuty (Monitor all EKS clusters) | [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) | | Monitor all EKS clusters but exclude some of them (using exclusion tags) | From the following procedures, choose one of the scenarios that apply to you. [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) | | Monitor selective EKS clusters using inclusion tags | Regardless of how you chose to enable Runtime Monitoring, the following steps will help you monitor selective EKS clusters that belong to the selected accounts: [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) | | Manage the GuardDuty security agent manually | [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) | ## Configuring Automated agent for standalone account A standalone account owns the decision to enable or disable a protection plan in their Amazon Web Services account in a specific Amazon Web Services Region. If your account is associated with a GuardDuty administrator account through Amazon Organizations, or by the method of invitation, this section doesn't apply to your account. For more information, see [Enabling Runtime Monitoring for multiple-account environments](enable-runtime-monitoring-multiple-acc-env.md). After you enable Runtime Monitoring, ensure to install GuardDuty security agent through automated configuration or manual deployment. As a part of completing all the steps listed in the following procedure, make sure to install the security agent. Based on your preference to monitor all or selective Amazon EKS resources, choose a preferred method and follow the steps in the following table. 1. Sign in to the Amazon Web Services Management Console and open the GuardDuty console at [https://console.amazonaws.cn/guardduty/](https://console.amazonaws.cn/guardduty/). 1. In the navigation pane, choose **Runtime Monitoring**. 1. Under the **Configuration** tab, choose **Enable** to enable automated agent configuration for your account. [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) # Managing security agent manually for Amazon EKS cluster Manual agent management for Amazon EKS cluster This section describes how you can manage your Amazon EKS add-on agent (GuardDuty agent) after you enable Runtime Monitoring (or EKS Runtime Monitoring). To use Runtime Monitoring, you must enable Runtime Monitoring and configure the Amazon EKS add-on, `aws-guardduty-agent`. You require to perform both the steps for GuardDuty to detect potential threats and generate [GuardDuty Runtime Monitoring finding types](findings-runtime-monitoring.md). For managing the agent manually, you need to create a VPC endpoint as a prerequisite. This helps GuardDuty receive the runtime events. After this, you can install the security agent so that GuardDuty will start receiving the runtime events from the Amazon EKS resources. When GuardDuty releases a new agent version for this resource, you can update the agent version in your account. **Topics** + [ # Prerequisite – Creating an Amazon VPC endpoint ](eksrunmon-prereq-deploy-security-agent.md) + [ # Installing GuardDuty security agent manually on Amazon EKS resources ](eksrunmon-deploy-security-agent.md) + [ # Updating security agent manually for Amazon EKS resources ](eksrunmon-update-security-agent.md) # Prerequisite – Creating an Amazon VPC endpoint Before you can install the GuardDuty security agent, you must create an Amazon Virtual Private Cloud (Amazon VPC) endpoint. This will help GuardDuty receive the runtime events of your Amazon EKS resources. **Note** There is no additional cost for the usage of the VPC endpoint. Choose a preferred access method to create an Amazon VPC endpoint. ------ #### [ Console ] **To create a VPC endpoint** 1. Open the Amazon VPC console at [https://console.amazonaws.cn/vpc/](https://console.amazonaws.cn/vpc/). 1. In the navigation pane, under **Virtual private cloud**, choose **Endpoints**. 1. Choose **Create Endpoint**. 1. On the **Create endpoint** page, for **Service category**, choose **Other endpoint services**. 1. For **Service name**, enter **com.amazonaws.*us-east-1*.guardduty-data**. Make sure to replace *us-east-1* with the correct Region. This must be the same Region as the EKS cluster that belongs to your Amazon Web Services account ID. 1. Choose **Verify service**. 1. After the service name is successfully verified, choose the **VPC** where your cluster resides. Add the following policy to restrict VPC endpoint usage to specified account only. With the organization `Condition` provided below this policy, you can update the following policy to restrict access to your endpoint. To provide VPC endpoint support to specific account IDs in your organization, see [Organization condition to restrict access to your endpoint](#gdu-shared-vpc-endpoint-org). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": "*", "Resource": "*", "Effect": "Allow", "Principal": "*" }, { "Condition": { "StringNotEquals": { "aws:PrincipalAccount": "111122223333" } }, "Action": "*", "Resource": "*", "Effect": "Deny", "Principal": "*" } ] } ``` ------ The `aws:PrincipalAccount` account ID must match the account containing the VPC and VPC endpoint. The following list shows how to share the VPC endpoint with other Amazon Web Services account IDs: **Organization condition to restrict access to your endpoint** + To specify multiple accounts to access the VPC endpoint, replace `"aws:PrincipalAccount": "111122223333"` with the following: ``` "aws:PrincipalAccount": [ "666666666666", "555555555555" ] ``` + To allow all the members from an organization to access the VPC endpoint, replace `"aws:PrincipalAccount": "111122223333"` with the following: ``` "aws:PrincipalOrgID": "o-abcdef0123" ``` + To restrict accessing a resource to an organization ID, add your `ResourceOrgID` to the policy. For more information, see [ResourceOrgID](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceorgid). ``` "aws:ResourceOrgID": "o-abcdef0123" ``` 1. Under **Additional settings**, choose **Enable DNS name**. 1. Under **Subnets**, choose the subnets in which your cluster resides. 1. Under **Security groups**, choose a security group that has the in-bound port 443 enabled from your VPC (or your EKS cluster). If you don't already have a security group that has an in-bound port 443 enabled, [Create a security group](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/working-with-security-groups.html#creating-security-group). If there is an issue while restricting the in-bound permissions to your VPC (or instance), you can the in-bound 443 port from any IP address `(0.0.0.0/0)`. However, GuardDuty recommends using IP addresses that matches the CIDR block for your VPC. For more information, see [VPC CIDR blocks](https://docs.amazonaws.cn//vpc/latest/userguide/vpc-cidr-blocks.html) in the *Amazon VPC User Guide*. ------ #### [ API/CLI ] **To create a VPC endpoint** + Invoke [CreateVpcEndpoint](https://docs.amazonaws.cn/AWSEC2/latest/APIReference/API_CreateVpcEndpoint.html). + Use the following values for the parameters: + For **Service name**, enter **com.amazonaws.*us-east-1*.guardduty-data**. Make sure to replace *us-east-1* with the correct Region. This must be the same Region as the EKS cluster that belongs to your Amazon Web Services account ID. + For [DNSOptions](https://docs.amazonaws.cn/AWSEC2/latest/APIReference/API_DnsOptions.html), enable private DNS option by setting it to `true`. ------ After you have followed the steps, see [Validating VPC endpoint configuration](validate-vpc-endpoint-config-runtime-monitoring.md) to ensure that the VPC endpoint was set up correctly. # Installing GuardDuty security agent manually on Amazon EKS resources This section describes how you can deploy the GuardDuty security agent for the first time for specific EKS clusters. Before you proceed with this section, make sure you have already set up the prerequisites and enabled Runtime Monitoring for your accounts. The GuardDuty security agent (EKS add-on) will not work if you do not enable Runtime Monitoring. Choose your preferred access method to deploy the GuardDuty security agent for the first time. ------ #### [ Console ] 1. Open the Amazon EKS console at [https://console.amazonaws.cn/eks/home\$1/clusters](https://console.amazonaws.cn/eks/home#/clusters). 1. Choose your **Cluster name**. 1. Choose the **Add-ons** tab. 1. Choose **Get more add-ons**. 1. On the **Select add-ons** page, choose **Amazon GuardDuty EKS Runtime Monitoring**. 1. GuardDuty recommends choosing the latest and default agent **Version**. 1. On the **Configure selected add-on settings** page, use the default settings. If the **Status** of your EKS add-on is **Requires activation**, choose **Activate GuardDuty**. This action will open the GuardDuty console to configure Runtime Monitoring for your accounts. 1. After you've configured Runtime Monitoring for your accounts, switch back to the Amazon EKS console. The **Status** of your EKS add-on should have changed to **Ready to install**. 1. **(Optional) Providing EKS add-on configuration schema** For the add-on **Version**, if you choose **v1.5.0** or above, Runtime Monitoring supports configuring specific parameters of the GuardDuty agent. For information about parameter ranges, see [Configure EKS add-on parameters](guardduty-configure-security-agent-eks-addon.md). 1. Expand **Optional configuration settings** to view the configurable parameters and their expected value and format. 1. Set the parameters. The values must be in the range provided in [Configure EKS add-on parameters](guardduty-configure-security-agent-eks-addon.md). 1. Choose **Save changes** to create the add-on based on the advanced configuration. 1. For **Conflict resolution method**, the option that you choose will be used to resolve a conflict when you update the value of a parameter to a non-default value. For more information about the listed options, see [resolveConflicts](https://docs.amazonaws.cn/eks/latest/APIReference/API_UpdateAddon.html#AmazonEKS-UpdateAddon-request-resolveConflicts) in the *Amazon EKS API Reference*. 1. Choose **Next**. 1. On the **Review and create** page, verify all the details, and choose **Create**. 1. Navigate back to the cluster details and choose the **Resources** tab. 1. You can view the new pods with the prefix **aws-guardduty-agent**. ------ #### [ API/CLI ] You can configure the Amazon EKS add-on agent (`aws-guardduty-agent`) using either of the following options: + Run [CreateAddon](https://docs.amazonaws.cn/eks/latest/APIReference/API_CreateAddon.html) for your account. + **Note** For the add-on `version`, if you choose **v1.5.0 or above**, Runtime Monitoring supports configuring specific parameters of the GuardDuty agent. For more information, see [Configure EKS add-on parameters](guardduty-configure-security-agent-eks-addon.md). Use the following values for the request parameters: + For `addonName`, enter `aws-guardduty-agent`. You can use the following Amazon CLI example when using configurable values supported for add-on versions `v1.5.0` or above. Make sure to replace the placeholder values highlighted in red and the associated `Example.json` with the configured values. ``` aws eks create-addon --region us-east-1 --cluster-name myClusterName --addon-name aws-guardduty-agent --addon-version v1.12.1-eksbuild.2 --configuration-values 'file://example.json' ``` **Example.json** ``` { "priorityClassName": "aws-guardduty-agent.priorityclass-high", "dnsPolicy": "Default", "resources": { "requests": { "cpu": "237m", "memory": "512Mi" }, "limits": { "cpu": "2000m", "memory": "2048Mi" } } } ``` + For information about supported `addonVersion`, see [Kubernetes versions supported by GuardDuty security agent](prereq-runtime-monitoring-eks-support.md#gdu-agent-supported-k8-version). ------ **Private DNS names for VPC endpoint** By default, the security agent resolves and connects to the private DNS name of the VPC endpoint. For a non-FIPS endpoint, your private DNS will appear in the following format: Non-FIPS endpoint – `guardduty-data.us-east-1.amazonaws.com` The Amazon Web Services Region, *us-east-1*, will change based on your Region. # Updating security agent manually for Amazon EKS resources When you manage the GuardDuty security agent manually, you are responsible to update it for your account. For notification about new agent versions, you can subscribe to an RSS feed to [GuardDuty security agent release versions](runtime-monitoring-agent-release-history.md). You can update the security agent to the latest version to benefit from the added support and improvements. If your current agent version is reaching an end of standard support, then to continue using Runtime Monitoring (or EKS Runtime Monitoring), you must update to a next available or the latest agent version. **Prerequisite** Before you update the security agent version, make sure that the agent version that you're planning to use now, is compatible with your Kubernetes version. For more information, see [Kubernetes versions supported by GuardDuty security agent](prereq-runtime-monitoring-eks-support.md#gdu-agent-supported-k8-version). ------ #### [ Console ] 1. Open the Amazon EKS console at [https://console.amazonaws.cn/eks/home\$1/clusters](https://console.amazonaws.cn/eks/home#/clusters). 1. Choose your **Cluster name**. 1. Under the **Cluster info**, choose the **Add-ons** tab. 1. Under the **Add-ons** tab, select **GuardDuty EKS Runtime Monitoring**. 1. Choose **Edit** to update the agent details. 1. On the **Configure GuardDuty EKS Runtime Monitoring** page, update the details. 1. **(Optional) Updating Optional configuration settings** If your EKS add-on **Version** is *1.5.0* or above, you can also update the add-on configuration schema. 1. Expand **Optional configuration settings** to view the configuration schema. 1. Update the parameter values based on the range provided in [Configure EKS add-on parameters](guardduty-configure-security-agent-eks-addon.md). 1. Choose **Save changes** to start the update. 1. For **Conflict resolution method**, the option that you choose will be used to resolve a conflict when you update the value of a parameter to a non-default value. For more information about the listed options, see [resolveConflicts](https://docs.amazonaws.cn/eks/latest/APIReference/API_UpdateAddon.html#AmazonEKS-UpdateAddon-request-resolveConflicts) in the *Amazon EKS API Reference*. ------ #### [ API/CLI ] To update the GuardDuty security agent for your Amazon EKS clusters, see [Updating an add-on](https://docs.amazonaws.cn/eks/latest/userguide/managing-add-ons.html#updating-an-add-on). **Note** For the add-on `version`, if you choose **1.5.0 or above**, Runtime Monitoring supports configuring specific parameters of the GuardDuty agent. For information about parameter ranges, see [Configure EKS add-on parameters](guardduty-configure-security-agent-eks-addon.md). You can use the following Amazon CLI example when using configurable values supported for add-on versions *1.5.0 and above*. Make sure to replace the placeholder values highlighted in red and the associated `Example.json` with the configured values. ``` aws eks update-addon --region us-east-1 --cluster-name myClusterName --addon-name aws-guardduty-agent --addon-version v1.12.1-eksbuild.2 --configuration-values 'file://example.json' ``` **Example.json** ``` { "priorityClassName": "aws-guardduty-agent.priorityclass-high", "dnsPolicy": "Default", "resources": { "requests": { "cpu": "237m", "memory": "512Mi" }, "limits": { "cpu": "2000m", "memory": "2048Mi" } } } ``` ------ If your Amazon EKS add-on version is 1.5.0 or above, and you have configured the add-on schema, you can verify whether or not the values appear correctly for your cluster. For more information, see [Verifying configuration schema updates](guardduty-configure-security-agent-eks-addon.md#gdu-verify-eks-add-on-configuration-param). # Configure GuardDuty security agent (add-on) parameters for Amazon EKS Configure EKS add-on parameters You can configure specific parameters of your GuardDuty security agent for Amazon EKS. This support is available for GuardDuty security agent version 1.5.0 and above. For information about latest add-on versions, see [GuardDuty security agent versions for Amazon EKS resources](runtime-monitoring-agent-release-history.md#eks-runtime-monitoring-agent-release-history). **Why should I update the security agent configuration schema** Configuration schema for the GuardDuty security agent is the same across all containers within your Amazon EKS clusters. When the default values do not align with the associated workloads and instance size, consider configuring the CPU settings, memory settings, `PriorityClass`, and `dnsPolicy` settings. Regardless of how you manage the GuardDuty agent for your Amazon EKS clusters, you can configure or update the existing configuration of these parameters. ## Automated agent configuration behavior with configured parameters When GuardDuty manages the security agent (EKS add-on) on your behalf, it updates the add-on, as needed. GuardDuty will set the value of the configurable parameters to a default value. However, you can still update the parameters to a desired value. If this leads to a conflict, the default option to [resolveConflicts](https://docs.amazonaws.cn/eks/latest/APIReference/API_UpdateAddon.html#AmazonEKS-UpdateAddon-request-resolveConflicts) is `None`. ## Configurable parameters and values For information about the steps to configure the add-on parameters, see: + [Installing GuardDuty security agent manually on Amazon EKS resources](eksrunmon-deploy-security-agent.md) or + [Updating security agent manually for Amazon EKS resources](eksrunmon-update-security-agent.md) The following tables provide the ranges and values that you can use to deploy the Amazon EKS add-on manually or update the existing add-on settings. **CPU settings** [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/guardduty/latest/ug/guardduty-configure-security-agent-eks-addon.html) The `disableCpuLimits` parameter is available for GuardDuty security agent version 1.12.1-eksbuild.3 and later. On earlier versions, the add-on does not support this parameter, and the Amazon EKS add-on APIs (`CreateAddon`, `UpdateAddon`) return a validation error if you specify it. When you set `disableCpuLimits` to `true`, the security agent pod does not enforce a CPU limit. Other resource settings are unaffected. To disable CPU limits, use the following configuration: ``` {"resources":{"disableCpuLimits":true}} ``` **Memory settings** [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/guardduty/latest/ug/guardduty-configure-security-agent-eks-addon.html) **`PriorityClass` settings** When GuardDuty creates an Amazon EKS add-on for you, the assigned `PriorityClass` is `aws-guardduty-agent.priorityclass`. This means that no action will be taken based on the priority of the agent pod. You can configure this add-on parameter by choosing one of the following `PriorityClass` options: [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/guardduty/latest/ug/guardduty-configure-security-agent-eks-addon.html) **1** Kubernetes provides these two `PriorityClass` options – `system-cluster-critical` and `system-node-critical`. For more information, see [PriorityClass](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/#how-to-use-priority-and-preemption) in the *Kubernetes documentation*. **`dnsPolicy` settings** Choose one of the following DNS policy options that Kubernetes supports. When no configuration is specified, `ClusterFirst` is used as the default value. + `ClusterFirst` + `ClusterFirstWithHostNet` + `Default` For information about these policies, see [Pod's DNS Policy](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-s-dns-policy) in the *Kubernetes documentation*. ## Verifying configuration schema updates After you have configured the parameters, perform the following steps to verify that the configuration schema has been updated: 1. Open the Amazon EKS console at [https://console.amazonaws.cn/eks/home\$1/clusters](https://console.amazonaws.cn/eks/home#/clusters). 1. In the navigation pane, choose **Clusters**. 1. On the **Clusters** page, select the **Cluster name** for which you want to verify the updates. 1. Choose the **Resources** tab. 1. From the **Resource types** pane, under **Workloads**, choose **DaemonSets**. 1. Select **aws-guardduty-agent**. 1. On the **aws-guardduty-agent** page, choose **Raw view** to view the unformatted JSON response. Verify that the configurable parameters display the value that you provided. After you verify, switch to the GuardDuty console. Select the corresponding Amazon Web Services Region and view the coverage status for your Amazon EKS clusters. For more information, see [Runtime coverage and troubleshooting for Amazon EKS clusters](eks-runtime-monitoring-coverage.md). # Validating VPC endpoint configuration After you install the security agent manually or through GuardDuty automated configuration, you can use this document to validate that the VPC endpoint configuration. You can also use these steps after troubleshooting any [runtime coverage issue](https://docs.amazonaws.cn/guardduty/latest/ug/runtime-monitoring-assessing-coverage.html) for a resource type. You can ensure that the steps worked as expected and the coverage status would potentially show up as **Healthy**. Use the following steps to validate that VPC endpoint configuration for your resource type is set up correctly in the VPC owner account: 1. Sign in to the Amazon Web Services Management Console and open the Amazon VPC console at [https://console.amazonaws.cn/vpc/](https://console.amazonaws.cn/vpc/). 1. In the navigation pane, under **Virtual private cloud**, choose **Your VPCs**. 1. On the **Your VPCs** page, choose **IPv4 CIDR** associated with your **VPC ID**. 1. In the navigation pane, under **Virtual private cloud**, choose **Endpoints**. 1. In the **Endpoints** table, select the row that has the **Service name** similar to **com.amazonaws.*us-east-1*.guardduty-data**. The Region (`us-east-1`) might be different for your endpoint. 1. A panel for endpoint details will appear. Under the **Security Groups** tab, select the associated **Group ID** link for more details. 1. In the **Security Groups** table, select the row that with the associated **Security group ID** to view the details. 1. Under the **Inbound rules** tab, ensure that there is an ingress policy with **Port range** as **443** and **Source** as the value copied from the **IPv4 CIDR**. Inbound rules control the incoming traffic that is allowed to reach the instance. The following image shows the inbound rules for a security group that is associated with the VPC used by the GuardDuty security agent. If you don't already have a security group that has an in-bound port 443 enabled, [Create a security group](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/working-with-security-groups.html#creating-security-group) in the *Amazon EC2 User Guide*. If there is an issue while restricting the in-bound permissions to your VPC (or cluster), provide the support to in-bound 443 port from any IP address (0.0.0.0/0). The following list includes good to know items after you install or update the security agent. **Assess runtime coverage** The next step after installing or updating your security agent is to assess runtime coverage of your resources. If the runtime coverage status is **Unhealthy**, then you must troubleshoot the issue. For more information, see [Runtime coverage issues and troubleshooting](runtime-monitoring-assessing-coverage.md). If the status of the runtime coverage shows as **Healthy**, it indicates that Runtime Monitoring is able to collect and receive runtime events. For a list of these events, see [Collected runtime event types](runtime-monitoring-collected-events.md). **Private DNS name for endpoint** After you install the GuardDuty security agent for your resources, by default, it will resolve and connect to the private DNS name of the VPC endpoint. For a non-FIPS endpoint, the private DNS will appear in the following format: `guardduty-data.us-east-1.amazonaws.com` The Amazon Web Services Region, *us-east-1*, will change based on your Region. **A host may get installed with two security agents** When working with GuardDuty security agent for an Amazon EC2 instance, you might install and use the agent on the underlying host within an Amazon EKS cluster. If you had already deployed a security agent on that EKS cluster, the same host could have two security agents running on it at the same time. For information about how GuardDuty works in this scenario, see [Security agents on same host](two-security-agents-installed-on-ec2-node.md).