이미지 보안 - Amazon EKS
추천도구 및 리소스

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

이미지 보안

컨테이너 이미지를 공격에 대한 첫 번째 방어선으로 보아야 합니다. 이미지가 안전하지 않고 잘못 구성되어 있으면 공격자가 컨테이너의 경계를 벗어나 호스트에 액세스할 수 있습니다. 호스트에서 공격자는 민감한 정보에 액세스하거나 클러스터 내부 또는 AWS 계정으로 내부적으로 이동할 수 있습니다. 다음 모범 사례는 이러한 일이 발생할 위험을 완화하는 데 도움이 됩니다.

추천

최소 이미지 생성

먼저 컨테이너 이미지에서 불필요한 바이너리를 모두 제거합니다. Dockerhub의 익숙하지 않은 이미지를 사용하는 경우 각 컨테이너 계층의 콘텐츠를 표시할 수 있는 Dive와 같은 애플리케이션을 사용하여 이미지를 검사합니다. SETUID 및 SETGID 비트가 있는 바이너리는 권한을 에스컬레이션하는 데 사용할 수 있으므로 모두 제거하고 악의적인 목적으로 사용할 수 있는 nc 및 curl과 같은 모든 셸 및 유틸리티를 제거하는 것이 좋습니다. 다음 명령을 사용하여 SETUID 및 SETGID 비트가 있는 파일을 찾을 수 있습니다.

find / -perm /6000 -type f -exec ls -ld {} \;

이러한 파일에서 특수 권한을 제거하려면 컨테이너 이미지에 다음 명령을 추가합니다.

RUN find / -xdev -perm /6000 -type f -exec chmod a-s {} \; || true

구체적으로 이는 이미지의 플랜징 해제라고 합니다.

다단계 빌드 사용

다단계 빌드를 사용하면 최소한의 이미지를 생성할 수 있습니다. 다단계 빌드를 사용하여 연속 통합 주기의 일부를 자동화하는 경우가 많습니다. 예를 들어 다단계 빌드를 사용하여 소스 코드를 린트하거나 정적 코드 분석을 수행할 수 있습니다. 이를 통해 개발자는 파이프라인이 실행될 때까지 기다리지 않고 거의 즉각적인 피드백을 받을 수 있습니다. 다단계 빌드는 컨테이너 레지스트리로 푸시되는 최종 이미지의 크기를 최소화할 수 있으므로 보안 관점에서 매력적입니다. 빌드 도구 및 기타 불필요한 바이너리가 없는 컨테이너 이미지는 이미지의 공격 표면을 줄여 보안 태세를 향상합니다. 다단계 빌드에 대한 자세한 내용은 Docker의 다단계 빌드 설명서를 참조하세요.

컨테이너 이미지에 대한 소프트웨어 재료표(SBOMs) 생성

"소프트웨어 재료표"(SBOM)는 컨테이너 이미지를 구성하는 소프트웨어 아티팩트의 중첩 인벤토리입니다. SBOM은 소프트웨어 보안 및 소프트웨어 공급망 위험 관리의 핵심 구성 요소입니다. SBOMS를 생성하여 중앙 리포지토리에 저장하고 SBOMs에서 취약성을 검사하면 다음과 같은 문제를 해결하는 데 도움이 됩니다.

  • 가시성: 컨테이너 이미지를 구성하는 구성 요소를 이해합니다. 중앙 리포지토리에 저장하면 배포 후에도 언제든지 SBOMs을 감사하고 스캔하여 제로데이 취약성과 같은 새로운 취약성을 감지하고 대응할 수 있습니다.

  • 증명 확인: 아티팩트의 출처와 방법에 대한 기존 가정이 사실이며 빌드 또는 전송 프로세스 중에 아티팩트 또는 관련 메타데이터가 변조되지 않았는지 확인합니다.

  • 신뢰성: 주어진 아티팩트와 해당 콘텐츠를 신뢰할 수 있도록 하여 의도한 작업을 수행할 수 있도록 보장합니다. 즉,가 목적에 적합합니다. 여기에는 코드가 실행하기에 안전한지 판단하고 코드 실행과 관련된 위험에 대해 정보에 입각한 결정을 내리는 것이 포함됩니다. 증명된 SBOM 및 증명된 CVE 스캔 보고서와 함께 증명된 파이프라인 실행 보고서를 생성하여이 이미지가 안전한 구성 요소를 포함하는 안전한 수단(파이프라인)을 통해 사실적으로 생성되도록 함으로써 신뢰성이 보장됩니다.

  • 종속성 신뢰 확인: 아티팩트의 종속성 트리에서 사용하는 아티팩트의 신뢰성과 출처를 재귀적으로 확인합니다. SBOMs 수 없는 무단 종속성, 침입 시도를 포함한 악의적인 활동을 탐지하는 데 도움이 될 수 있습니다.

다음 도구를 사용하여 SBOM을 생성할 수 있습니다.

  • Amazon Inspector를 사용하여 SBOMs.

  • 앵커의 Syft는 SBOM 생성에도 사용할 수 있습니다. 더 빠른 취약성 스캔을 위해 컨테이너 이미지에 대해 생성된 SBOM을 스캔할 입력으로 사용할 수 있습니다. 그런 다음 검토 및 감사 목적으로 Amazon ECR과 같은 중앙 OCI 리포지토리로 이미지를 푸시하기 전에 SBOM 및 스캔 보고서가 증명되고 이미지에 연결됩니다.

CNCF 소프트웨어 공급망 모범 사례 가이드를 검토하여 소프트웨어 공급망을 보호하는 방법에 대해 자세히 알아봅니다.

이미지에서 취약성을 정기적으로 스캔합니다.

가상 머신과 마찬가지로 컨테이너 이미지에는 취약성이 있는 바이너리 및 애플리케이션 라이브러리가 포함되어 있거나 시간이 지남에 따라 취약성이 발생할 수 있습니다. 악용을 방지하는 가장 좋은 방법은 이미지 스캐너로 이미지를 정기적으로 스캔하는 것입니다. Amazon ECR에 저장된 이미지는 푸시 또는 온디맨드(24시간 동안 한 번)로 스캔할 수 있습니다. ECR은 현재 Basic과 Enhanced라는 두 가지 유형의 스캔을 지원합니다. 기본 스캔은 오픈 소스 이미지 스캔 솔루션인 Clair를 무료로 활용합니다. 고급 스캔은 Amazon Inspector를 사용하여 추가 비용을 지불하고 자동 연속 스캔을 제공합니다. 이미지가 스캔되면 결과는 EventBridge의 ECR에 대한 이벤트 스트림에 로깅됩니다. ECR 콘솔 내에서 스캔 결과를 볼 수도 있습니다. 높음 또는 중요 취약성이 있는 이미지는 삭제하거나 다시 빌드해야 합니다. 배포된 이미지에서 취약성이 발견되면 가능한 한 빨리 교체해야 합니다.

환경을 안전하게 유지하려면 취약성이 있는 이미지가 어디에 배포되었는지 알아야 합니다. 이미지 추적 솔루션을 직접 구축할 수 있지만 다음과 같이이 기능과 기타 고급 기능을 즉시 제공하는 몇 가지 상용 제품이 이미 있습니다.

Kubernetes 검증 웹후크를 사용하여 이미지에 심각한 취약성이 없는지 확인할 수도 있습니다. 검증 웹후크는 Kubernetes API 이전에 호출됩니다. 일반적으로 웹후크에 정의된 검증 기준을 준수하지 않는 요청을 거부하는 데 사용됩니다. 다음은 ECR describeImageScanFindings API를 호출하여 포드가 중요한 취약성이 있는 이미지를 가져오는지 여부를 확인하는 서버리스 웹후크의 예입니다. 취약성이 발견되면 포드가 거부되고 CVEs 목록이 포함된 메시지가 이벤트로 반환됩니다.

증명을 사용하여 아티팩트 무결성 검증

증명은 암호화 방식으로 서명된 "문"으로, 파이프라인 실행 또는 SBOM과 같은 "예측" 또는 취약성 스캔 보고서가 다른 사물인 "주제", 즉 컨테이너 이미지에 대해 참인 것을 주장합니다.

증명은 사용자가 아티팩트가 소프트웨어 공급망의 신뢰할 수 있는 소스에서 비롯되었는지 검증하는 데 도움이 됩니다. 예를 들어, 해당 이미지에 포함된 모든 소프트웨어 구성 요소 또는 종속성을 모르는 상태에서 컨테이너 이미지를 사용할 수 있습니다. 그러나 컨테이너 이미지의 생산자가 존재하는 소프트웨어에 대해 말하는 것을 신뢰하는 경우 생산자의 증명을 사용하여 해당 아티팩트에 의존할 수 있습니다. 즉, 분석을 수행하는 대신 워크플로에서 아티팩트를 안전하게 사용할 수 있습니다.

  • AWS Signer 또는 Sigstore 공동 서명을 사용하여 증명을 생성할 수 있습니다.

  • Kyverno와 같은 Kubernetes 승인 컨트롤러를 사용하여 증명을 확인할 수 있습니다.

  • 컨테이너 이미지에 증명 생성 및 연결 등의 주제와 함께 오픈 소스 도구를 사용하는 AWS의 소프트웨어 공급망 관리 모범 사례에 대해 자세히 알아보려면이 워크숍을 참조하세요.

ECR 리포지토리에 대한 IAM 정책 생성

오늘날 조직에서 공유 AWS 계정 내에서 여러 개발 팀을 독립적으로 운영하는 것은 드문 일이 아닙니다. 이러한 팀이 자산을 공유할 필요가 없는 경우 각 팀이 상호 작용할 수 있는 리포지토리에 대한 액세스를 제한하는 일련의 IAM 정책을 생성할 수 있습니다. 이를 구현하는 좋은 방법은 ECR 네임스페이스를 사용하는 것입니다. 네임스페이스는 유사한 리포지토리를 그룹화하는 방법입니다. 예를 들어 팀 A의 모든 레지스트리에는 team-a/를 접두사로 붙일 수 있고, 팀 B의 레지스트리에는 team-b/ 접두사를 사용할 수 있습니다. 액세스를 제한하는 정책은 다음과 같을 수 있습니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowPushPull",
      "Effect": "Allow",
      "Action": [
        "ecr:GetDownloadUrlForLayer",
        "ecr:BatchGetImage",
        "ecr:BatchCheckLayerAvailability",
        "ecr:PutImage",
        "ecr:InitiateLayerUpload",
        "ecr:UploadLayerPart",
        "ecr:CompleteLayerUpload"
      ],
      "Resource": [
        "arn:aws:ecr:<region>:<account_id>:repository/team-a/*"
      ]
    }
  ]
}

ECR 프라이빗 엔드포인트 사용 고려

ECR API에는 퍼블릭 엔드포인트가 있습니다. 따라서 IAM에서 요청을 인증하고 승인하는 한 인터넷에서 ECR 레지스트리에 액세스할 수 있습니다. 클러스터 VPC에 인터넷 게이트웨이(IGW)가 없는 샌드박스 환경에서 운영해야 하는 사용자의 경우 ECR에 대한 프라이빗 엔드포인트를 구성할 수 있습니다. 프라이빗 엔드포인트를 생성하면 인터넷을 통해 트래픽을 라우팅하는 대신 프라이빗 IP 주소를 통해 ECR API에 비공개로 액세스할 수 있습니다. 이 주제에 대한 자세한 내용은 Amazon ECR 인터페이스 VPC 엔드포인트를 참조하세요.

ECR에 대한 엔드포인트 정책 구현

의 기본 엔드포인트 정책은 리전 내의 모든 ECR 리포지토리에 대한 액세스를 허용합니다. 이렇게 하면 공격자/내부자가 데이터를 컨테이너 이미지로 패키징하고 다른 AWS 계정의 레지스트리로 푸시하여 데이터를 유출할 수 있습니다. 이 위험을 완화하려면 ECR 리포지토리에 대한 API 액세스를 제한하는 엔드포인트 정책을 생성해야 합니다. 예를 들어 다음 정책은 계정의 모든 AWS 원칙이에 대해 모든 작업을 수행하고 ECR 리포지토리만 수행하도록 허용합니다.

{
  "Statement": [
    {
      "Sid": "LimitECRAccess",
      "Principal": "*",
      "Action": "*",
      "Effect": "Allow",
      "Resource": "arn:aws:ecr:<region>:<account_id>:repository/*"
    }
  ]
}

AWS Organization의 일부가 아닌 IAM 원칙에 따라 이미지 푸시/풀링을 방지하는 새 PrincipalOrgID 속성을 사용하는 조건을 설정하여 이를 더욱 개선할 수 있습니다. 자세한 내용은 aws:PrincipalOrgID를 참조하세요. com.amazonaws.<region>.ecr.dkr 및 com.amazonaws.<region>.ecr.api 엔드포인트 모두에 동일한 정책을 적용하는 것이 좋습니다. EKS는 ECR에서 kube-proxy, coredns 및 aws-node에 대한 이미지를 가져오므로 엔드포인트 정책의 리소스 목록에 레지스트리602401143452.dkr.ecr.us-west-2.amazonaws.com/ 의 계정 ID를 추가하거나 정책을 변경하여에서 가져오기를 허용하고 계정 ID에 대한 푸시를 제한해야 합니다. 아래 표에는 EKS 이미지가 벤딩되는 AWS 계정과 클러스터 리전 간의 매핑이 나와 있습니다.

계정 번호 리전

602401143452

아래 나열된 리전을 제외한 모든 상용 리전

—

—

800184023465

ap-east-1 - 아시아 태평양(홍콩)

558608220178

me-south-1 - 중동(바레인)

918309763551

cn-north-1 - 중국(베이징)

961992271922

cn-northwest-1 - 중국(닝샤)

엔드포인트 정책 사용에 대한 자세한 내용은 VPC 엔드포인트 정책을 사용하여 Amazon ECR 액세스 제어를 참조하세요.

ECR에 대한 수명 주기 정책 구현

NIST 애플리케이션 컨테이너 보안 가이드는 "레지스터리의 오래된 이미지"의 위험에 대해 경고하며, 시간이 지남에 따라 소프트웨어 패키지가 취약하고 out-of-date 이미지를 제거하여 우발적인 배포 및 노출을 방지해야 합니다. 각 ECR 리포지토리에는 이미지가 만료되는 시점에 대한 규칙을 설정하는 수명 주기 정책이 있을 수 있습니다. AWS 공식 설명서에서는 테스트 규칙을 설정하고 평가하여 적용하는 방법을 설명합니다. 공식 문서에는 리포지토리의 이미지를 필터링하는 다양한 방법을 보여주는 몇 가지 수명 주기 정책 예제가 있습니다.

  • 이미지 연령 또는 개수를 기준으로 필터링

  • 태그가 지정되거나 지정되지 않은 이미지를 기준으로 필터링

  • 여러 규칙 또는 단일 규칙에서 이미지 태그를 기준으로 필터링

???+ 경고 장기 실행 애플리케이션의 이미지가 ECR에서 제거되면 애플리케이션을 수평으로 재배포하거나 확장할 때 이미지 가져오기 오류가 발생할 수 있습니다. 이미지 수명 주기 정책을 사용할 때는 배포 및 배포에서 참조하는 이미지를 최신 상태로 유지하고 릴리스/배포 빈도를 설명하는 [이미지] 만료 규칙을 항상 생성하는 데 적합한 CI/CD 사례가 있는지 확인합니다.

큐레이팅한 이미지 세트 생성

개발자가 자체 이미지를 생성하도록 허용하는 대신 조직의 다양한 애플리케이션 스택에 대해 심사된 이미지 세트를 생성하는 것이 좋습니다. 이렇게 하면 개발자는 Dockerfile 작성 방법을 배울 필요 없이 코드 작성에 집중할 수 있습니다. 변경 사항이 마스터로 병합되면 CI/CD 파이프라인은 자산을 자동으로 컴파일하고 아티팩트 리포지토리에 저장한 다음 ECR과 같은 Docker 레지스트리로 푸시하기 전에 아티팩트를 적절한 이미지에 복사할 수 있습니다. 최소한 개발자가 자체 Dockerfiles를 생성할 기본 이미지 세트를 생성해야 합니다. 이상적으로는 Dockerhub에서 이미지를 가져오지 않는 것이 좋습니다. 이미지에 무엇이 있는지 항상 알지는 못하며 상위 1000개 이미지 https://www.kennasecurity.com/blog/one-fifth-of-the-most-used-docker-containers-have-at-least-one-critical-vulnerability/ 중 2/5에 취약성이 있기 때문입니다. 이러한 이미지 및 취약성 목록은 여기에서 확인할 수 있습니다.

루트가 아닌 사용자로 실행되도록 Dockerfiles에 사용자 지시문 추가

포드 보안 섹션에서 언급했듯이 컨테이너를 루트로 실행하지 않아야 합니다. 이를 podSpec의 일부로 구성할 수 있지만 Dockerfiles에 대한 USER 명령을 사용하는 것이 좋습니다. USER 명령은 사용자 명령 뒤에 나타나는 RUN, ENTRYPOINT또는 CMD 명령을 실행할 때 사용할 UID를 설정합니다.

Dockerfiles 린트

린팅을 사용하여 Dockerfile이 USER 명령 포함 또는 모든 이미지에 태그를 지정해야 하는 요구 사항과 같은 사전 정의된 지침 세트를 준수하는지 확인할 수 있습니다. dockerfile_lint는 RedHat의 오픈 소스 프로젝트로, 일반적인 모범 사례를 확인하고 Dockerfile 린팅을 위한 자체 규칙을 구축하는 데 사용할 수 있는 규칙 엔진을 포함합니다. 규칙을 위반하는 Dockerfile이 포함된 빌드는 자동으로 실패한다는 점에서 CI 파이프라인에 통합할 수 있습니다.

스크래치에서 이미지 빌드

이미지를 빌드할 때 컨테이너 이미지의 공격 표면을 줄이는 것이 기본 목표여야 합니다. 이를 위한 이상적인 방법은 취약성을 악용하는 데 사용할 수 있는 바이너리가 없는 최소한의 이미지를 생성하는 것입니다. 다행히 Docker에는에서 이미지를 생성하는 메커니즘이 있습니다scratch. Go와 같은 언어를 사용하면 정적 연결 바이너리를 생성하고이 예제와 같이 Dockerfile에서 참조할 수 있습니다.

############################
# STEP 1 build executable binary
############################
FROM golang:alpine AS builder# Install git.
# Git is required for fetching the dependencies.
RUN apk update && apk add --no-cache gitWORKDIR $GOPATH/src/mypackage/myapp/COPY . . # Fetch dependencies.
# Using go get.
RUN go get -d -v# Build the binary.
RUN go build -o /go/bin/hello

############################
# STEP 2 build a small image
############################
FROM scratch# Copy our static executable.
COPY --from=builder /go/bin/hello /go/bin/hello# Run the hello binary.
ENTRYPOINT ["/go/bin/hello"]

이렇게 하면 애플리케이션만으로 구성된 컨테이너 이미지가 생성되므로 매우 안전합니다.

ECR에서 변경 불가능한 태그 사용

변경 불가능한 태그는 이미지 리포지토리로 푸시할 때마다 이미지 태그를 업데이트하도록 강제합니다. 이렇게 하면 공격자가 이미지의 태그를 변경하지 않고도 악성 버전으로 이미지를 덮어쓰지 못하게 할 수 있습니다. 또한 이미지를 쉽고 고유하게 식별할 수 있는 방법을 제공합니다.

이미지, SBOMs, 파이프라인 실행 및 취약성 보고서에 서명

Docker가 처음 도입되었을 때 컨테이너 이미지를 확인하기 위한 암호화 모델은 없었습니다. v2에서는 Docker가 이미지 매니페스트에 다이제스트를 추가했습니다. 이렇게 하면 이미지의 구성이 해시되고 해시를 사용하여 이미지의 ID를 생성할 수 있습니다. 이미지 서명이 활성화되면 Docker 엔진은 매니페스트의 서명을 확인하여 콘텐츠가 신뢰할 수 있는 소스에서 생성되었고 변조가 발생하지 않았는지 확인합니다. 각 계층을 다운로드한 후 엔진은 계층의 다이제스트를 확인하여 콘텐츠가 매니페스트에 지정된 콘텐츠와 일치하는지 확인합니다. 이미지 서명은 이미지와 연결된 디지털 서명을 확인하여 보안 공급망을 효과적으로 생성할 수 있습니다.

AWS Signer 또는 Sigstore Cosign을 사용하여 컨테이너 이미지에 서명하고, SBOMs, 취약성 스캔 보고서 및 파이프라인 실행 보고서에 대한 증명을 생성할 수 있습니다. 이러한 증명은 이미지의 신뢰성과 무결성을 보장하고, 실제로는 간섭이나 변조 없이 신뢰할 수 있는 파이프라인에서 생성되며, 이미지 게시자가 검증하고 신뢰할 수 있는 (SBOM에서) 문서화된 소프트웨어 구성 요소만 포함한다는 것을 보장합니다. 이러한 증명은 컨테이너 이미지에 연결하고 리포지토리로 푸시할 수 있습니다.

다음 섹션에서는 감사 및 승인 컨트롤러 확인에 대해 증명된 아티팩트를 사용하는 방법을 알아봅니다.

Kubernetes 승인 컨트롤러를 사용한 이미지 무결성 확인

동적 승인 컨트롤러를 사용하여 대상 Kubernetes 클러스터에 이미지를 배포하기 전에 자동화된 방식으로 이미지 서명, 증명된 아티팩트를 확인하고 아티팩트의 보안 메타데이터가 승인 컨트롤러 정책을 준수하는 경우에만 배포를 허용할 수 있습니다.

예를 들어 이미지의 서명, 증명된 SBOM, 증명된 파이프라인 실행 보고서 또는 증명된 CVE 스캔 보고서를 암호화 방식으로 확인하는 정책을 작성할 수 있습니다. 정책의 조건을 작성하여 보고서의 데이터를 확인할 수 있습니다. 예를 들어 CVE 스캔에는 중요한 CVEs 없어야 합니다. 배포는 이러한 조건을 충족하는 이미지에만 허용되며 다른 모든 배포는 승인 컨트롤러에 의해 거부됩니다.

승인 컨트롤러의 예는 다음과 같습니다.

컨테이너 이미지의 패키지 업데이트

이미지apt-get update && apt-get upgrade의 패키지를 업그레이드하려면 Dockerfiles에 RUN을 포함해야 합니다. 업그레이드하려면 루트로를 실행해야 하지만 이는 이미지 빌드 단계에서 발생합니다. 애플리케이션은 루트로 실행할 필요가 없습니다. 업데이트를 설치한 다음 사용자 지시문을 사용하여 다른 사용자로 전환할 수 있습니다. 기본 이미지가 루트가 아닌 사용자로 실행되는 경우 루트 및 백으로 전환합니다. 최신 보안 업데이트를 설치하기 위해 기본 이미지의 유지 관리에만 의존하지 마세요.

를 실행apt-get clean하여에서 설치 관리자 파일을 삭제합니다/var/cache/apt/archives/. 패키지를 설치rm -rf /var/lib/apt/lists/*한 후를 실행할 수도 있습니다. 그러면 인덱스 파일 또는 설치할 수 있는 패키지 목록이 제거됩니다. 이러한 명령은 패키지 관리자마다 다를 수 있습니다. 예:

RUN apt-get update && apt-get install -y \
    curl \
    git \
    libsqlite3-dev \
    && apt-get clean && rm -rf /var/lib/apt/lists/*

도구 및 리소스