AWS IAM 권한 쪽 메모

개인 프로젝트하다가 협업자에게 내 s3 내의 특정 bucket 에 대한 권한을 부여할 일이 생겼는데, 과정에서 좀 헷갈리는 부분이 많아 그 과정을 정리해봤다. 나의 케이스에서는

1. iam role 에 accessS3Role을 만들고,
2. 해당 role 의 trust policy에 협업자의 arn을 넣었으며,
3. 마지막으로 inline policy 에 특정 bucket 이름에 대한 fullAccess 를 부여하였다.

---

1. IAM (Identity and Access Management)

• AWS의 인증/권한 시스템.
• 사용자(User), 그룹(Group), 역할(Role), 정책(Policy)을 통해 “누가 무엇을 할 수 있는지” 를 정의함.
• 모든 권한은 정책(JSON 문서) 으로 관리됨.

2. IAM User vs IAM Role

항목	IAM User	IAM Role
정의	AWS 계정 내 정해진 사용자의 고정된 자격	누군가가 “임시로” assume(역할 수행) 하는 대상
인증 방식	Access Key / Secret Key	AssumeRole API 호출로 발급받은 임시 토큰
사용 주체	본인 계정의 사용자	다른 계정의 사용자, AWS 서비스, 외부 주체
대표 예	user/john	role/accessS3Role

 

IAM Role은 크게 다음 두 가지 정책에 의해 구성됨

구성 요소	목적	저장 위치
Trust Policy	누가 이 Role을 Assume할 수 있는가? (역할 위임자)	Role > Trust relationships
Permissions Policy  (Managed or Inline)	이 Role은 무엇을 할 수 있는가? (행동 권한)	Role > Permissions

 

IAM Role: accessS3Role
├── Trust Policy (who can assume me?)
│   └── Example: john 사용자만 이 Role을 Assume할 수 있음
│       - Principal: arn:aws:iam::123456789012:user/john
│       - Action: sts:AssumeRole
│
├── Permissions Policy (what can I do?)
│   ├── Inline Policy (Role 전용으로 부착됨)
│   │   └── 예: rolly-poly 버킷의 특정 prefix에 List/Get/Put/Delete 허용
│   │
│   └── OR Managed Policy (재사용 가능한 정책을 attach)
│       └── 예: AmazonS3ReadOnlyAccess 등 AWS 제공 정책 사용 가능

 

trust Policy의 역할 (Assume Role을 허용하는 쪽)

• “누가 이 Role을 빌릴 수 있는가?” 를 정의

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::123456789012:user/john"
  },
  "Action": "sts:AssumeRole"
}

 

 

Permissions Policy의 역할 (Assume한 후에 할 수 있는 것들)

• “이 Role을 Assume한 사람은 무엇을 할 수 있는가?”
• 주로 아래 두 가지 방식으로 Role에 붙음:
  1. Inline Policy: 해당 Role 전용으로 정의
  2. Managed Policy: 여러 Role/User가 공유할 수 있는 정책
• 예시 (Inline Policy):

{
  "Effect": "Allow",
  "Action": [ "s3:GetObject", "s3:PutObject" ],
  "Resource": "arn:aws:s3:::{BUCKET}/{PATH}/*"
}

 

언제 User Policy, 언제 Role Policy?

목적	추천 방식	이유
외부 협업자에게 읽기 권한만 주기	Role + AssumeRole	보안 우수, 만료 가능한 세션 사용
빠르게 테스트/스크립트 실행	User + AccessKey + User Policy	설정 간단, 권한 바로 부여 가능
조직 내부 로그인/CLI 실행	User + Managed Policy	고정 자격 기반, 명확한 책임 추적
S3, KMS, RDS 등에 서비스 간 접근 부여	Role + Inline Policy or Attached Policy	신뢰 주체(Principal)를 명확히 설정 가능