기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# Amazon EKS 클러스터에서 Runtime Monitoring이 작동하는 방식
<a name="how-runtime-monitoring-works-eks"></a>

런타임 모니터링은 GuardDuty 보안 에이전트라고도 하는 [EKS 애드온 기능 `aws-guardduty-agent`](https://docs.aws.amazon.com/eks/latest/userguide/eks-add-ons.html#workloads-add-ons-available-eks)을 사용합니다. GuardDuty 보안 에이전트가 EKS 클러스터에 배포되면 GuardDuty는 이러한 EKS 클러스터에 대한 런타임 이벤트를 수신할 수 있습니다.

**참고**  
Runtime Monitoring은 Amazon EC2 인스턴스 및 Amazon EKS 자율 모드에서 실행되는 Amazon EKS 클러스터를 **지원합니다**.  
Runtime Monitoring은 Amazon EKS Hybrid Nodes가 있는 Amazon EKS 클러스터와 AWS Fargate에서 실행되는 클러스터를 **지원하지 않습니다**.  
Amazon EKS 기능에 관한 자세한 내용은 **Amazon EKS 사용 설명서**의 [Amazon EKS란 무엇입니까?](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html)를 참조하세요.

계정 또는 클러스터 수준에서 Amazon EKS 클러스터의 런타임 이벤트를 모니터링할 수 있습니다. 위협 탐지를 위해 모니터링하려는 Amazon EKS 클러스터에 대해서만 GuardDuty 보안 에이전트를 관리할 수 있습니다. GuardDuty 보안 에이전트는 수동으로 관리하거나 자동 에이전트 구성을 사용하여 GuardDuty가 사용자를 대신하여 관리하도록 허용하여 관리할 수 있습니다.

자동 에이전트 구성 접근 방식을 사용하여 GuardDuty가 사용자를 대신하여 보안 에이전트의 배포를 관리할 수 있도록 하면 ** Amazon Virtual Private Cloud(Amazon VPC) 엔드포인트가 자동으로 생성**됩니다. 보안 에이전트는 이 Amazon VPC 엔드포인트를 사용하여 런타임 이벤트를 GuardDuty에 전달합니다.

VPC 엔드포인트와 함께 GuardDuty는 새 보안 그룹도 생성합니다. 인바운드(인그레스) 규칙은 보안 그룹과 연결된 리소스에 도달할 수 있는 트래픽을 제어합니다. GuardDuty는 리소스의 VPC CIDR 범위와 일치하는 인바운드 규칙을 추가하고 CIDR 범위가 변경될 때도 이에 적응합니다. 자세한 내용은 *Amazon VPC 사용 설명서*에서 [VPC CIDR 범위](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-cidr-blocks.html)를 참조하세요.

**참고**  
VPC 엔드포인트 사용에 대한 추가 비용은 없습니다.
자동화 에이전트를 사용하여 중앙 집중식 VPC 작업 - 리소스 유형에 GuardDuty 자동화 에이전트 구성을 사용하는 경우 GuardDuty는 모든 VPC에 대해 사용자를 대신하여 VPCs 엔드포인트를 생성합니다. 여기에는 중앙 집중식 VPC 및 스포크 VPCs 포함됩니다. GuardDuty는 중앙 집중식 VPC에 대해서만 VPC 엔드포인트 생성을 지원하지 않습니다. 중앙 집중식 VPC의 작동 방식에 대한 자세한 내용은 백서 - 확장 가능하고 안전한 다중 [VPC 네트워크 인프라 구축의 인터페이스 VPC 엔드포인트](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-access-to-vpc-private-endpoints.html#interface-vpc-endpoints)를 참조하세요. *AWS AWS * 

## Amazon EKS 클러스터에서 GuardDuty 보안 에이전트를 관리하는 방법
<a name="eksrunmon-approach-to-monitor-eks-clusters"></a>

2023년 9월 13일 이전에는 계정 수준에서 보안 에이전트를 관리하도록 GuardDuty를 구성할 수 있었습니다. 이 동작은 기본적으로 GuardDuty에서 AWS 계정에 속하는 모든 EKS 클러스터의 보안 에이전트를 관리함을 나타냅니다. 이제 GuardDuty에서 보안 에이전트를 관리할 EKS 클러스터를 선택하는 데 도움이 되도록 세분화된 기능이 제공됩니다.

[GuardDuty 보안 에이전트를 수동으로 관리](#eks-runtime-using-gdu-agent-manually) 방법을 선택한 경우에도 모니터링하려는 EKS 클러스터를 선택할 수 있습니다. 그러나 에이전트를 수동으로 관리하려면에 대한 Amazon VPC 엔드포인트를 생성 AWS 계정 해야 합니다.

**참고**  
GuardDuty 보안 에이전트를 관리하는 데 사용하는 접근 방식과 무관하게 EKS 런타임 모니터링은 계정 수준에서 항상 활성화됩니다.

**Topics**
+ [GuardDuty를 통한 보안 에이전트 관리](#eks-runtime-using-gdu-agent-management-auto)
+ [GuardDuty 보안 에이전트를 수동으로 관리](#eks-runtime-using-gdu-agent-manually)

### GuardDuty를 통한 보안 에이전트 관리
<a name="eks-runtime-using-gdu-agent-management-auto"></a>

GuardDuty는 사용자를 대신하여 보안 에이전트를 배포 및 관리합니다. 언제든 다음 접근 방식 중 하나를 사용하여 계정의 EKS 클러스터를 모니터링할 수 있습니다.

**Topics**
+ [모든 EKS 클러스터 모니터링](#gdu-security-agent-all-eks-custers)
+ [선택적 EKS 클러스터 제외](#eks-runtime-using-exclusion-tags)
+ [선택적 EKS 클러스터 포함](#eks-runtime-using-inclusion-tags)

#### 모든 EKS 클러스터 모니터링
<a name="gdu-security-agent-all-eks-custers"></a>

GuardDuty에서 계정의 모든 EKS 클러스터에 대해 보안 에이전트를 배포 및 관리하도록 하려는 경우 이 접근 방식을 사용합니다. 기본적으로 GuardDuty는 사용자 계정에 생성된 잠재적으로 새로운 EKS 클러스터에도 보안 에이전트를 배포합니다.

**이 접근 방식을 사용할 때의 영향**  
+ GuardDuty는 Amazon Virtual Private Cloud(Amazon VPC) 엔드포인트를 생성하여, 이 엔드포인트를 통해 GuardDuty 보안 에이전트는 GuardDuty에 런타임 이벤트를 제공합니다. GuardDuty를 통해 보안 에이전트를 관리하는 경우 Amazon VPC 엔드포인트 생성에 따른 추가 비용은 없습니다.
+ 워커 노드에 활성 `guardduty-data` VPC 엔드포인트에 대해 유효한 네트워크 경로가 있어야 합니다. GuardDuty는 EKS 클러스터에 보안 에이전트를 배포합니다. Amazon Elastic Kubernetes Service(Amazon EKS)는 EKS 클러스터 내의 노드에 보안 에이전트 배포를 조정합니다.
+ GuardDuty는 IP 가용성을 기반으로 VPC 엔드포인트를 생성할 서브넷을 선택합니다. 고급 네트워크 토폴로지를 사용하는 경우 연결이 가능한지 검증해야 합니다.

#### 선택적 EKS 클러스터 제외
<a name="eks-runtime-using-exclusion-tags"></a>

GuardDuty에서 계정의 모든 EKS 클러스터에 대해(단, 선택적 EKS 클러스터 제외) 보안 에이전트를 관리하도록 하려는 경우 이 접근 방식을 사용합니다. 이 방법은 런타임 이벤트를 수신하지 않으려는 EKS 클러스터에 태그를 지정할 수 있는 태그 기반[1](#eks-runtime-inclusion-exclusion-tags) 접근 방식을 사용합니다. 사전 정의된 태그에는 키-값 쌍으로 `GuardDutyManaged`-`false`가 있어야 합니다.

**이 접근 방식을 사용할 때의 영향**  
이 방법을 사용하려면 모니터링에서 제외하려는 EKS 클러스터에 태그를 추가한 후에만 GuardDuty 에이전트 자동 관리를 활성화해야 합니다.  
따라서 [GuardDuty를 통한 보안 에이전트 관리](#eks-runtime-using-gdu-agent-management-auto)의 영향이 이 접근 방식에도 적용됩니다. GuardDuty 에이전트 자동 관리를 활성화하기 전에 태그를 추가하면 GuardDuty는 모니터링에서 제외된 EKS 클러스터의 보안 에이전트를 배포하지도 않고 관리하지도 않습니다.

**고려 사항**  
+ 자동 에이전트 구성을 활성화하기 전에 선택적 EKS 클러스터에 대해 태그 키-값 쌍을 `GuardDutyManaged`:`false`로 추가해야 합니다. 그렇지 않으면 태그를 사용할 때까지 GuardDuty 보안 에이전트가 모든 EKS 클러스터에 배포됩니다.
+ 신뢰할 수 있는 ID를 제외하고는 태그가 수정되지 않도록 해야 합니다.
**중요**  
서비스 제어 정책 또는 IAM 정책을 사용하여 EKS 클러스터의 `GuardDutyManaged` 태그 값을 수정하는 권한을 관리합니다. 자세한 내용은AWS Organizations 사용 설명서**의 [서비스 제어 정책(SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) 또는 IAM 사용 설명서**의 [AWS 리소스에 대한 액세스 제어](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html)를 참조하세요.
+ 모니터링하지 않으려는 잠재적으로 새로운 EKS 클러스터의 경우 이 EKS 클러스터를 생성할 때 `GuardDutyManaged`-`false` 키-값 쌍을 추가해야 합니다.
+ 이 접근 방식에도 [모든 EKS 클러스터 모니터링](#gdu-security-agent-all-eks-custers)에 대해 지정된 것과 동일한 고려 사항이 적용됩니다.

#### 선택적 EKS 클러스터 포함
<a name="eks-runtime-using-inclusion-tags"></a>

GuardDuty에서 계정의 선택적 EKS 클러스터에 대해서만 보안 에이전트를 배포하고 업데이트를 관리하도록 하려는 경우 이 접근 방식을 사용합니다. 이 방법은 런타임 이벤트를 수신하려는 EKS 클러스터에 태그를 지정할 수 있는 태그 기반[1](#eks-runtime-inclusion-exclusion-tags) 접근 방식을 사용합니다.

**이 접근 방식을 사용할 때의 영향**  
+ 포함 태그를 사용하면 GuardDuty는 키-값 쌍으로 `GuardDutyManaged`-`true` 태그가 지정된 선택적 EKS 클러스터에 대해서만 보안 에이전트를 자동으로 배포 및 관리합니다.
+ 이 접근 방식을 사용해도 [모든 EKS 클러스터 모니터링](#gdu-security-agent-all-eks-custers)에 대해 지정된 것과 동일한 영향을 미칩니다.

**고려 사항**  
+ `GuardDutyManaged` 태그의 값이 `true`로 설정되지 않으면 포함 태그가 예상대로 작동하지 않고 EKS 클러스터 모니터링에 영향을 미칠 수 있습니다.
+ 선택적 EKS 클러스터가 모니터링되도록 신뢰할 수 있는 ID를 제외하고는 태그가 수정되지 않도록 해야 합니다.
**중요**  
서비스 제어 정책 또는 IAM 정책을 사용하여 EKS 클러스터의 `GuardDutyManaged` 태그 값을 수정하는 권한을 관리합니다. 자세한 내용은AWS Organizations 사용 설명서**의 [서비스 제어 정책(SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) 또는 IAM 사용 설명서**의 [AWS 리소스에 대한 액세스 제어](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html)를 참조하세요.
+ 모니터링하지 않으려는 잠재적으로 새로운 EKS 클러스터의 경우 이 EKS 클러스터를 생성할 때 `GuardDutyManaged`-`false` 키-값 쌍을 추가해야 합니다.
+ 이 접근 방식에도 [모든 EKS 클러스터 모니터링](#gdu-security-agent-all-eks-custers)에 대해 지정된 것과 동일한 고려 사항이 적용됩니다.<a name="eks-runtime-inclusion-exclusion-tags"></a>

1 선택적 EKS 클러스터의 태그 지정에 대한 자세한 내용은 Amazon EKS 사용 설명서****의 [Amazon EKS 리소스 태깅](https://docs.aws.amazon.com/eks/latest/userguide/eks-using-tags.html)을 참조하세요.

### GuardDuty 보안 에이전트를 수동으로 관리
<a name="eks-runtime-using-gdu-agent-manually"></a>

GuardDuty에서 모든 EKS 클러스터에 수동으로 보안 에이전트를 배포 및 관리하도록 하려는 경우 이 접근 방식을 사용합니다. 계정에 EKS 런타임 모니터링이 활성화되어 있어야 합니다. EKS 런타임 모니터링을 활성화하지 않으면 GuardDuty 보안 에이전트가 예상대로 작동하지 않을 수 있습니다.

**이 접근 방식을 사용할 때의 영향**  
모든 계정 및이 기능을 사용할 수 AWS 리전 있는 EKS 클러스터 내에서 GuardDuty 보안 에이전트의 배포를 조정해야 합니다. 또한 GuardDuty가 릴리스할 때 에이전트 버전을 업데이트해야 합니다. EKS용 에이전트 버전에 대한 자세한 내용은 [Amazon EKS 리소스용 GuardDuty 보안 에이전트 버전](runtime-monitoring-agent-release-history.md#eks-runtime-monitoring-agent-release-history)을 참조하세요.

**고려 사항**  
새 클러스터와 워크로드가 지속적으로 배포되는 상황에서 적용 범위 격차를 모니터링하고 해결하면서 안전한 데이터 흐름을 지원해야 합니다.