AKS에서 OIDC를 통한 AWS S3 액세스 구성 가이드

AKS(Azure Kubernetes Service)에서 OIDC 연동을 사용하여 AWS 액세스 키 없이 S3 버킷에 안전하게 액세스하는 방법을 실습을 통해 알아봅니다.

2025. 8. 19.
7개 태그

AKS에서 OIDC를 통한 AWS S3 액세스 구성 가이드

🔍 개요

AKS(Azure Kubernetes Service) 클러스터에서 실행되는 애플리케이션이 AWS 액세스 키 없이 S3 버킷과 같은 AWS 리소스에 안전하게 액세스하는 방법을 소개합니다.

이 가이드에서는 OIDC(OpenID Connect) 연동을 통해 IAM 역할을 받아 임시 자격 증명을 사용하는 방식을 사용합니다.

왜 OIDC를 사용해야 할까요?

  • 보안 강화: AWS Access Key와 같은 장기 자격 증명을 코드나 Secret에 저장할 필요가 없습니다.
  • 동적 자격 증명: IAM 역할을 통해 자동으로 갱신되는 단기 임시 자격 증명을 사용하므로 보안성이 뛰어납니다.
  • 감사 용이성: 어떤 Pod가 어떤 IAM 역할을 사용했는지 AWS CloudTrail을 통해 명확하게 추적할 수 있습니다.
  • 세분화된 권한 관리: Kubernetes ServiceAccount 단위로 AWS 권한을 부여하여 최소 권한 원칙을 쉽게 적용할 수 있습니다.

1. 전체 아키텍처

전체 구성 요소와 인증 흐름은 아래 다이어그램과 같습니다.

Mermaid diagram

1.1 인증 흐름 상세

Mermaid diagram

2. 사전 준비

이 가이드를 진행하기 전에 다음 환경이 준비되어 있어야 합니다.

  • Azure CLIkubectl이 설치된 환경
  • AKS 클러스터에 대한 관리자 권한
  • AWS 계정 및 IAM 리소스를 생성할 수 있는 권한

3. AKS (Azure Kubernetes Service) 구성

3.1 OIDC Issuer 기능 활성화

Workload Identity vs OIDC만 활성화

AKS에서 Azure 리소스 액세스에는 일반적으로 Workload Identity를 사용합니다. 하지만 이 가이드에서는 OIDC Issuer만 활성화하는 이유는:

  • Workload Identity: AKS → Azure 리소스 (Key Vault, Storage Account 등) 연동
  • OIDC Issuer만: AKS → 외부 Identity Provider (AWS, GCP 등) 연동

AWS S3와 연동하려면 AKS의 OIDC 토큰을 AWS IAM에서 신뢰할 수 있도록 OIDC Issuer 기능만 필요하며, Azure Workload Identity는 불필요합니다.

먼저, AKS 클러스터가 OIDC 자격 증명을 발급할 수 있도록 OIDC Issuer 기능을 활성화합니다.
이미 활성화된 경우 이 단계는 건너뛸 수 있습니다. (한번 활성화를 하면 다시 비활성화는 불가능)

az aks update \
--resource-group <MY_AZURE_RG> \
--name <MY_AKS_CLUSTER> \
--enable-oidc-issuer

Azure Portal에서도 활성화가 가능합니다.

Azure Portal에서 AKS 클러스터의 OIDC Issuer 기능을 활성화하는 설정 화면

3.2 OIDC Issuer URL 확인

활성화된 OIDC Issuer의 URL을 확인합니다. 이 URL은 나중에 AWS IAM OIDC 자격 증명 공급자를 생성할 때 필요합니다.

az aks show \
--resource-group <MY_AZURE_RG> \
--name <MY_AKS_CLUSTER> \
--query "oidcIssuerProfile.issuerUrl" \
--output tsv

Azure Portal에서도 OIDC Issuer URL 확인이 가능합니다.

Azure Portal에서 AKS 클러스터의 OIDC Issuer URL을 확인하는 화면
URL을 복사해두세요!

발급자 URL은 보통 https://<region>.oic.prod-aks.azure.com/{tenant-id}/{cluster-id}/ 형태입니다.

3.3 ServiceAccount 생성

AKS에서 Pod가 사용할 ServiceAccount를 생성합니다.
해당 ServiceAccount의 이름과 네임스페이스는 AWS IAM Role의 신뢰 정책에서 사용됩니다.

serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: s3-access-sa
  namespace: default

3.4 OIDC 토큰 검증

ServiceAccount가 올바르게 설정되었는지 확인하기 위해 실제 JWT 토큰을 생성하고 내용을 검증해보겠습니다.

3.4.1 JWT 토큰 생성

OIDC 토큰의 발급자(iss)와 대상(aud) 이해
  • 발급자(iss): "이 토큰을 누가 만들었는가?" → AKS OIDC Issuer URL
  • 대상(aud): "이 토큰은 누구를 위해 발급된 것인가?" → AKS에서 사용하므로 이것도 AKS OIDC Issuer URL
  • AWS 인증 방식: AWS STS는 토큰의 iss와 aud가 등록된 OIDC 공급자와 일치하는지 확인

그럼 실제 ServiceAccount를 사용하여 토큰 생성 및 검증절차를 진행해보겠습니다.

# ServiceAccount를 사용하여 JWT 토큰 생성
TOKEN=$(kubectl create token s3-access-sa --duration=3600s)

# 생성된 토큰 확인 (처음 50글자만 표시)
echo "생성된 JWT 토큰 (일부): " 
echo $TOKEN | cut -c1-50

# 토큰을 파일로 저장 (선택사항)
echo $TOKEN > /tmp/aks-jwt-token.txt

3.4.2 JWT 토큰 디코딩 및 검증

JWT 토큰은 점(.)으로 구분된 세 부분으로 구성됩니다: header.payload.signature. 우리는 payload 부분을 디코딩하여 토큰의 내용을 확인할 수 있습니다.

# JWT 토큰의 payload 부분 추출 및 디코딩
PAYLOAD=$(echo $TOKEN | cut -d'.' -f2)

# Base64 디코딩 (패딩 추가 처리)
echo $PAYLOAD | base64 -d 2>/dev/null || echo "$PAYLOAD=" | base64 -d 2>/dev/null || echo "$PAYLOAD==" | base64 -d 2>/dev/null || echo "$PAYLOAD===" | base64 -d

# jq가 설치되어 있다면 JSON 형태로 예쁘게 출력
echo $TOKEN | cut -d'.' -f2 | base64 -d 2>/dev/null | jq . 2>/dev/null || echo "jq가 설치되지 않았습니다. 원시 JSON이 출력됩니다."

# 핵심 필드만 추출하여 확인
echo "=== 핵심 필드 검증 ==="
DECODED=$(echo $TOKEN | cut -d'.' -f2 | base64 -d 2>/dev/null)
echo "Issuer (iss):"
echo $DECODED | jq -r '.iss' 2>/dev/null || echo "수동으로 확인 필요"
echo "Audience (aud):"
echo $DECODED | jq -r '.aud[]' 2>/dev/null || echo "수동으로 확인 필요"
echo "Subject (sub):"
echo $DECODED | jq -r '.sub' 2>/dev/null || echo "수동으로 확인 필요"

3.4.3 검증 포인트

생성된 JWT 토큰에서 다음 값들이 올바른지 확인하세요:

확인해야 할 핵심 필드
  1. iss (Issuer): 1.2 단계에서 확인한 AKS OIDC Issuer URL과 정확히 일치해야 합니다.

  2. aud (Audience): AKS OIDC Issuer URL과 동일해야 합니다 (기본값).

  3. sub (Subject): system:serviceaccount:default:s3-access-sa 형태여야 합니다.

  4. exp (Expiration): 토큰 만료 시간 (Unix timestamp)

  5. iat (Issued At): 토큰 발급 시간 (Unix timestamp)

실제 JWT 토큰 디코딩 결과 예시:

실제 JWT Payload 예시
{
  "aud": [
    "https://koreacentral.oic.prod-aks.azure.com/00000000-0000-0000-0000-000000000000/11111111-1111-1111-1111-111111111111/",
    "https://<cluster-name>.hcp.koreacentral.azmk8s.io",
    "\"<cluster-name>.hcp.koreacentral.azmk8s.io\""
  ],
  "exp": 1755673306,
  "iat": 1755669706,
  "iss": "https://koreacentral.oic.prod-aks.azure.com/00000000-0000-0000-0000-000000000000/11111111-1111-1111-1111-111111111111/",
  "jti": "a8c8e96a-2aea-4a3f-8aa2-779b2bee8853",
  "kubernetes.io": {
    "namespace": "default",
    "serviceaccount": {
      "name": "s3-access-sa",
      "uid": "c400e143-64db-4338-a986-41001239c272"
    }
  },
  "nbf": 1755669706,
  "sub": "system:serviceaccount:default:s3-access-sa"
}

핵심 필드 검증 결과:

Issuer (iss): https://koreacentral.oic.prod-aks.azure.com/00000000-0000-0000-0000-000000000000/11111111-1111-1111-1111-111111111111/
Audience (aud): https://koreacentral.oic.prod-aks.azure.com/00000000-0000-0000-0000-000000000000/11111111-1111-1111-1111-111111111111/, https://<cluster-name>.hcp.koreacentral.azmk8s.io, "<cluster-name>.hcp.koreacentral.azmk8s.io"
Subject (sub): system:serviceaccount:default:s3-access-sa
Audience 배열이 AWS 인증에 미치는 영향

기본 토큰의 문제점:

  • aud 배열에 3개 값 포함: OIDC Issuer URL, AKS API Server URL, API Server URL(따옴표 포함)
  • AWS IAM은 정확히 일치하는 단일 audience만 허용 → 인증 실패

해결방법:
Pod 매니페스트에서 audience를 명시적으로 지정하면 해당 값만 포함된 토큰 발급 (이후 단계에서 설명)

온라인 JWT 디코더 사용 (대안):

명령줄 도구가 없는 경우 jwt.io와 같은 온라인 JWT 디코더를 사용할 수 있습니다. 생성된 토큰을 복사하여 붙여넣으면 디코딩된 내용을 확인할 수 있습니다.

보안 주의사항

프로덕션 환경의 JWT 토큰을 온라인 서비스에 입력하지 마세요. 테스트 목적으로만 사용하시기 바랍니다.

4. AWS (Amazon Web Services) 구성

4.1 IAM OIDC 자격 증명 공급자 생성

AWS IAM이 AKS 클러스터에서 발급한 OIDC 토큰을 신뢰하도록 설정합니다.

  1. AWS IAM 콘솔로 이동하여 자격 증명 공급자(Identity providers) 메뉴를 선택합니다.
  2. 공급자 추가(Add provider) 버튼을 클릭합니다.
  3. OpenID Connect를 선택합니다.
  4. 공급자 URL(Provider URL): 1.2 단계에서 확인한 AKS OIDC Issuer URL을 입력합니다. (앞의 https:// 포함)
  5. 대상(Audience): AKS OIDC Issuer URL을 입력합니다. (Provider URL과 동일)
  6. **공급자 추가(Add provider)**를 클릭하여 생성을 완료합니다.
AWS IAM에서 AKS OIDC Provider URL과 Audience를 입력하는 설정 페이지

4.2 S3 접근용 IAM Role 생성

이제 AKS의 ServiceAccount가 임시 자격 증명(Assume)을 획득할 IAM Role을 생성합니다.

4.2.1 신뢰 관계(Trust Policy) 설정

먼저 IAM Role이 어떤 주체를 신뢰할지 정의하는 Trust Policy를 작성합니다.
우리의 경우 특정 AKS ServiceAccount에서 발급한 OIDC 토큰만 신뢰하도록 제한해야 합니다.

iam-trust-policy.json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::<AWS_ACCOUNT_ID>:oidc-provider/<OIDC_ISSUER_URL_WITHOUT_HTTPS>"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "<OIDC_ISSUER_URL_WITHOUT_HTTPS>:sub": "system:serviceaccount:default:s3-access-sa",
          "<OIDC_ISSUER_URL_WITHOUT_HTTPS>:aud": "https://<OIDC_ISSUER_URL_WITHOUT_HTTPS>/"
        }
      }
    }
  ]
}
주요 필드 설명
  • Federated: 2.1 단계에서 생성한 OIDC 공급자의 ARN을 입력합니다. <OIDC_ISSUER_URL_WITHOUT_HTTPS> 부분은 https://를 제외한 URL입니다.

  • Action: OIDC 토큰으로 임시 자격 증명을 요청할 수 있는 sts:AssumeRoleWithWebIdentity 액션을 허용합니다.

  • Condition:

    • sub (subject) 클레임이 지정한 ServiceAccount와 일치하는지 확인
    • aud (audience) 클레임이 OIDC Issuer URL과 정확히 일치하는지 확인 (끝에 "/" 필수)

4.2.2 권한 정책(Permission Policy) 연결

생성한 역할에 S3 버킷에 접근할 수 있는 최소한의 권한을 부여합니다.

iam-permission-policy.json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
      "Resource": "arn:aws:s3:::<MY_S3_BUCKET>/*"
    },
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::<MY_S3_BUCKET>"
    }
  ]
}

4.2.3 IAM Role 생성 및 정책 연결

이제 준비한 정책들을 사용하여 실제 IAM Role을 생성합니다.

# 1. Trust Policy로 IAM Role 생성
aws iam create-role \
--role-name AKS-S3-Access-Role \
--assume-role-policy-document file://iam-trust-policy.json

# 2. S3 Permission Policy를 Role에 연결 (인라인 정책)
aws iam put-role-policy \
--role-name AKS-S3-Access-Role \
--policy-name S3AccessPolicy \
--policy-document file://iam-permission-policy.json

# 3. 생성된 Role의 ARN 확인 (나중에 Pod 환경변수에서 사용)
aws iam get-role \
--role-name AKS-S3-Access-Role \
--query 'Role.Arn' \
--output text
생성된 Role ARN 저장

생성된 IAM Role의 ARN을 복사해두세요.
예: arn:aws:iam::123456789012:role/AKS-S3-Access-Role

이 ARN은 이후 Pod 매니페스트의 AWS_ROLE_ARN 환경변수에서 사용됩니다.

5. 샘플 애플리케이션 배포

이제 모든 설정을 마쳤으니, 실제 Pod를 배포하여 테스트해 보겠습니다.

5.1 프로젝트 디렉토리 구조

먼저 테스트를 위한 프로젝트 디렉토리 구조를 준비합니다:

aks-oidc-s3-demo/
├── app/
│   └── main.py                 # Python S3 업로드 스크립트
├── k8s/
│   ├── serviceaccount.yaml     # Kubernetes ServiceAccount
│   └── job.yaml                # Kubernetes Job 매니페스트
├── Dockerfile                  # Docker 이미지 빌드 파일
└── requirements.txt            # Python 의존성
프로젝트 구성
  • app/: Python 애플리케이션 소스 코드
  • k8s/: Kubernetes 매니페스트 파일들
  • Dockerfile: 컨테이너 이미지 빌드 설정
  • requirements.txt: Python 패키지 의존성 목록

5.2 Python 테스트 스크립트

S3에 테스트 파일을 업로드하는 간단한 Python 스크립트입니다. boto3 라이브러리는 필요한 환경변수가 설정되어 있으면 자동으로 OIDC 인증을 수행합니다.

app/main.py
import boto3
import os
import logging
from datetime import datetime, timezone, timedelta

# 로깅 설정
logging.basicConfig(level=logging.INFO, format='%(asctime)s - %(levelname)s - %(message)s')
logger = logging.getLogger(__name__)

# 한국 표준시 (UTC+9)
KST = timezone(timedelta(hours=9))

def verify_aws_identity() -> bool:
    """현재 AWS 자격 증명 정보를 확인하고 출력합니다."""
    try:
        logger.info("현재 AWS 자격 증명을 확인합니다...")
        sts_client = boto3.client('sts')
        identity = sts_client.get_caller_identity()
        logger.info(f"  - AWS 계정: {identity['Account']}")
        logger.info(f"  - 역할 세션 ARN: {identity['Arn']}")
    except Exception as e:
        logger.error(f"❌ AWS 자격 증명 확인 실패: {e}")
        return False
    return True

def upload_to_s3() -> None:
    """boto3를 사용하여 S3에 파일을 업로드합니다."""
    local_file = 'aks-oidc-test.txt'
    try:
        # 환경변수에서 S3 버킷 이름과 리전 정보 가져오기
        bucket_name = os.getenv('S3_BUCKET_NAME')
        region = os.getenv('AWS_REGION', 'ap-northeast-2')

        if not bucket_name:
            raise ValueError("S3_BUCKET_NAME 환경변수가 설정되지 않았습니다.")

        logger.info(f"대상 S3 버킷: {bucket_name}, 리전: {region}")

        # boto3 클라이언트는 환경변수(AWS_ROLE_ARN, AWS_WEB_IDENTITY_TOKEN_FILE)를
        # 기반으로 자동으로 AssumeRoleWithWebIdentity를 호출합니다.
        s3_client = boto3.client('s3', region_name=region)

        # 테스트용 파일 내용 생성
        timestamp_str = datetime.now(KST).strftime('%Y-%m-%d %H:%M:%S KST')
        file_content = f"AKS OIDC S3 Upload Test\nTimestamp: {timestamp_str}\n"
        with open(local_file, 'w', encoding='utf-8') as f:
            f.write(file_content)

        # S3에 업로드할 객체 키 정의
        s3_key = f"uploads/aks-oidc-test-{datetime.now(KST).strftime('%Y%m%d_%H%M%S')}.txt"

        logger.info(f"파일 업로드를 시작합니다: {local_file} -> s3://{bucket_name}/{s3_key}")
        s3_client.upload_file(local_file, bucket_name, s3_key)

        logger.info(f"✅ 파일 업로드 성공! s3://{bucket_name}/{s3_key}")

    except Exception as e:
        logger.error(f"❌ 업로드 중 오류 발생: {e}", exc_info=True)
    finally:
        if os.path.exists(local_file):
            os.remove(local_file)

if __name__ == "__main__":
    logger.info("=== AKS to S3 OIDC 테스트 시작 ===")
    if verify_aws_identity():
        upload_to_s3()
    logger.info("=== 테스트 종료 ===")

5.3 Kubernetes Job 매니페스트

테스트 스크립트를 실행할 Kubernetes Job을 정의합니다. 이 매니페스트 파일이 OIDC 연동의 핵심입니다.

k8s/job.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: aks-oidc-s3-test-job
  namespace: default
spec:
  template:
    spec:
      # 1. 앞에서 생성한 ServiceAccount 지정
      serviceAccountName: s3-access-sa
      containers:
      - name: s3-uploader
        image: "<YOUR_ACR_REGISTRY>.azurecr.io/aks-oidc-s3-demo:latest"
        env:
        # boto3가 자동으로 인식하는 환경변수 설정
        - name: S3_BUCKET_NAME
          value: "<MY_S3_BUCKET>"
        - name: AWS_REGION
          value: "ap-northeast-2"
        - name: AWS_ROLE_ARN
          value: "<MY_IAM_ROLE_ARN>"
        - name: AWS_WEB_IDENTITY_TOKEN_FILE
          value: "/var/run/secrets/tokens/aws-iam-token"
        resources:
          requests:
            memory: "128Mi"
            cpu: "100m"
          limits:
            memory: "256Mi"
            cpu: "200m"
        volumeMounts:
        # 3. Projected Volume을 통해 생성된 토큰을 컨테이너에 마운트
        - name: aws-iam-token
          mountPath: "/var/run/secrets/tokens"
          readOnly: true
      volumes:
      # 2. Kubernetes API에 특정 Audience를 가진 OIDC 토큰을 요청하여 볼륨으로 생성
      - name: aws-iam-token
        projected:
          sources:
          - serviceAccountToken:
              path: aws-iam-token
              # audience는 AWS OIDC 공급자에 등록한 값과 정확히 일치해야 함
              # 기본값 사용 시 여러 audience 값이 배열로 들어가 AWS 인증 실패
              audience: "https://koreacentral.oic.prod-aks.azure.com/tenant-id/cluster-id/" # 반드시 끝에 "/"가 있어야 함
              expirationSeconds: 3600 # 1시간
      restartPolicy: Never
  backoffLimit: 3
핵심 동작 원리
  1. volumes: Pod는 projected 볼륨을 통해 Kubernetes API에 JWT 토큰을 요청합니다. audience를 AKS OIDC Issuer URL로 명시적으로 지정해야 AWS 인증이 성공합니다.

  2. volumeMounts: Kubernetes는 발급받은 JWT 토큰을 /var/run/secrets/tokens/aws-iam-token 경로에 파일로 마운트합니다.

  3. env: AWS_ROLE_ARNAWS_WEB_IDENTITY_TOKEN_FILE 환경변수를 설정합니다. AWS SDK(boto3)는 이 변수들을 발견하면, 지정된 경로의 토큰 파일을 읽어 AssumeRoleWithWebIdentity API를 자동으로 호출합니다.

audience 명시적 지정이 필요한 이유
  • 기본 토큰 생성 시: aud 배열에 여러 값이 포함됩니다 (OIDC Issuer URL, AKS API Server URL 등)
  • AWS 요구사항: AWS IAM OIDC 공급자는 정확히 일치하는 단일 audience 값을 기대합니다
  • 해결방법: audience를 AKS OIDC Issuer URL로 명시하면 aud 배열에 해당 값만 포함되어 AWS 인증이 성공합니다
  • 예시: audience: "https://koreacentral.oic.prod-aks.azure.com/tenant-id/cluster-id/"

6. 배포 및 결과 확인

6.1 Docker 이미지 빌드 및 푸시

먼저 Python 애플리케이션을 Docker 이미지로 패키징하기 위한 파일들을 생성합니다.

requirements.txt
boto3==1.34.144
Dockerfile
FROM python:3.11-slim

WORKDIR /app

# 의존성 설치
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# 애플리케이션 코드 복사
COPY app/ .

# 애플리케이션 실행
CMD ["python", "main.py"]

이제 Docker 이미지를 빌드하고 Azure Container Registry에 푸시합니다:

Docker 이미지 빌드 및 푸시
# Docker 이미지 빌드
docker build -t aks-oidc-s3-demo .

# ACR 로그인
az acr login --name <YOUR_ACR_NAME>

# 이미지 태그 지정 및 푸시
docker tag aks-oidc-s3-demo <YOUR_ACR_NAME>.azurecr.io/aks-oidc-s3-demo:latest
docker push <YOUR_ACR_NAME>.azurecr.io/aks-oidc-s3-demo:latest

6.2 Kubernetes 리소스 배포 및 로그 확인

Kubernetes 리소스 배포 및 테스트
# 1. ServiceAccount 배포
kubectl apply -f k8s/serviceaccount.yaml

# 2. Job 배포 (job.yaml 파일의 플레이스홀더 값을 실제 값으로 변경했는지 확인!)
kubectl apply -f k8s/job.yaml

# 3. Job Pod 상태 확인
kubectl get pods --selector=job-name=aks-oidc-s3-test-job

# 4. Pod 로그 확인하여 S3 업로드 성공 여부 확인
POD_NAME=$(kubectl get pods --selector=job-name=aks-oidc-s3-test-job -o jsonpath='{.items[0].metadata.name}')
kubectl logs -f $POD_NAME

성공 시 로그 예시:

2025-08-19 14:30:00,123 - INFO - === AKS to S3 OIDC 테스트 시작 ===
2025-08-19 14:30:00,123 - INFO - 현재 AWS 자격 증명을 확인합니다...
2025-08-19 14:30:01,456 - INFO -   - AWS 계정: 123456789012
2025-08-19 14:30:01,456 - INFO -   - 역할 세션 ARN: arn:aws:sts::123456789012:assumed-role/MyAksS3Role/botocore-session-1723987801
2025-08-19 14:30:01,457 - INFO - 대상 S3 버킷: <MY_S3_BUCKET>, 리전: ap-northeast-2
2025-08-19 14:30:01,458 - INFO - 파일 업로드를 시작합니다: aks-oidc-test.txt -> s3://<MY_S3_BUCKET>/uploads/aks-oidc-test-20250819_143001.txt
2025-08-19 14:30:02,890 - INFO - ✅ 파일 업로드 성공! s3://<MY_S3_BUCKET>/uploads/aks-oidc-test-20250819_143001.txt
2025-08-19 14:30:02,891 - INFO - === 테스트 종료 ===

이제 AWS S3 콘솔로 이동하여 버킷에 파일이 정상적으로 업로드되었는지 확인해 보세요!

7. 트러블슈팅

오류 메시지일반적인 원인해결 방법
An error occurred (InvalidIdentityToken)OIDC 토큰 검증 실패.- AWS IAM OIDC 공급자 URL이 AKS Issuer URL과 정확히 일치하는지 확인하세요.
- IAM Role 신뢰 정책의 OIDC 공급자 ARN이 올바른지 확인하세요.
An error occurred (AccessDenied)AssumeRoleWithWebIdentity 호출은 성공했으나, 대상 리소스(S3)에 대한 권한이 없음.- IAM Role에 연결된 권한 정책이 올바른 S3 버킷과 액션(GetObject, PutObject 등)을 허용하는지 확인하세요.
could not assume role: unable to load web identity tokenAWS_WEB_IDENTITY_TOKEN_FILE 경로에 토큰 파일이 없거나 읽을 수 없음.- Job 매니페스트의 volumeMounts 경로와 AWS_WEB_IDENTITY_TOKEN_FILE 환경변수 값이 일치하는지 확인하세요.
- Projected Volume 설정이 올바른지 확인하세요.
AccessDenied ... is not authorized to perform: sts:AssumeRoleWithWebIdentity신뢰 정책의 조건 불일치- IAM Role 신뢰 정책의 Condition 블록에서 sub 클레임 값이 ServiceAccount의 네임스페이스와 이름을 정확히 포함하는지 확인하세요 (system:serviceaccount:namespace:name).

✨ 결론

AKS와 AWS IAM OIDC 연동을 통해 더 이상 수동으로 AWS 자격 증명을 관리할 필요 없이, 안전하고 자동화된 방식으로 멀티 클라우드 리소스에 접근할 수 있습니다.

이 방식은 최소 권한 원칙을 준수하고 강력한 감사 추적을 가능하게 하므로, 프로덕션 환경에서 멀티 클라우드를 운영할 때 강력히 권장되는 아키텍처입니다.

이 글이 멀티 클라우드 환경을 구성하는 데 도움이 되셨기를 바랍니다! 💬

이 포스트는 2025년 8월 기준 최신 Azure 및 AWS 공식 문서를 바탕으로 작성되었습니다.
최신 정보는 Microsoft Learn - AKS에서 OIDC 발급자 사용AWS 문서 - IAM OIDC 자격 증명 공급자에서 확인하실 수 있습니다.

댓글

0/500
댓글을 불러오는 중...