Skip to content

KR_AWS_IAM

somaz edited this page Mar 30, 2026 · 1 revision

AWS IAM & Assume Role

1. Assume Role

AWS 역할 가정을 사용하면 임시 보안 자격 증명(액세스 키, 보안 액세스 키 및 세션 토큰)을 획득하여 다른 계정의 AWS 리소스에 액세스하거나 동일한 계정 내에서 다른 권한을 사용할 수 있다.

  • sts:AssumeRole 작업을 사용하면 다른 AWS 계정이나 자신의 계정 내에 존재하는 역할을 맡을 수 있다. 역할을 맡으면 해당 역할과 관련된 권한을 일시적으로 획득하게 된다.

    • 교차 계정 액세스: 다른 AWS 계정의 역할을 맡아 해당 계정의 리소스에 액세스할 수 있다.
    • 동일 계정 내: 현재 명령을 실행하는 사용자 또는 서비스와 다른 권한을 가진 역할을 맡는다.
  • 다음은 Assume Role 을 사용하여 계정 B의 EKS 리소스에 대한 계정 A 액세스 권한을 부여하는 방법이다.

Step1: 계정 B에서 IAM 역할 생성

계정 B에서 계정 A가 이 역할을 맡도록 허용하는 신뢰 정책을 사용하여 IAM 역할을 생성한다. 이 역할은 계정 B에서 EKS 리소스를 관리할 수 있는 권한을 부여한다.

  • 계정 B에 AssumeRole 역할 생성 예시: 이 정책은 계정 A의 사용자 또는 역할이 다음 역할을 맡도록 허용한다.
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root" // Account A ID
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

또는 계정 A에서 특정 역할을 지정할 수 있다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/AccountARole"  // Replace with specific role in Account A
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
  • 계정 B의 역할에 EKS 권한을 연결한다.
    • EKS 리소스를 관리하기 위해 AmazonEKSClusterPolicy 또는 사용자 지정 권한과 같은 필수 EKS 정책을 역할에 연결한다.

Step2: 계정 A에서 IAM 정책 생성

계정 A의 사용자 또는 서비스가 계정 B의 역할을 맡도록 허용하려면 계정 A에서 IAM 정책을 생성한다.

계정 A 정책 예시:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::111122223333:role/EKSAdminRole" // Role ARN in Account B
    }
  ]
}
  • 이 정책을 계정 A의 필요한 사용자, 그룹 또는 역할에 연결한다.

Step3: 계정 A에서 역할 위임

역할을 맡을 권한이 있는 계정 A의 사용자 또는 서비스는 AWS CLI, SDK 또는 AWS 콘솔을 사용하여 이를 수행할 수 있다.

AWS CLI 예시:

aws sts assume-role \
  --role-arn arn:aws:iam::111122223333:role/EKSAdminRole \
  --role-session-name eks-session
  • 이 명령은 계정 B에서 EKS 클러스터에 액세스하고 관리하는 데 사용할 수 있는 임시 자격 증명(액세스 키, 비밀 키 및 세션 토큰)을 제공한다.

Step4: 액세스를 위해 임시 자격 증명 사용

  • 임시 자격 증명을 사용하면 계정 A에 권한이 있는 것처럼 계정 B의 리소스를 관리할 수 있다.

계정 B에서 EKS 클러스터를 관리하도록 kubeconfig를 업데이트 예시:

aws eks --region us-west-2 update-kubeconfig --name eks-cluster \
  --role-arn arn:aws:iam::111122223333:role/EKSAdminRole
  • 이를 계정 A의 kubectl을 사용하여 계정 B에서 EKS 클러스터를 관리할 수 있다.

sts:AssumeRoleWithWebIdentity

Google, GitHub Actions, AWS Cognito 또는 OIDC 호환 ID 공급자와 같은 외부 공급자(OIDC 또는 SAML)로부터 연합된 ID를 기반으로 역할을 임시로 획득하기 위해 사용된다.

인증 방식

AWS IAM 자격 증명 대신 OIDC 토큰 또는 SAML 어설션이 필요하다.

주요 사용 사례
  • OIDC 통합 액세스: GitHub Actions, Kubernetes 서비스 계정, AWS Cognito 또는 외부 ID 공급자와 같은 CI/CD 시스템.
  • 장기 IAM 자격 증명 없이 AWS 리소스에 안전하고 단기적으로 접근할 수 있다.
  • OIDC 공급자가 사용자나 서비스에 OIDC 토큰을 발급하고, 해당 토큰을 AssumeRoleWithWebIdentity API 호출에 포함하여 AWS로 전송한다.
  • AWS는 구성된 OIDC 공급자를 기준으로 토큰을 검증하고, 토큰 및 조건이 유효한 경우 역할에 대한 임시 자격 증명을 발급한다.
sts:AssumeRole vs sts:AssumeRoleWithWebIdentity
특징 sts:AssumeRole sts:AssumeRoleWithWebIdentity
인증 방식 AWS IAM 자격 증명 (액세스 키와 비밀 키) OIDC 토큰 또는 SAML 어설션
사용 사례 AWS 내 계정 간 접근 외부 공급자로부터 통합 접근
지원 ID 유형 AWS IAM 엔터티(사용자, 그룹, 역할) 연합 ID(예: Google, GitHub, Cognito)
CI/CD 통합 드물게 사용됨 GitHub Actions, Kubernetes 등에서 자주 사용됨

목록으로 돌아가기

Clone this wiki locally