AWS

AWS Assume Role이란?

Somaz 2024. 11. 4. 20:09
728x90
반응형

Overview

AWS Assume Role은 하나의 AWS 계정이나 사용자, 서비스가 다른 역할(Role)을 임시로 가정(Assume)하여 그 역할의 권한으로 리소스에 접근할 수 있도록 해주는 핵심 보안 기능이다.

 

특히 다음과 같은 환경에서 자주 사용된다.

  • 교차 계정 액세스 (Cross-Account Access): 계정 A에서 계정 B의 리소스를 관리하고 싶을 때
  • OIDC 기반 외부 인증 (예: GitHub Actions, Kubernetes 등)
  • 임시 권한 부여로 최소 권한 원칙 구현

 

sts:AssumeRole, sts:AssumeRoleWithWebIdentity API 호출을 통해 역할을 수락하고, 일시적인 자격 증명(access key, secret key, session token)을 발급받아 권한 위임을 안전하게 수행할 수 있다.

 

 

 

출처 : https://linuxbeast.com/blog/how-to-set-up-cross-account-access-in-aws-with-assumerole/

 

 

 

 

 

📅 관련 글

2022.02.13 - [AWS] - AWS IAM (Identity and Access Management) 개요 및 설정 방법

2022.02.07 - [AWS] - AWS EC2 인스턴스 생성

2022.02.13 - [AWS] - AWS S3 (Simple Storage Service) 개요 및 활용 방법

2023.03.30 - [AWS] - AWS Secrets Manager란?(OAuth, SSO)

2023.03.29 - [AWS] - AWS CLI 정리

2023.03.28 - [AWS] - AWS IAM이란?

2023.03.28 - [AWS] - AWS S3 권한이란?

2023.03.28 - [AWS] - AWS S3란?(개념, 속성)

2023.03.30 - [AWS] - AWS Cloudfront란? / Canary 및 Blue-Green 배포

2023.04.03 - [AWS] - AWS VPC란?

2023.05.26 - [AWS] - AWS IRSA(IAM Roles for Service Accounts)란?

2024.11.07 - [AWS] - AWS Ingress Annotations 정리

2024.11.04 - [AWS] - AWS Assume Role이란?

2024.11.16 - [AWS] - AWS Network ACL vs Security Group

2024.11.21 - [AWS] - ALB access Log 활성화 → S3 권한 설정 및 로그 저장

2024.11.24 - [AWS] - EKS Pod Identity Addon

2024.11.27 - [AWS] - AWS DynamoDB란?

2025.01.03 - [AWS] - AWS DynamoDB Local 설치

 

 

 

 

 

 

 




 

 

 

AWS Assume Role

AWS Assume Role는 AWS에서 하나의 사용자 또는 서비스가 다른 역할(Role)을 임시로 수락하고, 그 역할에 설정된 권한을 임시로 사용할 수 있게 하는 기능이다. 이 기능을 통해 보안성과 관리 편의성을 높이면서도 필요한 권한만을 안전하게 사용할 수 있다.

  • sts:AssumeRole 작업을 사용하면 다른 AWS 계정이나 자신의 계정 내에 존재하는 역할을 맡을 수 있다. 역할을 맡으면 해당 역할과 관련된 권한을 일시적으로 획득하게 된다.
    • 교차 계정 액세스: 다른 AWS 계정의 역할을 맡아 해당 계정의 리소스에 액세스할 수 있다.
    • 동일 계정 내: 현재 명령을 실행하는 사용자 또는 서비스와 다른 권한을 가진 역할을 맡는다.

 

 

 

Assume Role 사용 예시

  • 다음은 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 콘솔을 사용하여 계정 B에서 역할을 가정할 수 있다.

  • 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 또는 외부 IdP와 같은 CI/CD 시스템이다.
  • 장기 IAM 자격 증명 없이도 AWS 리소스에 대한 안전하고 단기적인 액세스가 가능하다.

 

프로세스

  • 외부 IdP(OIDC 공급자)는 사용자 또는 서비스에 OIDC 토큰을 발급한다. 토큰은 AssumeRoleWithWebIdentity API 호출의 일부로 AWS로 전송된다.
  • AWS는 구성된 OIDC 공급자에 대해 토큰을 확인한 다음 토큰과 조건이 유효한 경우 위임된 역할에 대한 임시 자격 증명을 발급한다.

 

 

sts:AssumeRole vs  sts:AssumeRoleWithWebIdentity

기능 sts:AssumeRole sts:AssumeRoleWithWebIdentity
인증 AWS IAM 자격 증명(액세스 키 및 비밀) OIDC 토큰 또는 SAML 어설션
사용 사례 AWS 내 교차 계정 액세스 외부 공급자의 통합 액세스
지원되는 ID AWS IAM 엔터티(사용자, 그룹, 역할) Federated ID(예: Google, GitHub, Cognito)
CI/CD 공통 - GitHub Actions, Kubernetes 등과 함께 일반적으로 사용

 

 

 

 

 


 

 

 

 

 

실무 적용을 위한 추가 자료 모음

 

1. sts assume-role CLI 실습 스크립트

# AssumeRole 명령 실행
aws sts assume-role \
  --role-arn arn:aws:iam::111122223333:role/YourRoleName \
  --role-session-name demo-session \
  --duration-seconds 3600 > temp-creds.json

# 환경 변수에 자격 증명 설정
export AWS_ACCESS_KEY_ID=$(jq -r '.Credentials.AccessKeyId' temp-creds.json)
export AWS_SECRET_ACCESS_KEY=$(jq -r '.Credentials.SecretAccessKey' temp-creds.json)
export AWS_SESSION_TOKEN=$(jq -r '.Credentials.SessionToken' temp-creds.json)

# 확인: 다른 계정에서 권한 있는 리소스 조회
aws s3 ls

 

jq 도구가 필요하며, 만약 없다면 brew install jq 혹은 apt install jq 등으로 설치하자.

 

 

 

 

 

2. GitHub Actions용 OIDC 설정 예제

 

AssumeRoleWithWebIdentity 를 사용하는 GitHub Actions 설정 예시:

# .github/workflows/deploy.yml
name: Deploy to AWS

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - name: Configure AWS credentials
      uses: aws-actions/configure-aws-credentials@v2
      with:
        role-to-assume: arn:aws:iam::111122223333:role/GitHubOIDCRole
        aws-region: ap-northeast-2

    - name: Deploy app
      run: aws s3 ls
  • 해당 역할은 IAM 신뢰 정책에서 GitHub의 OIDC 공급자를 신뢰해야 한다.

 

 

 

 

3. EKS/Kubernetes와 Assume Role 연동 구성도

Account A                        Account B
---------                       ---------
IAM 사용자 or CI/CD  ---> sts:AssumeRole ---> IAM Role (EKS 권한)
                                      |
                                +-----------+
                                | EKS 클러스터 |
                                +-----------+

 

 

 

 

4. IAM 정책 템플릿 모음

 

계정 A 사용자에게 Assume Role 권한 부여 (IAM 정책)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::111122223333:role/TargetRole"
    }
  ]
}

 

 

 

계정 B의 역할 신뢰 정책

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/AssumingUser"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
  • 상황에 따라 Principal 을 사용자 대신 role/CI-CD-Role 로 설정 가능

 

 

 

 

 

 

 

 

 

 

 


 

 

 

 

 

마무리: AWS 보안의 핵심은 권한 위임

Assume Role은 단순한 권한 부여 기능이 아니라, 보안성과 운영 효율성을 동시에 만족시키는 AWS의 핵심 아키텍처 중 하나이다.

 

특히 교차 계정 관리, CI/CD 파이프라인 연동, SSO 환경 구성, 클라우드 거버넌스 구축 등에 광범위하게 활용되며, 보안 사고를 예방하고 IAM 구조를 단순화할 수 있다.

 

 

Tip

  • 다수의 계정을 사용하는 조직에서는 중앙 관리 계정에서 필요한 리소스를 Assume Role 방식으로 접근하는 것이 일반적이다.
  • GitHub Actions 등 외부 워크플로우에서는 sts:AssumeRoleWithWebIdentity 를 통한 OIDC 인증으로 장기 IAM 키 없이도 안전한 연동이 가능하다.

 

 

Assume Role을 제대로 이해하고 활용하는 것은 AWS 실무자의 필수 역량이다.

 

 

 

 

 

 

 

 


Reference

https://linuxbeast.com/blog/how-to-set-up-cross-account-access-in-aws-with-assumerole/

 

https://cloudstudio.com.au/2021/06/06/aws-assumerole/

728x90
반응형

'AWS' 카테고리의 다른 글

AWS Network ACL vs Security Group  (0) 2024.11.16
AWS Ingress Annotations 정리  (0) 2024.11.07
AWS IRSA(IAM Roles for Service Accounts)란?  (0) 2023.05.28
AWS VPC란?  (0) 2023.04.07
AWS Cloudfront란? / Canary 및 Blue-Green 배포  (0) 2023.04.03