EKS 보호 조사 결과 해결 - Amazon GuardDuty
잠재적 구성 문제잠재적으로 손상된 Kubernetes 사용자 해결잠재적으로 손상된 Kubernetes 포드 해결잠재적으로 손상된 컨테이너 이미지 수정잠재적으로 손상된 Kubernetes 노드 해결

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

EKS 보호 조사 결과 해결

Amazon은 계정에 EKS 보호가 활성화된 경우 잠재적인 Kubernetes 보안 문제를 나타내는 결과를 GuardDuty 생성합니다. 자세한 내용은 EKS 보호 단원을 참조하십시오. 다음 섹션에서는 이러한 시나리오에 대한 권장 해결 단계를 설명합니다. 특정 문제 해결 조치는 해당 결과 유형의 항목에 설명되어 있습니다. 활성 결과 유형 표에서 선택하여 결과 유형에 대한 전체 정보에 액세스할 수 있습니다.

EKS 보호 결과 유형 중 하나라도 예상대로 생성된 경우 향후 알림을 방지하기 의 억제 규칙 GuardDuty 위해를 추가하는 것을 고려할 수 있습니다.

다양한 유형의 공격 및 구성 문제로 인해 보호 조사 결과가 트리거 GuardDuty EKS될 수 있습니다. 이 가이드는 클러스터에 대한 GuardDuty 조사 결과의 근본 원인을 식별하는 데 도움이 되며 적절한 해결 지침을 간략하게 설명합니다. 다음은 GuardDuty Kubernetes 조사 결과로 이어지는 주요 근본 원인입니다.

참고

Kubernetes 버전 1.14 이전에는 system:unauthenticated 그룹이 system:basic-user ClusterRoles 기본적으로 system:discovery 및에 연결되었습니다. 이로 인해 익명 사용자의 의도하지 않은 액세스가 허용될 수 있습니다. 클러스터 업데이트는 이러한 권한을 철회하지 않으므로 클러스터를 버전 1.14 이상으로 업데이트한 경우에도 이러한 권한이 계속 유지될 수 있습니다. system:unauthenticated 그룹에서 이러한 권한을 분리하는 것이 좋습니다.

이러한 권한 제거에 대한 자세한 내용은 Amazon 사용 설명서의 Amazon 보안 모범 사례를 EKS 참조하세요. EKS

잠재적 구성 문제

결과에 구성 문제가 있는 경우 해당 결과의 해결 섹션에서 특정 문제를 해결하는 방법에 대한 지침을 참조하세요. 자세한 내용은 구성 문제를 나타내는 다음 결과 유형을 참조하세요.

잠재적으로 손상된 Kubernetes 사용자 해결

GuardDuty 조사 결과에서 식별된 사용자가 예상치 못한 API 작업을 수행한 경우 조사 결과는 손상된 Kubernetes 사용자를 나타낼 수 있습니다. 콘솔의 Kubernetes 사용자 세부 정보 섹션 또는 조사 결과 resource.kubernetesDetails.kubernetesUserDetails의에서 사용자를 식별할 수 있습니다JSON. 이러한 사용자 세부 정보에는 user name, uid 및 사용자가 속한 Kubernetes 그룹이 포함됩니다.

사용자가 IAM엔터티를 사용하여 워크로드에 액세스하는 경우 Access Key details 섹션을 사용하여 IAM 역할 또는 사용자의 세부 정보를 식별할 수 있습니다. 다음 사용자 유형 및 해결 지침을 참조하세요.

참고

Amazon Detective를 사용하여 조사 결과에서 식별된 IAM 역할 또는 사용자를 추가로 조사할 수 있습니다. GuardDuty 콘솔에서 조사 결과 세부 정보를 보는 동안 Detective에서 조사를 선택합니다. 그런 다음 나열된 항목에서 AWS 사용자 또는 역할을 선택하여 Detective에서 조사합니다.

기본 제공 Kubernetes 관리자 - Amazon에서 클러스터를 생성한 IAM 자격 증명EKS에 할당한 기본 사용자입니다. 이 사용자 유형은 사용자 이름 kubernetes-admin으로 식별됩니다.

기본 제공 Kubernetes 관리자의 액세스 권한 철회:

OIDC 인증된 사용자 - OIDC 공급자를 통해 액세스 권한을 부여한 사용자입니다. 일반적으로 OIDC 사용자는 이메일 주소를 사용자 이름으로 가집니다. 클러스터가 다음 명령과 OIDC 함께를 사용하는지 확인할 수 있습니다. aws eks list-identity-provider-configs --cluster-name your-cluster-name

OIDC 인증된 사용자의 액세스를 취소하려면:

  1. OIDC 공급자에서 해당 사용자의 자격 증명을 교체합니다.

  2. 사용자가 액세스할 수 있었던 모든 보안 암호를 교체합니다.

AWS-인증 ConfigMap 정의 사용자 AWS- 인증을 통해 액세스 권한이 부여된 IAM 사용자입니다 ConfigMap. 자세한 내용은 &EKS; 사용 설명서의 클러스터의 사용자 또는 IAM 역할 관리를 참조하세요. 다음 kubectl edit configmaps aws-auth --namespace kube-system 명령을 사용하여 권한을 검토할 수 있습니다.

사용자의 액세스를 AWS ConfigMap 취소하려면:

  1. 다음 명령을 사용하여를 엽니다 ConfigMap.

    kubectl edit configmaps aws-auth --namespace kube-system

  2. mapRoles 또는 mapUsers 섹션 아래의 역할 또는 사용자 항목을 GuardDuty 조사 결과의 Kubernetes 사용자 세부 정보 섹션에 보고된 것과 동일한 사용자 이름으로 식별합니다. 다음 예시에서는 관리자가 결과에서 식별되었습니다.

    apiVersion: v1
data:
  mapRoles: |
    - rolearn: arn:aws:iam::444455556666:role/eksctl-my-cluster-nodegroup-standard-wo-NodeInstanceRole-1WP3NUE3O6UCF
      user name: system:node:EC2_PrivateDNSName
      groups:
        - system:bootstrappers
        - system:nodes
  mapUsers: |
    - userarn: arn:aws:iam::123456789012:user/admin
      username: admin
      groups:
        - system:masters
    - userarn: arn:aws:iam::111122223333:user/ops-user
      username: ops-user
      groups:
        - system:masters

  3. 에서 해당 사용자를 제거합니다 ConfigMap. 다음 예시에서는 관리자가 결과에서 제거되었습니다.

    apiVersion: v1
data:
  mapRoles: |
    - rolearn: arn:aws:iam::111122223333:role/eksctl-my-cluster-nodegroup-standard-wo-NodeInstanceRole-1WP3NUE3O6UCF
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes
  mapUsers: |
    - userarn: arn:aws:iam::111122223333:user/ops-user
      username: ops-user
      groups:
        - system:masters

  4. userType이 사용자이거나 사용자가 맡은 역할인 경우:

    1. 해당 사용자의 액세스 키를 교체합니다.

    2. 사용자가 액세스할 수 있었던 모든 보안 암호를 교체합니다.

    3. 자세한 내용은 내 AWS 계정의 정보를 검토하세요.

결과에 resource.accessKeyDetails 섹션이 없는 경우 사용자는 Kubernetes 서비스 계정입니다.

서비스 계정 - 서비스 계정은 포드의 ID를 제공하고 system:serviceaccount:namespace:service_account_name 형식의 사용자 이름으로 식별할 수 있습니다.

서비스 계정에 대한 액세스 권한 철회:

  1. 서비스 계정 보안 인증 정보를 교체합니다.

  2. 다음 섹션의 포드 손상 안내를 검토합니다.

잠재적으로 손상된 Kubernetes 포드 해결

가 resource.kubernetesDetails.kubernetesWorkloadDetails 섹션 내 포드 또는 워크로드 리소스의 세부 정보를 GuardDuty 지정하는 경우 해당 포드 또는 워크로드 리소스가 손상되었을 수 있습니다. GuardDuty 조사 결과는 단일 포드가 손상되었거나 상위 수준 리소스를 통해 여러 포드가 손상되었음을 나타낼 수 있습니다. 손상된 포드를 식별하는 방법에 대한 지침은 다음 보안 침해 시나리오를 참조하세요.

단일 포드 손상

resource.kubernetesDetails.kubernetesWorkloadDetails 섹션 내 type 필드가 포드인 경우 결과에서 단일 포드가 식별됩니다. 이름 필드는 포드의 name이고 namespace 필드는 네임스페이스입니다.

파드를 실행하는 워커 노드를 식별하는 방법에 대한 자세한 내용은 문제가 있는 파드 및 워커 노드 식별을 참조하세요.

워크로드 리소스를 통해 포드가 손상됨

resource.kubernetesDetails.kubernetesWorkloadDetails 섹션 내 type 필드에서 워크로드 리소스(예: Deployment)가 식별되면 해당 워크로드 리소스 내의 모든 포드가 손상되었을 수 있습니다.

워크로드 리소스의 모든 파드와 해당 파드가 실행 중인 노드를 식별하는 방법에 대한 자세한 내용은 워크로드 이름을 사용하여 문제가 있는 파드 및 워커 노드 식별을 참조하세요.

서비스 계정을 통해 포드가 손상됨

GuardDuty 조사 결과 resource.kubernetesDetails.kubernetesUserDetails 섹션에서 서비스 계정을 식별하는 경우 식별된 서비스 계정을 사용하는 포드가 손상되었을 수 있습니다. 형식이 system:serviceaccount:namespace:service_account_name인 경우 결과에 보고된 사용자 이름은 서비스 계정입니다.

서비스 계정을 사용하여 모든 파드와 실행 중인 노드를 식별하는 방법에 대한 자세한 내용은 서비스 계정 이름을 사용하여 문제가 있는 파드 및 워커 노드 식별하기를 참조하세요.

손상된 포드와 해당 포드가 실행 중인 노드를 모두 식별한 후에는 포드를 격리하고, 자격 증명을 교체하고, 포렌식 분석을 위한 데이터를 수집하는 Amazon EKS 모범 사례 가이드를 참조하세요.

잠재적으로 손상된 포드를 해결하려면:

  1. 포드를 손상시킨 취약성을 식별합니다.

  2. 해당 취약성에 대한 수정 사항을 구현하고 새 대체 포드를 시작합니다.

  3. 취약한 포드를 삭제합니다.

    자세한 내용은 손상된 포드 또는 워크로드 리소스 재배포를 참조하세요.

작업자 노드에 포드가 다른 AWS 리소스에 액세스할 수 있는 IAM 역할이 할당된 경우 인스턴스에서 해당 역할을 제거하여 공격으로 인한 추가 손상을 방지합니다. 마찬가지로 포드에 IAM 역할이 할당된 경우 다른 워크로드에 영향을 주지 않고 역할에서 IAM 정책을 안전하게 제거할 수 있는지 평가합니다.

잠재적으로 손상된 컨테이너 이미지 수정

GuardDuty 조사 결과가 포드 손상을 나타내는 경우 포드를 시작하는 데 사용되는 이미지가 잠재적으로 악성이거나 손상되었을 수 있습니다. GuardDuty 조사 결과는 resource.kubernetesDetails.kubernetesWorkloadDetails.containers.image 필드 내의 컨테이너 이미지를 식별합니다. 맬웨어를 스캔하여 이미지가 악성인지 확인할 수 있습니다.

잠재적으로 손상된 컨테이너 이미지를 수정합니다

  1. 이미지 사용을 즉시 중지하고 이미지 리포지토리에서 이미지를 제거합니다.

  2. 손상 가능성이 있는 이미지를 사용하여 모든 포드를 식별합니다.

    자세한 내용은 잠재적으로 취약하거나 손상된 컨테이너 이미지 및 워커 노드가 있는 파드 식별하기를 참조하세요.

  3. 잠재적으로 손상된 파드를 격리하고, 자격 증명을 교체하고, 분석을 위해 데이터를 수집하세요. 자세한 내용은 Amazon EKS 모범 사례 가이드를 참조하세요.

  4. 잠재적으로 손상된 이미지를 사용하여 모든 포드를 삭제합니다.

잠재적으로 손상된 Kubernetes 노드 해결

GuardDuty 조사 결과에서 식별된 사용자가 노드 자격 증명을 나타내는 경우 또는 조사 결과가 권한이 있는 컨테이너를 사용하는 것을 나타내는 경우 조사 결과는 노드 손상을 나타낼 수 있습니다.

사용자 이름 필드에 system:node:node name 형식이 있는 경우 사용자 ID는 워커 노드입니다. 예: system:node:ip-192-168-3-201.ec2.internal. 이는 공격자가 노드에 대한 액세스 권한을 얻었고 노드의 자격 증명을 사용하여 Kubernetes API 엔드포인트와 통신하고 있음을 나타냅니다.

결과에 나열된 하나 이상의 컨테이너에 resource.kubernetesDetails.kubernetesWorkloadDetails.containers.securityContext.privileged 결과 필드가 True로 설정된 경우 결과에서 권한이 있는 컨테이너의 사용을 나타냅니다.

잠재적으로 손상된 노드를 해결하려면:

  1. 포렌식 분석을 위해 포드를 격리하고, 자격 증명을 교체하고, 데이터를 수집하세요.

    자세한 내용은 Amazon EKS 모범 사례 가이드를 참조하세요.

  2. 손상 가능성이 있는 노드에서 실행 중인 모든 파드에서 사용하는 서비스 계정을 식별합니다. 권한을 검토하고 필요한 경우 서비스 계정을 교체합니다.

  3. 잠재적으로 손상된 노드를 종료합니다.