EKS에서 AWS 리소스 접근 권한 설정하기: IRSA 상세 가이드

들어가며

Amazon EKS(Elastic Kubernetes Service)에서 실행되는 애플리케이션이 S3, DynamoDB 등 AWS 리소스에 접근해야 하는 경우가 많습니다. 이때 보안적으로 안전하면서도 효과적인 권한 설정 방법을 선택하는 것이 중요합니다. 이 글에서는 가장 권장되는 방식인 IRSA(IAM Roles for Service Accounts)를 활용한 상세 설정 방법을 알아보겠습니다.

AWS 리소스 접근 권한 설정 방식 비교

EKS에서 Pod가 AWS 리소스에 접근하기 위한 방법은 크게 3가지가 있습니다:

1. Node(EC2) IAM Role 부여 방식

장점: 설정이 간단함
단점:
- 노드의 모든 Pod가 동일한 권한을 가짐
- 노드가 해킹당할 경우 모든 AWS 리소스가 노출될 위험
- 최소 권한 원칙 위배

2. 코드 단에서의 Access Key 사용 방식

장점: 구현이 단순함
단점:
- Access Key 유출 위험이 높음
- Key rotation 관리가 어려움
- 보안 감사가 어려움

3. IRSA(IAM Roles for Service Accounts) 방식

장점:
- Pod 단위로 세밀한 권한 제어 가능
- Access Key 없이 임시 크레덴셜 사용
- AWS IAM과 Kubernetes RBAC의 통합
- 보안 감사가 용이함
단점:
- 초기 설정이 다소 복잡함

따라서 IRSA 방식를 사용하는 것을 권고하고 있으며, 가장 권장되는 방식인 IRSA 활용하여, 특정 파드가 AWS DynamoDB 리소스에만 접근 가능하도록 권한을 부여하는 시나리오로 상세 설정 방법을 알아보겠습니다.

IRSA 설정 상세 가이드

시나리오 : 특정 파드가 AWS DynamoDB 리소스에만 접근 가능하도록 권한을 부여

1. 사전 준비: OIDC Provider 확인

먼저 EKS 클러스터에 OIDC(OpenID Connect) Provider가 설정되어 있는지 확인해야 합니다.

AWS Console에서 확인하는 방법:
1. EKS 클러스터 상세 페이지 접속
2. "구성" 탭에서 "OpenID Connect 공급자 URL" 확인

OIDC Provider 설정 확인
CLI로 확인하는 방법:

aws eks describe-cluster --name your-cluster-name --query "cluster.identity.oidc.issuer" --output text

2. IAM Role 생성

보안 자격 증명 페이지에 들어가, IAM Role을 생성합니다. 신뢰 정책과 권한 설정 이후, Role을 생성합니다.

2.1 신뢰 정책(Trust Policy) 설정

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::<AWS_ACCOUNT_ID>:oidc-provider/<OIDC_PROVIDER>"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "<OIDC_PROVIDER>:sub": "system:serviceaccount:<NAMESPACE>:<SERVICE_ACCOUNT_NAME>",
                    "<OIDC_PROVIDER>:aud": "sts.amazonaws.com"
                }
            }
        }
    ]
}

여기서 각 플레이스홀더는 다음과 같이 교체해야 합니다:

<AWS_ACCOUNT_ID>: AWS 계정 ID
<OIDC_PROVIDER>: EKS 클러스터의 OIDC Provider URL (https:// 제외)
<NAMESPACE>: Kubernetes ServiceAccount가 위치할 네임스페이스
<SERVICE_ACCOUNT_NAME>: 생성할 ServiceAccount 이름

2.2 권한 정책(Permission Policy) 설정

DynamoDB 접근을 위한 예시 정책:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "dynamodb:GetItem",
                "dynamodb:PutItem",
                "dynamodb:UpdateItem",
                "dynamodb:DeleteItem",
                "dynamodb:Query",
                "dynamodb:Scan"
            ],
            "Resource": "arn:aws:dynamodb:<REGION>:<AWS_ACCOUNT_ID>:table/<TABLE_NAME>"
        }
    ]
}

3. Kubernetes ServiceAccount 생성

apiVersion: v1
kind: ServiceAccount
metadata:
  name: dynamodb-sa
  namespace: your-namespace
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::<AWS_ACCOUNT_ID>:role/<ROLE_NAME>

arn:aws:iam::<AWS_ACCOUNT_ID>:role/<ROLE_NAME>을 이전에 만든 Role의 arn으로 변경합니다.

이후 ServiceAccount를 적용합니다:

kubectl apply -f service-account.yaml

4. Pod에 ServiceAccount 연결

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
  namespace: your-namespace
spec:
  serviceAccountName: dynamodb-sa
  containers:
  - name: app
    image: your-application-image

설정 검증

설정이 제대로 되었는지 확인하기 위해 테스트 Pod를 생성하고 권한을 확인해봅시다:

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: aws-test-pod
spec:
  serviceAccountName: dynamodb-sa
  containers:
  - name: aws-cli
    image: amazon/aws-cli:latest
    command: ["sleep", "3600"]
EOF

# IAM Role 확인
kubectl exec -it aws-test-pod -- aws sts get-caller-identity

# DynamoDB 테이블 리스트 확인
kubectl exec -it aws-test-pod -- aws dynamodb list-tables --region ap-northeast-2

정상적으로 설정된 경우 다음과 같이 DynamoDB 테이블 목록을 확인할 수 있습니다:

권한 테스트 결과

마무리

IRSA를 사용하면 EKS의 Pod가 안전하게 AWS 리소스에 접근할 수 있습니다. 초기 설정은 다소 복잡할 수 있지만, 보안성과 관리 용이성 측면에서 큰 이점이 있습니다. 특히 마이크로서비스 아키텍처에서 서비스별로 세밀한 권한 제어가 필요한 경우 IRSA는 최적의 선택이 될 것입니다.