카테고리 없음

EKS에서 ECR 이미지 사용하기: Secret 기반 인증과 Cross-Account 방식

sedong 2025. 4. 10. 08:59

Amazon EKS를 사용할 때, Private ECR(Elastic Container Registry)에 저장된 이미지를 Pod에서 사용하려면 인증이 필요합니다. 특히 EKS 클러스터가 퍼블릭이 아닌 프라이빗 환경에서 실행되거나, 계정 간의 리소스를 공유하는 구조에서는 이미지 접근 제어가 중요한 요소입니다.

일반적으로 private ecr을 사용해 이미지를 pull 하는 경우에 다음과 같은 두 가지 주요 시나리오가 자주 발생합니다:

  • 단일 AWS 계정 내에서 EKS와 ECR을 함께 사용하는 경우
  • → 이 경우, EKS에서 Private ECR 이미지를 pull 하기 위해 imagePullSecrets를 설정하는 것이 일반적인 접근 방식입니다.
  • 여러 AWS 계정 간에 EKS와 ECR을 분리하여 운영하는 경우
  • → 이 경우, cross-account IAM 권한 위임을 통해 imagePullSecret 없이도 이미지를 pull 하는 접근 방식입니다.

이 글에서는 위 두 가지 방식에 대해 실제 적용 가능한 설정 방법과 특징을 비교하여 정리합니다.

Image Pull Secret을 사용하는 방법

Amazon EKS에서 Private ECR에 저장된 이미지를 Pod에서 사용하려면 인증이 필요합니다.

가장 일반적으로 사용되는 방식은 imagePullSecrets를 활용하여 Kubernetes에 ECR 접근 정보를 명시적으로 제공하는 것입니다.

이 방식은 EKS 클러스터와 ECR이 동일한 AWS 계정 내에 존재할 때 간단하게 사용할 수 있으며, 테스트 환경이나 소규모 서비스에 적합합니다. 복잡한 IAM 권한 설정 없이 빠르게 환경을 구성할 수 있기 때문에 초기 환경 구축 시 많이 활용됩니다.

구성 방법

  • 인증 토큰 생성
  • Kubernetes Secret 생성
  • Pod 또는 Deployment에서 Secret 참조

 

AWS CLI로 Docker 인증 토큰 생성

먼저, AWS CLI를 사용해 Docker 로그인에 사용할 인증 토큰을 생성합니다.

aws ecr get-login-password --region <region> | \\
docker login --username AWS --password-stdin <account_id>.dkr.ecr.<region>.amazonaws.com

이 명령은 로컬 Docker에 ECR 인증 정보를 저장하며, 이후 Secret 생성 시 필요한 인증 값을 추출하는 데 사용됩니다.

 

Kubernetes Secret 생성

다음으로는 ECR 로그인 정보를 Kubernetes Secret으로 만들어 클러스터에 등록합니다.

docker-registry 타입의 Secret을 생성해야 하며, --namespace 플래그를 통해 원하는 네임스페이스에 Secret을 저장할 수 있습니다.

kubectl create secret docker-registry ecr-secret \\
  --docker-server=<account_id>.dkr.ecr.<region>.amazonaws.com \\
  --docker-username=AWS \\
  --docker-password=$(aws ecr get-login-password --region <region>) \\
  --namespace=<namespace>

 

여기서 생성된 ecr-secret은 이후 Pod 또는 Deployment의 imagePullSecrets 필드에서 참조됩니다.

 

Pod Spec에 imagePullSecrets 설정

Secret을 생성한 후, 실제로 이미지를 pull 하려는 리소스에 해당 Secret을 명시해주어야 합니다. 아래는 ECR 이미지를 사용하는 간단한 Pod 예시입니다:

apiVersion: v1
kind: Pod
metadata:
  name: sample-app
spec:
  containers:
  - name: app
    image: <account_id>.dkr.ecr.<region>.amazonaws.com/sample:latest
  imagePullSecrets:
  - name: ecr-secret

 

실제 운영에서는 Pod가 아닌 Deployment 또는 StatefulSet, Job 등 다양한 리소스에 동일하게 적용할 수 있으며, 해당 리소스들의 spec.template.spec.imagePullSecrets 항목에 Secret 이름을 설정해주면 됩니다.

특징

imagePullSecrets 방식을 사용하는 가장 큰 장점은 설정이 매우 간단하고 직관적이라는 점입니다. 복잡한 IAM 정책이나 계정 간 권한 위임 없이, Kubernetes에 인증 정보를 명시적으로 주입하는 방식이기 때문에 처음 EKS를 도입하거나, 테스트 환경을 빠르게 구성하고자 할 때 매우 유용합니다.

 

다만 이 방식은 몇 가지 주의해야 할 점이 있습니다.

가장 먼저 고려할 점은 ECR 인증 토큰의 유효 기간이 12시간으로 제한되어 있다는 것입니다.

 

 

 

인증 토큰이 만료되면 기존 Secret으로 이미지 Pull이 불가능해지므로, 장기 실행 환경에서는 해당 Secret을 주기적으로 갱신하는 자동화 작업이 필요합니다. 일반적으로는 CI/CD 파이프라인이나 스크립트를 통해 자동으로 Secret을 갱신하는 방식을 사용합니다.

Secret은 네임스페이스 스코프 리소스입니다. 다시 말해, 생성된 네임스페이스 내에서만 유효하기 때문에, 리소스가 배포되는 네임스페이스마다 Secret을 별도로 생성하고 관리해야 합니다. 이를 깜빡하면 이미지 Pull 오류가 발생할 수 있으므로 주의가 필요합니다.

 

클러스터의 노드 IAM Role 에는 ECR 접근 권한이 반드시 포함되어야 합니다. 일반적으로 AmazonEC2ContainerRegistryReadOnly 또는 ecr:GetAuthorizationToken 권한이 포함된 IAM 정책이 있어야 Kubernetes가 ECR 인증 토큰을 발급받고, 이미지를 정상적으로 가져올 수 있습니다.

 

이처럼 ImagePullSecrets 방식은 빠르고 명시적인 구성이 가능하다는 점에서 장점이 있지만, 토큰 유효 기간 관리와 네임스페이스 별 Secret 관리 등 운영 측면에서의 고려사항이 존재합니다.

Cross-Account 권한을 활용한 Secret 없이 Pull

보다 효율적이고 자동화된 방식은 IAM Role을 활용하여 EKS 클러스터가 위치한 계정에서, 다른 AWS 계정의 Private ECR 이미지에 접근할 수 있도록 설정하는 것입니다.

이 방식은 별도의 imagePullSecrets 없이도 이미지를 직접 Pull 할 수 있습니다.

특히 다음과 같은 상황에서 유용하게 활용됩니다:

  • EKS 클러스터와 ECR 리포지토리가 서로 다른 AWS 계정에 존재하는 경우
  • 여러 EKS 클러스터가 공통된 ECR 이미지 소스를 공유해야 하는 경우
  • Secret 관리 없이 보다 단순한 배포 자동화를 구성하고자 하는 경우

구성 방법

다음과 같은 상황을 가정합니다:

  • 계정 A (Account A): Private ECR 이미지를 소유하고 있는 AWS 계정
  • 계정 B (Account B): EKS 클러스터가 생성되어 있고, 해당 클러스터에서 계정 A의 ECR 이미지를 Pull 해야 하는 AWS 계정

 

ECR 계정(A)의 Repository Policy 설정

먼저 ECR 이미지가 저장된 계정(A)의 AWS 콘솔에서 다음과 같이 이미지 레포지토리의 권한을 설정할 수 있습니다.

 

 

 

edit을 클릭 후 ECR 레포지토리 정책을 다음과 같이 설정합니다.

{
  "Version": "2008-10-17",
  "Statement": [
    {
      "Sid": "AllowCrossAccountPull",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<account_b_id>:role/<EKS_NodeRole>"
      },
      "Action": [
        "ecr:GetDownloadUrlForLayer",
        "ecr:BatchGetImage",
        "ecr:BatchCheckLayerAvailability"
      ]
    }
  ]
}
  • <account_b_id>: 이미지 Pull 요청을 보내는 계정 B의 AWS 계정 ID
  • <EKS_NodeRole>: 계정 B의 EKS 클러스터에서 사용하는 노드 IAM Role 또는 IRSA Role 이름

 

EKS 노드 Role 또는 IRSA Role에 ECR 접근 권한 추가

다음으로 EKS 클러스터가 ECR에 인증할 수 있도록, 계정 B에서 EKS 클러스터의 노드 Role 또는 IRSA Role에 정책을 추가합니다.

{
  "Effect": "Allow",
  "Action": [
    "ecr:GetAuthorizationToken"
  ],
  "Resource": "*"
}
  • 이 정책은 계정 B가 ECR 인증 토큰을 요청할 수 있도록 허용합니다.
  • Resource는 "*"로 설정합니다. ECR 인증 토큰 요청은 리소스 수준 권한 제어를 지원하지 않기 때문입니다.

 

ImagePullSecrets 없이 사용

이제 Kubernetes 리소스에서는 별도의 imagePullSecrets 없이 Private ECR 이미지를 사용할 수 있습니다.

아래는 Deployment 리소스 예시입니다:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cross-account-sample
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: sample
  template:
    metadata:
      labels:
        app: sample
    spec:
      containers:
      - name: app
        image: <account_a_id>.dkr.ecr.<region>.amazonaws.com/sample:latest
        ports:
        - containerPort: 8080
  • <account_a_id>: Private ECR 이미지를 소유하고 있는 계정 A의 AWS 계정 ID
  • <region>: 해당 ECR이 위치한 리전

위 예시에서는 imagePullSecrets 없이도 ECR 이미지가 정상적으로 Pull 됩니다. 이 방식은 클러스터 내 노드 또는 서비스 계정이 올바른 IAM Role을 가지고 있을 때에만 동작합니다.

특징

기존 방식인 imagePullSecrets를 사용하는 경우, 먼저 ECR 인증 정보를 담은 Secret을 클러스터 내부에 수동으로 생성하고, 각 리소스에 이를 참조하도록 명시해야 했습니다. 단순한 구조이지만 네임스페이스가 많아질수록 Secret을 일관되게 관리하는 일이 번거로워지고, 관리자의 실수로 인한 오류 가능성도 높아집니다.

 

반면, Cross-Account 방식은 IAM Role을 기반으로 인증이 자동 처리되므로, Secret을 생성하거나 참조할 필요 자체가 없습니다. 이로 인해 리소스 정의는 더 간결해지고, 운영 중 인증 정보 갱신과 같은 유지보수 작업도 사라집니다.

즉, Kubernetes와 IAM 사이의 신뢰 기반 인증 구조를 활용하여 인증 과정을 자동화하는 방식입니다.

 

특히 주목할 점은 ECR 인증이 단기 토큰 기반이라는 점입니다. 기존 방식에서는 토큰이 만료되면 수동 또는 자동화된 방식으로 Secret을 재생성해야 했는데, 이 작업이 누락되면 이미지 Pull 실패로 이어져 장애가 발생할 수 있습니다. 반면 Cross-Account 방식은 IAM Role을 통해 필요한 토큰을 매번 자동으로 발급받기 때문에, 토큰 만료에 대해 신경 쓸 필요가 없습니다. 장기 실행 서비스에도 적합하며, 교차 계정간 안정적인 운영이 가능합니다.

 

 

멀티 계정 구조에서의 장점

조직 규모가 커지면 이미지 빌드와 서비스 운영을 별도 계정으로 분리하는 경우가 많습니다. 예를 들어 CI/CD 계정에서 이미지를 빌드하고, ECR에 Push 한 뒤, 운영 계정의 EKS 클러스터에서는 해당 이미지를 Pull 해서 사용하는 방식입니다.

이럴 때 Cross-Account 구조는 ECR을 한 계정에서 중앙 집중식으로 관리하고, 여러 클러스터에서 동일한 이미지를 손쉽게 참조할 수 있게 해줍니다. 결과적으로 다음과 같은 장점이 있습니다:

  • 이미지 관리 체계를 일원화
  • 클러스터 간 이미지 버전이 정합성 있게 유지
  • 운영 비용과 보안 리스크도 효율적으로 관리