IAM이 도대체 뭘까?

그런데 자바 기반 프로젝트는 NodeJS의 PM2처럼 무중단 배포를 지원하는 라이브러리가 마땅치 않은 것 같아 고민하고 있었는데, AWS의 CodeDeploy로 Blue-Green 배포 방식을 사용해 무중단 배포가 가능하다는 얘기를 들었습니다. 그래서 CodeDeploy 서비스를 이용하고자 하였습니다.

그런데 CodeDeploy 배포 환경을 구축하던 중 IAM의 낯선 개념과 마주하게 되었습니다. 바로 역할(Role)과 정책(Policy)이었습니다.

IAM도 아직 뭔지 잘 모르겠는데 얘네는 더 모르겠네요…!

오늘은 IAM이 뭐고 여기 나오는 용어들은 무엇인지에 대해서 정리하고자 합니다!

IAM(Identity and Access Management)

정의

AWS Identity and Access Management(IAM)은 AWS 리소스에 대한 액세스를 안전하게 제어할 수 있는 웹 서비스입니다. IAM을 사용하면 사용자가 액세스할 수 있는 AWS 리소스를 제어하는 권한을 중앙에서 관리할 수 있습니다. IAM을 사용하여 리소스를 사용하도록 인증(로그인) 및 권한 부여(권한 있음)된 대상을 제어합니다.

AWS 계정을 생성할 때는 해당 계정의 모든 AWS 서비스 및 리소스에 대한 완전한 액세스 권한이 있는 단일 로그인 ID로 시작합니다. 이 자격 증명은 AWS 계정 루트 사용자라고 하며, 계정을 생성할 때 사용한 이메일 주소와 암호로 로그인하여 액세스합니다. 일상적인 태스크에 루트 사용자를 사용하지 않을 것을 강력히 권장합니다. 루트 사용자 보안 인증 정보를 보호하고 루트 사용자만 수행할 수 있는 작업을 수행하는 데 사용합니다. 루트 사용자로 로그인해야 하는 태스크의 전체 목록은 AWS Account Management 참조 안내서의 Tasks that require root user credentials(루트 사용자 보안 인증이 필요한 태스크)를 참조하세요.

AWS 공식 문서에서는 IAM을 다음과 같이 소개하고 있다. 큰 개념은 내가 알고 있는 것과 크게 차이나지 않았다.

AWS 계정 루트 사용자라는 관리자용 계정이 있고, 그 아래 여러 사용자(계정이라고도 말함)을 두고 그 사용자가 이용할 수 있는 권한을 관리하는 서비스를 IAM이라고 정리해 볼 수 있다.

필수 용어

IAM에서 사용되는 몇가지 필수 용어에 대해서 정리에 대해서 정리하고자 한다. 이 용어가 정리되지 않으면 AWS를 이용할 때 중간에 튀어나오는 설정들이 무슨 설정인지 이해하지 못한채로 넘기게 될 수 있다.

정책과 권한

정책을 생성하고 IAM 자격 증명(사용자, 사용자 그룹 또는 역할) 또는 AWS 리소스에 연결하여 AWS에서 액세스를 관리합니다. 정책은 자격 증명이나 리소스와 연결될 때 해당 권한을 정의하는 AWS의 객체입니다. AWS는 IAM 보안 주체(사용자 또는 역할)가 요청을 보낼 때 이러한 정책을 평가합니다. 정책에서 권한은 요청이 허용되거나 거부되는지를 결정합니다. 대부분의 정책은 AWS에 JSON 문서로 저장됩니다. AWS에서는 자격 증명 기반 정책, 리소스 기반 정책, 권한 경계, Organizations SCP, ACL 및 세션 정책이라는 여섯 가지 정책 유형을 지원합니다.

정책은 액세스 제어를 정의하는 문서 또는 객체로 이해할 수 있다. 정책은 특정 작업에 대한 권한을 정의하는 것을 말하고, 권한은 해당 작업을 수행할 수 있는 실제 권한을 말한다.

예를 들어 정책 중에 AmazonS3FullAccess라는 정책이 있다. 이 정책에는 이 정책을 부여받은 객체가 어떤 서비스를 이용할 수 있는지, 그 권한을 정의하고 있다.

즉, AmazonS3FullAccess를 부여받은 객체는 S3와 S3 Object Lambda 서비스를 이용할 수 있는 권한을 갖는다.

S3라는 서비스에서 수행할 수 있는 작업의 목록도 확인이 가능하다.

AWS에는 현재 1101개의 정책이 있으며, 루트 사용자는 이러한 모든 정책에 대한 제어와 액세스 권한을 갖는다. 이는 루트 사용자가 AWS 계정의 모든 리소스와 서비스에 대한 제어를 갖고 있다는 것을 의미한다.

AWS는 보안 및 권한 관리를 위해 루트 계정을 최소한으로 사용하고 IAM 사용자와 그룹을 생성하여 필요한 권한을 할당하는 것을 권장하고 있다.

여기서 객체에게 정책을 부여할 수 있다는 것에 주목해야 한다. AWS에서는 사용자나 역할에 정책을 부여할 수 있다. 자세한 설명은 추후에 진행하겠다.

사용자(혹은 계정)와 사용자 그룹

앞에서 설명한 사용자와 동일한 개념이다. AWS에 가입할 때 루트 사용자를 처음 만들게 되고, 이 루트 사용자가 여러 다른 사용자를 만들어 사용자들에게 정책을 부여할 수 있다. 이렇게 만들어진 사용자를 IAM 사용자라는 용어로 주로 부른다.

까비도 IAM 사용자를 부여 받아서 이용하고 있다. 이노베이션 아카데미 재단 측이 루트 계정을 소유하고 있고, 과거 보컬이셨던 doosoo님께서 IAM 루트 계정을 이용하여 CABI라는 IAM 사용자를 만들어 까비팀에게 제공해주셨다. (현재는 크리스틴님이 담당하고 계신다.)

루트 사용자가 부여해준 정책하에서, CABI라는 IAM 사용자는 자유롭게 AWS 서비스를 이용할 수 있다.

(심지어는 필요한 정책을 가졌다면 IAM 사용자가 추가로 사용자, 사용자 그룹을 생성할 수도 있다.)

여러 사용자에게 동일한 권한을 부여하고 싶은 경우도 종종 있을 것이다.

이때 사용자 그룹을 만들어 한 번에 관리할 수 있다.

사진처럼 sichoi와 test-deploy라는 사용자를 하나의 그룹으로 묶고, 동일하게 AdministratorAccess라는 정책을 부여할 수 있다.

(42 Intra에서 월렛마켓으로 AWS 크레딧을 구매하면 IAM 사용자 계정을 부여 받게 되는데, 아마 이것도 크레딧을 구매한 사용자들을 사용자 그룹으로 묶고 모두 동일한 권한을 부여하고 있지 않을까 추측하고 있다.)

역할

계정에서 생성할 수 있는 특정 권한을 가진 IAM 자격 증명입니다. IAM 역할은 IAM 사용자와 몇 가지 점에서 유사합니다. 역할과 사용자 모두 AWS에서 자격 증명으로 할 수 있는 것과 할 수 없는 것을 결정하는 권한 정책을 포함하는 AWS 자격 증명입니다. 그러나 역할은 한 사람과만 연관되지 않고 해당 역할이 필요한 사람이라면 누구든지 맡을 수 있어야 합니다. 또한 역할에는 그와 연관된 암호 또는 액세스 키와 같은 표준 장기 자격 증명이 없습니다. 대신에 역할을 맡은 사람에게는 해당 역할 세션을 위한 임시 보안 자격 증명이 제공됩니다.

앞에서 사용자에게 정책을 부여하여 서비스에 대한 액세스 권한을 컨트롤할 수 있다고 말했었다. 그런데 상황에 따라 사용자가 아니라 서비스 인스턴스가 다른 서비스 인스턴스를 사용해야하는 경우도 종종 발생할 것이다.

예를 들어 EC2와 CodeDeploy가 있다. CodeDeploy는 자동적으로 소스코드를 배포할 수 있도록 하는 서비스이다. 그런데 만약 EC2 인스턴스에 소스코드를 배포하려고 하는 경우에는 어떻게 해야할까?

EC2 인스턴스에 대한 접근권한을 가진 유저가 직접 허용을 해줘야 한다면, 작업이 수동으로 이루어지는 것이기 때문에 CodeDeploy 서비스를 이용하는 것 자체가 의미가 없어질 것이다.

따라서 CodeDeploy에서 EC2 인스턴스를 사용할 수 있는 권한을 가질 수 있어야 한다..! AWS에서 이를 가능하게 해주는 것이 바로 역할이다.

역할은 미리 지정한 정책들의 묶음이다. 이 역할을 부여받은 사용자나 서비스는 임시로 정책들이 지정한 권한들을 획득할 수 있다.

사진에서 여러 역할들이 정의되어 있다. 신뢰할 수 있는 개체가 해당 역할을 맡고 있는 객체를 의미한다.

예를들어 sysadmin이라는 이름의 역할을 031498277935라는 계정 ID를 가진 사용자가 맡고 있고,

sichoi-test-codedeploy-role이라는 이름의 역할을 AWS 서비스 중 EC2 인스턴스가 맡고 있다.

역할을 클릭하면 해당 역할이 묶고 있는 정책 목록을 확인할 수 있다.

사진에서는 sichoi-test-codedeploy-role라는 역할이 AmazonEC2RoleforAWSCodeDeploy라는 정책을 가지고 있다. 해당 역할을 맡고 있는 EC2 인스턴스는 이 정책을 부여받고 있는 것이다.

CodeDeploy가 EC2 인스턴스에 대한 배포 작업을 수행하기 위해서는 사진처럼AmazonEC2RoleforAWSCodeDeploy라는 정책을 가진 역할을 EC2 인스턴스에 부여해야 한다.

(참고)

CodeDeploy에서 배포 그룹을 만들 때 역시 대상 인스턴스로 액세스할 수 있도록 AWSCodeDeployRole이라는 정책을 가진 역할을 부여해주어야 한다.

(참고) 역할을 사용할 수 있는 주체

역할과 동일한 AWS 계정의 IAM 사용자

역할과 다른 AWS 계정의 IAM 사용자

AWS에서 제공하는 웹 서비스(Amazon EC2)

외부 자격 증명 공급자(IdP) 서비스에 의해 인증된 외부 사용자

역할과 보안 그룹

엇 근데 분명 RDS랑 EC2 인스턴스를 연동시켜서 EC2에서 RDS Database를 이용할 수 있게 할 때는 EC2에게 역할을 부여하지 않고, EC2 인스턴스와 RDS 인스턴스를 동일한 보안 그룹으로 묶었었다.

그러면 역할을 부여하는 것과 보안 그룹으로 묶는게 어떤 차이가 있을까?

보안 그룹이란?

보안 그룹은 Virtual Private Cloud(VPC)의 리소스와 주고받을 수 있는 트래픽을 제어하는 방화벽 역할을 합니다. 인바운드 트래픽 및 아웃바운드 트래픽을 허용하는 포트 및 프로토콜을 선택할 수 있습니다.

각 보안 그룹에 인바운드 트래픽과 아웃바운드 트래픽에 대한 별개의 규칙 집합을 추가합니다. 자세한 내용은 보안 그룹 규칙 섹션을 참조하세요.

(VPC에 대한 설명은 아래 토글을 참고해주세요!)

VPC(Virtual Private Cloud)란?

보안 그룹은 한마디로 VPC 내의 서비스들끼리 통신하는 것을 제어하는 방화벽으로 이해할 수 있다.

보안 그룹의 인바운드 규칙을 다음과 같이 설정하게 되면 같은 VPC에 있는 인스턴스들끼리 3306 포트를 통해 TCP 프로토콜로 통신할 수 있도록 하겠다는 의미가 된다.

즉, EC2 인스턴스와 RDS 인스턴스를 같은 VPC에 두고 이런식으로 보안 그룹을 설정하게 되면 EC2에서 RDS 데이터베이스에 3306 포트를 통해 접근해서 사용할 수 있다.

RDS와 EC2 통신 구조

이 통신 과정은 위와 같은 구조로 이해할 수 있다. Region 안에 같은 VPC로 RDS와 EC2 인스턴스가 존재하고, 미리 정의한 보안 그룹의 인바운드 규칙에 따라서 VPC의 서비스들 간의 통신이 이루어진다.

역할 부여와 보안 그룹 설정의 차이점 정리

애초에 둘은 서로 다른 개념이다. 사용하는 목적과 사용 사례에서 차이점이 있다.

EC2에서 CodeDeploy를 이용할 때는 EC2 인스턴스가 임시로 해당 권한을 취득할 수 있도록 필요한 역할을 EC2에 부여해주어야 한다. CodeDeploy는 EC2나 RDS처럼 IP를 갖는 서버가 아니기 때문에 애초에 보안 그룹을 설정한다는 것 자체가 어불성설이다.

반면 EC2와 RDS는 둘 다 IP를 갖는 서버이고, 연동하기 위해서는 동일한 VPC에 있어야 하며 보안 그룹을 설정하여 3306 포트로 통신할 수 있도록 해야 한다.