잠재적 구성 문제 잠재적으로 침해된 Kubernetes 사용자 문제 해결 잠재적으로 손상될 수 있는 Kubernetes 포드 수정 잠재적으로 손상되었을 수 있는 컨테이너 이미지 수정 잠재적으로 손상될 수 있는 Kubernetes 노드의 문제 해결

EKS 감사 로그 모니터링 결과 해결

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

EKS 감사 로그 모니터링 결과 유형이 예상대로 생성된 경우 억제 규칙 추가를 통해 향후 알림을 방지하는 것을 고려할 수 있습니다.

다양한 유형의 공격과 구성 문제가 Kubernetes 탐지 결과를 유발할 수 있습니다. GuardDuty 이 가이드는 클러스터에 대한 GuardDuty 발견의 근본 원인을 식별하고 적절한 수정 지침을 설명하는 데 도움이 됩니다. GuardDuty 쿠버네티스 발견으로 이어지는 주요 근본 원인은 다음과 같습니다.

잠재적 구성 문제
잠재적으로 침해된 Kubernetes 사용자 문제 해결
잠재적으로 손상될 수 있는 Kubernetes 포드 수정
잠재적으로 손상될 수 있는 Kubernetes 노드의 문제 해결
잠재적으로 손상되었을 수 있는 컨테이너 이미지 수정

참고

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

이러한 권한을 제거하는 방법에 대한 자세한 내용은 Amazon EKS 사용 설명서의 Amazon EKS의 보안 모범 사례를 참조하십시오.

잠재적 구성 문제

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

Policy:Kubernetes/AnonymousAccessGranted
Policy:Kubernetes/ExposedDashboard
Policy:Kubernetes/AdminAccessToDefaultServiceAccount
Policy:Kubernetes/KubeflowDashboardExposed
다음으로 끝나는 모든 결과 SuccessfulAnonymousAccess

잠재적으로 침해된 Kubernetes 사용자 문제 해결

GuardDuty 탐지 결과에서 식별된 사용자가 예상치 못한 API 작업을 수행한 경우 탐지 결과는 Kubernetes 사용자가 침해되었음을 의미할 수 있습니다. 콘솔의 결과 세부 정보에 있는 Kubernetes 사용자 세부 정보 섹션 또는 결과 JSON의 resources.eksClusterDetails.kubernetesDetails.kubernetesUserDetails에서 사용자를 식별할 수 있습니다. 이러한 사용자 세부 정보에는 user name, uid 및 사용자가 속한 Kubernetes 그룹이 포함됩니다.

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

참고

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

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

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

Access Key details 섹션에서 userType을 찾습니다.
- userType이 역할이고 역할이 EC2 인스턴스 역할에 속하는 경우:
  - 해당 인스턴스를 식별한 다음 잠재적으로 손상된 Amazon EC2 인스턴스의 문제 해결의 지침을 따릅니다.
- userType이 사용자이거나 사용자가 맡은 역할인 경우:
  1. 해당 사용자의 액세스 키를 교체합니다.
  2. 사용자가 액세스할 수 있었던 모든 보안 암호를 교체합니다.
  3. 자세한 내용은 내 AWS 계정이 침해될 수 있는 정보를 검토하십시오.

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

OIDC 인증 사용자의 액세스 철회:

OIDC 공급자에서 해당 사용자의 보안 인증 정보를 교체합니다.
사용자가 액세스할 수 있었던 모든 보안 암호를 교체합니다.

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

사용자 액세스 취소하기: AWS ConfigMap

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


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

검색 결과의 Kubernetes 사용자 세부 정보 섹션에 보고된 것과 동일한 사용자 이름을 사용하여 MapRoles 또는 MapUsers 섹션에서 역할 또는 사용자 항목을 식별하십시오. GuardDuty 다음 예시에서는 관리자가 결과에서 식별되었습니다.


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

에서 해당 사용자를 제거하세요. 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

userType이 사용자이거나 사용자가 맡은 역할인 경우:
1. 해당 사용자의 액세스 키를 교체합니다.
2. 사용자가 액세스할 수 있었던 모든 보안 암호를 교체합니다.
3. 자세한 내용은 내 AWS 계정의 정보가 유출될 수 있다는 정보를 검토하십시오.

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

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

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

서비스 계정 보안 인증 정보를 교체합니다.
다음 섹션의 포드 손상 안내를 검토합니다.

잠재적으로 손상될 수 있는 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 모범 사례 가이드를 참조하여 파드를 분리하고, 자격 증명을 교체하고, 포렌식 분석을 위한 데이터를 수집하십시오.

잠재적으로 손상되었을 수 있는 파드를 해결하려면:

포드를 손상시킨 취약성을 식별합니다.
해당 취약성에 대한 수정 사항을 구현하고 새 대체 포드를 시작합니다.
취약한 포드를 삭제합니다.

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

작업자 노드에 파드가 다른 AWS 리소스에 액세스할 수 있도록 허용하는 IAM 역할을 할당받은 경우, 해당 역할을 인스턴스에서 제거하여 공격으로 인한 추가 피해를 방지하세요. 마찬가지로 포드에 IAM 역할이 할당된 경우 다른 워크로드에 영향을 미치지 않으면서 역할에서 IAM 정책을 안전하게 제거할 수 있는지 평가합니다.

잠재적으로 손상되었을 수 있는 컨테이너 이미지 수정

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

잠재적으로 손상되었을 수 있는 컨테이너 이미지를 수정하려면:

이미지 사용을 즉시 중지하고 이미지 리포지토리에서 이미지를 제거합니다.
손상 가능성이 있는 이미지를 사용하여 모든 포드를 식별하십시오.

자세한 내용은 잠재적으로 취약하거나 손상된 컨테이너 이미지와 워커 노드가 있는 포드 식별을 참조하십시오.
잠재적으로 손상될 수 있는 파드를 분리하고, 자격 증명을 교체하고, 분석을 위한 데이터를 수집하세요. 자세한 내용은 Amazon EKS 모범 사례 가이드를 참조하십시오.
손상 가능성이 있는 이미지를 사용하는 모든 포드를 삭제하십시오.

잠재적으로 손상될 수 있는 Kubernetes 노드의 문제 해결

GuardDuty 검색 결과에서 식별된 사용자가 노드 ID를 나타내거나 검색 결과가 권한 있는 컨테이너의 사용을 나타내는 경우, 검색 결과는 노드 손상을 의미할 수 있습니다.

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

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

잠재적으로 손상된 노드를 수정하려면:

포드를 격리하고, 자격 증명을 교체하고, 포렌식 분석을 위한 데이터를 수집하십시오.

자세한 내용은 Amazon EKS 모범 사례 가이드를 참조하십시오.
잠재적으로 손상된 노드에서 실행되는 모든 포드가 사용하는 서비스 계정을 식별하십시오. 권한을 검토하고 필요한 경우 서비스 계정을 교체합니다.
잠재적으로 손상된 노드를 종료합니다.

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

잠재적으로 손상되었을 수 있는 독립형 컨테이너의 문제 해결

런타임 모니터링 결과 수정