IAM Role은 특정 권한을 가진 자격(Identity)이지만, 그 자격을 영구적으로 소유하는 주체(사람)은 없다. 필요할 때만 잠시 빌려쓰는 모자(Hat)나 유니폼에 비유할 수 있다.

1. Role의 구조: 두 가지 정책(Policy)의 만남

Role을 생성할 때 가장 어려운 부분이다. Role은 반드시 두 가지 종류의 정책을 가진다.

1.1. 신뢰 정책 (Trust Policy) - 누가 이 모자를 쓸 수 있는가?

• 정의: 이 Role을 누가 가져갈(Assume) 수 있는지 허용하는 조건이다.
• Principle: 모자를 쓸 수 있는 주체를 명시한다.
• 예시: 이 Role은 오직 ec2.amazonaws.com만 사용할 수 있다.

// Trust Policy 예시
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "ec2.amazonaws.com" }, // EC2만 이 역할을 맡을 수 있음
      "Action": "sts:AssumeRole"
    }
  ]
}

1.2. 권한 정책 (Permission Policy) - 이 모자를 쓰면 무엇을 할 수 있는가?

• 정의: 우리가 흔히 아는 IAM 정책이다. S3 읽기, DynamoDB 쓰기 등의 실제 권한을 정의한다.
• 예시: S3의 my-bucket을 읽을 수 있다.

---

2. 동작 원리: STS와 임시 자격 증명

Role을 사용한다는 것은 기술적으로 AWS STS(Security Token Service)를 호출한다는 것이다.

1. 요청 (Assume Role): EC2나 사용자가 AWS에게 “어떠한 Role을 사용하고 싶다(AssumeRole)”라고 요청한다.
2. 검증: AWS는 해당 Role의 신뢰 정책(Trust Policy)을 확인하여, 요청한 주체가 허용된 주체인지 검사한다.
3. 발급
   • 검증이 통과되면 STS는 임시 보안 자격 증명(Temporary Security Credentials)를 발급해준다.
   • 이 자격 증명은 3 가지로 구성된다.
     1. AccessKeyId (임시)
     2. SecretAccessKey (임시)
     3. SessionToken (핵심: 이것이 있어야 임시 키로 인정된다)
4. 만료: 이 자격 증명은 설정된 시간(15분 ~ 12시간)이 지나면 자동으로 폐기되어 사용할 수 없게 된다.

---

3. 백엔드 개발자 필수 개념: 인스턴스 프로파일 (Instance Profile)

콘솔에서 EC2에 Role을 연결할 때는 보이지 않지만, 내부적으로는 인스턴스 프로파일이라는 컨테이너가 존재한다.

• 문제: IAM Role은 개념적인 자격이라서 물리적인 서버인 EC2에 직접 붙일 수 없다.
• 해결: IAM Role은 인스턴스 프로파일이라는 그릇에 담아서 EC2에 전달한다.
• 개발자가 알아야 할 것
  • 콘솔에서는 Role을 만들면 자동으로 프로파일도 만들어줘서 신경 쓸 필요가 없다.
  • 하지만 Terraform이나 CloudFormation으로 인프라를 짤 때는, aws_iam_role과 aws_iam_instance_profile리소스를 각각 만들고 연결해줘야 한다. (배포 시 자주 발생하는 에러 원인)

---

4. 실전 시나리오: Cross-Account Access (계정 간 접근)

회사에서 개발과 운영 계정이 분리되어있을 때 개발 서버에서 운영 S3의 로그를 읽어야 한다면 어떻게 해야할까

1. Prod 계정
   • LogReaderRole이라는 Role을 만든다
   • 권한 정책: S3 읽기 허용
   • 신뢰 정책: "Dev 계정(Account ID: 12345)이 이 Role을 맡을(Assume) 수 있다”고 명시
2. Dev 계정
   • 개발 서버(EC2)에 부여된 Role에 “Prod 계정의 LogReaderRole을 Assume할 수 있는 권한”을 준다.
3. 코드 동작
   • 개발 서버 코드는 먼저 STS에게 “Prod 계정의 Role로 바꿔줘”라고 요청한다.
   • 응답 받은 임시 키를 이용해 S3 클라이언트를 다시 생성하여 접근한다.

---

5. iam:PassRole 권한 (배포 파이프라인 에러 1순위)

백엔드 개발자가 Jenkins나 Github Actions로 EC2/Lambda를 배포할 때 가장 많이 만나는 에러이다.

• 상황: 개발자가 Lambda 함수를 생성하는 코드를 실행한다. 이 Lambda에는 S3FullAccess Role을 붙이려고 한다..
• 에러: ClientError: User A is not authorized to perform: iam:PassRole
• 이유
  • Lambda에 S3FullAccess같은 강력한 Role을 붙이는 행위는 간접적으로 개발자가 그 강력한 권한을 쓰는 것과 같다.
  • 따라서 AWS는 “너가 이 Role을 Lambda에게 전달(Pass)할 자격이 있어?”라고 물어본다.
• 해결: 배포를 수행하는 사용자(또는 CI/CD Role)에게 iam:PassRole권한이 반드시 있어야 한다.

---

요약

1. Role은 영구적인 키(Key) 없고 STS를 통해 발급 받는 만료 시간이 있는 임시 토큰으로 동작한다.
2. Role을 만들 때는 “누가 쓸 수 있는지”를 정하는 신뢰 정책(Trust Policy) 설정이 가장 중요하다.
3. EC2/Lambda가 다른 리소스에 접근할 때는 무조건 Role을 사용하고 절대 코드에 Access Key를 넣지 않는다.