Overview
AWS Assume Role에 대해서 알아본다.
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 등과 함께 일반적으로 사용 |
Reference
https://linuxbeast.com/blog/how-to-set-up-cross-account-access-in-aws-with-assumerole/
'AWS' 카테고리의 다른 글
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 |
AWS Secrets Manager란?(OAuth, SSO) (0) | 2023.04.01 |