인프라(호스트) 보호 - Amazon EKS
추천대안도구 및 리소스

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

인프라(호스트) 보호

컨테이너 이미지를 보호하는 것이 중요하므로 컨테이너 이미지를 실행하는 인프라를 보호하는 것도 중요합니다. 이 섹션에서는 호스트에 대해 직접 시작된 공격으로 인한 위험을 완화하는 다양한 방법을 살펴봅니다. 이러한 지침은 런타임 보안 섹션에 설명된 것과 함께 사용해야 합니다.

추천

컨테이너 실행에 최적화된 OS 사용

Linux 컨테이너를 실행하도록 설계된 AWS의 특수 용도 OS인 Flatcar Linux, Project Atomic, RancherOS 및 Bottlerocket을 사용하는 것이 좋습니다. 여기에는 감소된 공격 표면, 부팅 시 확인된 디스크 이미지, SELinux를 사용하여 시행된 권한 경계가 포함됩니다.

또는 Kubernetes 작업자 노드에 EKS 최적화 AMI를 사용합니다. EKS 최적화 AMI는 정기적으로 릴리스되며 컨테이너화된 워크로드를 실행하는 데 필요한 최소한의 OS 패키지 및 바이너리 세트를 포함합니다.

Hashicorp Packer를 사용하여 Red Hat Enterprise Linux에서 실행되는 사용자 지정 Amazon EKS AMI를 빌드하는 데 사용할 수 있는 샘플 구성 스크립트는 Amazon EKS AMI RHEL 빌드 사양을 참조하세요. 이 스크립트를 추가로 활용하여 STIG 준수 EKS 사용자 지정 AMIs.

작업자 노드 OS 업데이트 유지

Bottlerocket과 같은 컨테이너 최적화 호스트 OS를 사용하든 더 크지만 여전히 미니멀리스트인 EKS 최적화 AMIs와 같은 Amazon Machine Image를 사용하든 관계없이 이러한 호스트 OS 이미지를 최신 보안 패치로 최신 상태로 유지하는 것이 좋습니다.

EKS 최적화 AMIs의 경우 변경 로그 및/또는 릴리스 정보 채널을 정기적으로 확인하고 업데이트된 작업자 노드 이미지를 클러스터에 자동으로 롤아웃합니다.

인프라를 변경할 수 없는 것으로 취급하고 작업자 노드 교체 자동화

새 패치 또는 업데이트를 사용할 수 있게 되면 현재 위치 업그레이드를 수행하는 대신 작업자를 교체합니다. 이는 몇 가지 방법으로 접근될 수 있습니다. 그룹의 모든 노드가 최신 AMI로 교체될 때까지 노드를 순차적으로 연결 및 드레이닝할 때 최신 AMI를 사용하여 기존 오토 스케일링 그룹에 인스턴스를 추가할 수 있습니다. 또는 모든 노드가 교체될 때까지 이전 노드 그룹에서 노드를 순차적으로 연결하고 드레이닝하는 동안 새 노드 그룹에 인스턴스를 추가할 수 있습니다. EKS 관리형 노드 그룹은 첫 번째 접근 방식을 사용하며 새 AMI를 사용할 수 있게 되면 콘솔에 메시지를 표시하여 작업자를 업그레이드합니다. eksctl 또한 에는 최신 AMI를 사용하여 노드 그룹을 생성하고 인스턴스가 종료되기 전에 노드 그룹에서 포드를 정상적으로 코딩하고 드레이닝하는 메커니즘이 있습니다. 작업자 노드를 교체하기 위해 다른 방법을 사용하기로 결정한 경우 새 업데이트/패치가 릴리스되고 컨트롤 플레인이 업그레이드될 때 작업자를 정기적으로 교체해야 하므로 인적 감독을 최소화하도록 프로세스를 자동화하는 것이 좋습니다.

EKS Fargate를 사용하면 업데이트가 제공되면 AWS가 기본 인프라를 자동으로 업데이트합니다. 이 작업을 원활하게 수행할 수 있지만 업데이트로 인해 포드가 다시 예약되는 경우가 있을 수 있습니다. 따라서 애플리케이션을 Fargate 포드로 실행할 때 여러 복제본을 사용하여 배포를 생성하는 것이 좋습니다.

kube-bench를 정기적으로 실행하여 Kubernetes에 대한 CIS 벤치마크 준수 확인

kube-bench는 Kubernetes에 대한 CIS 벤치마크를 기준으로 클러스터를 평가하는 Aqua의 오픈 소스 프로젝트입니다. 벤치마크는 비관리형 Kubernetes 클러스터를 보호하기 위한 모범 사례를 설명합니다. CIS Kubernetes 벤치마크는 컨트롤 플레인과 데이터 플레인을 포함합니다. Amazon EKS는 완전 관리형 컨트롤 플레인을 제공하므로 CIS Kubernetes 벤치마크의 모든 권장 사항이 적용되는 것은 아닙니다. 이 범위가 Amazon EKS가 구현되는 방식을 반영하도록 AWS는 CIS Amazon EKS 벤치마크를 생성했습니다. EKS 벤치마크는 EKS 클러스터에 대한 특정 구성 고려 사항과 함께 커뮤니티의 추가 입력과 함께 CIS Kubernetes 벤치마크에서 상속됩니다.

EKS 클러스터에 대해 kube-bench를 실행하는 경우 Aqua Security의 다음 지침을 따르세요. 자세한 내용은 CIS Amazon EKS 벤치마크 소개를 참조하세요.

작업자 노드에 대한 액세스 최소화

호스트로 원격해야 하는 경우 SSH 액세스를 활성화하는 대신 SSM 세션 관리자를 사용합니다. 손실, 복사 또는 공유할 수 있는 SSH 키와 달리 Session Manager를 사용하면 IAM을 사용하여 EC2 인스턴스에 대한 액세스를 제어할 수 있습니다. 또한 인스턴스에서 실행된 명령의 감사 추적 및 로그를 제공합니다.

2020년 8월 19일부터 관리형 노드 그룹은 사용자 지정 AMIs 및 EC2 시작 템플릿을 지원합니다. 이렇게 하면 SSM 에이전트를 AMI에 임베드하거나 작업자 노드가 부트스트래핑될 때 설치할 수 있습니다. 최적화된 AMI 또는 ASG의 시작 템플릿을 수정하지 않으려면 이 예제와 같이 DaemonSet를 사용하여 SSM 에이전트를 설치할 수 있습니다.

SSM 기반 SSH 액세스를 위한 최소 IAM 정책

AmazonSSMManagedInstanceCore AWS 관리형 정책에는 SSH 액세스를 피하려는 경우 SSM 세션 관리자/SSM RunCommand에 필요하지 않은 여러 권한이 포함되어 있습니다. 특히 중요한 것은가 Parameter Store의 모든 파라미터(AWS 관리형 KMS 키가 구성된 SecureStrings 포함)에 액세스할 ssm:GetParameter(s) 수 있도록 허용하는 * 권한입니다.

다음 IAM 정책에는 SSM Systems Manager를 통해 노드 액세스를 활성화할 수 있는 최소한의 권한 집합이 포함되어 있습니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnableAccessViaSSMSessionManager",
      "Effect": "Allow",
      "Action": [
        "ssmmessages:OpenDataChannel",
        "ssmmessages:OpenControlChannel",
        "ssmmessages:CreateDataChannel",
        "ssmmessages:CreateControlChannel",
        "ssm:UpdateInstanceInformation"
      ],
      "Resource": "*"
    },
    {
      "Sid": "EnableSSMRunCommand",
      "Effect": "Allow",
      "Action": [
        "ssm:UpdateInstanceInformation",
        "ec2messages:SendReply",
        "ec2messages:GetMessages",
        "ec2messages:GetEndpoint",
        "ec2messages:FailMessage",
        "ec2messages:DeleteMessage",
        "ec2messages:AcknowledgeMessage"
      ],
      "Resource": "*"
    }
  ]
}

이 정책이 적용되고 Session Manager 플러그인이 설치된 상태에서를 실행할 수 있습니다.

aws ssm start-session --target [INSTANCE_ID_OF_EKS_NODE]

노드에 액세스합니다.

참고

Session Manager 로깅을 활성화하는 권한 추가를 고려할 수도 있습니다.

프라이빗 서브넷에 작업자 배포

프라이빗 서브넷에 작업자를 배포하면 공격이 자주 발생하는 인터넷에 대한 노출을 최소화할 수 있습니다. 2020년 4월 22일부터 관리형 노드 그룹의 노드에 대한 퍼블릭 IP 주소 할당은 배포된 서브넷에 의해 제어됩니다. 이전에는 관리형 노드 그룹의 노드에 퍼블릭 IP가 자동으로 할당되었습니다. 작업자 노드를 퍼블릭 서브넷에 배포하도록 선택한 경우 제한적인 AWS 보안 그룹 규칙을 구현하여 노출을 제한합니다.

Amazon Inspector를 실행하여 호스트의 노출, 취약성 및 모범 사례와의 편차를 평가합니다.

Amazon Inspector를 사용하여 노드에 대한 의도하지 않은 네트워크 액세스와 기본 Amazon EC2 인스턴스의 취약성을 확인할 수 있습니다.

Amazon Inspector는 Amazon EC2 Systems Manager(SSM) 에이전트가 설치되고 활성화된 경우에만 Amazon EC2 인스턴스에 대한 일반적인 취약성 및 노출(CVE) 데이터를 제공할 수 있습니다. 이 에이전트는 EKS 최적화 Amazon Linux AMIs 포함한 여러 Amazon Machine Image(AMI)에 사전 설치되어 있습니다. AMIs SSM 에이전트 상태에 관계없이 모든 Amazon EC2 인스턴스에서 네트워크 연결성 문제를 스캔합니다. Amazon EC2에 대한 스캔 구성에 대한 자세한 내용은 Amazon EC2 인스턴스 스캔을 참조하세요.

중요

Fargate 포드를 실행하는 데 사용되는 인프라에서는 Inspector를 실행할 수 없습니다.

대안

SELinux 실행

참고

Red Hat Enterprise Linux(RHEL), CentOS, Bottlerocket 및 Amazon Linux 2023에서 사용 가능

SELinux는 컨테이너를 서로 격리하고 호스트에서 격리할 수 있는 추가 보안 계층을 제공합니다. SELinux를 사용하면 관리자가 모든 사용자, 애플리케이션, 프로세스 및 파일에 대해 필수 액세스 제어(MAC)를 적용할 수 있습니다. 레이블 집합을 기반으로 특정 리소스에 대해 수행할 수 있는 작업을 제한하는 백스톱이라고 가정합니다. EKS에서 SELinux를 사용하여 컨테이너가 서로의 리소스에 액세스하지 못하도록 할 수 있습니다.

컨테이너 SELinux 정책은 container-selinux 패키지에 정의되어 있습니다. Docker CE는 Docker(또는 기타 컨테이너 런타임)에서 생성한 프로세스와 파일이 제한된 시스템 액세스로 실행되도록이 패키지(종속성과 함께)가 필요합니다. 컨테이너는의 별칭인 container_t 레이블을 활용합니다svirt_lxc_net_t. 이러한 정책은 컨테이너가 호스트의 특정 기능에 액세스하는 것을 효과적으로 방지합니다.

Docker용 SELinux를 구성하면 Docker는 자동으로 워크로드에 유형container_t으로 레이블을 지정하고 각 컨테이너에 고유한 MCS 수준을 부여합니다. 이렇게 하면 컨테이너가 서로 격리됩니다. 더 느슨한 제한이 필요한 경우 파일 시스템의 특정 영역에 컨테이너 권한을 부여하는 자체 프로필을 SElinux에서 생성할 수 있습니다. 이는 컨테이너/포드마다 다른 프로필을 생성할 수 있다는 점에서의 PSPs와 유사합니다. 예를 들어 제한 제어 세트가 있는 일반 워크로드에 대한 프로파일과 권한이 있는 액세스가 필요한 사물에 대한 프로파일을 가질 수 있습니다.

SELinux for Containers에는 기본 제한을 수정하도록 구성할 수 있는 옵션 세트가 있습니다. 필요에 따라 다음 SELinux 부울을 활성화하거나 비활성화할 수 있습니다.

불 Default 설명

container_connect_any

off

컨테이너가 호스트의 권한 있는 포트에 액세스하도록 허용합니다. 예를 들어, 호스트의 443 또는 80에 포트를 매핑해야 하는 컨테이너가 있는 경우

container_manage_cgroup

off

컨테이너가 cgroup 구성을 관리하도록 허용합니다. 예를 들어 systemd를 실행하는 컨테이너는 이를 활성화해야 합니다.

container_use_cephfs

off

컨테이너가 ceph 파일 시스템을 사용하도록 허용합니다.

기본적으로 컨테이너는에서 읽고 실행할 수 /usr 있으며에서 대부분의 콘텐츠를 읽을 수 있습니다/etc. /var/lib/docker 및 아래의 파일에는 레이블/var/lib/containers이 있습니다container_var_lib_t. 기본값의 전체 목록을 보려면 레이블은 container.fc 파일을 참조하세요.

docker container run -it \
  -v /var/lib/docker/image/overlay2/repositories.json:/host/repositories.json \
  centos:7 cat /host/repositories.json
# cat: /host/repositories.json: Permission denied

docker container run -it \
  -v /etc/passwd:/host/etc/passwd \
  centos:7 cat /host/etc/passwd
# cat: /host/etc/passwd: Permission denied

로 레이블이 지정된 파일은 컨테이너에서 쓸 수 있는 유일한 파일container_file_t입니다. 볼륨 마운트를 쓸 수 있도록 하려면 끝에 :z 또는 :Z를 지정해야 합니다.

  • :z는 컨테이너가 읽고 쓸 수 있도록 파일에 레이블을 다시 지정합니다.

  • :Z는 컨테이너만 읽고 쓸 수 있도록 파일에 레이블을 다시 지정합니다.

ls -Z /var/lib/misc
# -rw-r--r--. root root system_u:object_r:var_lib_t:s0   postfix.aliasesdb-stamp

docker container run -it \
  -v /var/lib/misc:/host/var/lib/misc:z \
  centos:7 echo "Relabeled!"

ls -Z /var/lib/misc
#-rw-r--r--. root root system_u:object_r:container_file_t:s0 postfix.aliasesdb-stamp
docker container run -it \
  -v /var/log:/host/var/log:Z \
  fluentbit:latest

Kubernetes에서는 레이블 재지정이 약간 다릅니다. Docker가 자동으로 파일에 레이블을 다시 지정하는 대신 포드를 실행할 사용자 지정 MCS 레이블을 지정할 수 있습니다. 재라벨링을 지원하는 볼륨은 자동으로 재라벨링되어 액세스할 수 있습니다. MCS 레이블이 일치하는 포드는 볼륨에 액세스할 수 있습니다. 엄격한 격리가 필요한 경우 각 포드에 대해 다른 MCS 레이블을 설정합니다.

securityContext:
  seLinuxOptions:
    # Provide a unique MCS label per container
    # You can specify user, role, and type also
    # enforcement based on type and level (svert)
    level: s0:c144:c154

이 예제에서는 컨테이너가 액세스할 수 있는 파일에 할당된 MCS 레이블에 s0:c144:c154 해당합니다.

EKS에서는 FluentD와 같이 권한이 있는 컨테이너를 실행할 수 있도록 허용하는 정책을 생성하고 호스트 디렉터리에 레이블을 다시 지정할 필요 없이 호스트의 /var/log에서 읽을 수 있도록 SELinux 정책을 생성할 수 있습니다. 레이블이 동일한 포드는 동일한 호스트 볼륨에 액세스할 수 있습니다.

CentOS 7 및 RHEL 7에 SELinux가 구성된 Amazon EKS용 샘플 AMIs를 구현했습니다. 이러한 AMIs 규제가 엄격한 고객의 요구 사항을 충족하는 샘플 구현을 보여주기 위해 개발되었습니다.

주의

SELinux는 유형이 제한되지 않은 컨테이너를 무시합니다.

도구 및 리소스