개요

IAM

AWS 입문을 해 봤다면 IAM 이라는 단어는 자주 들어봤을 것이다. IAM은 사용자 또는 AWS 사용 권한에 대한 관리를 하는 웹 서비스로 보통 사용자를 생성할 때 해당 서비스를 사용하는 것을 볼 수가 있다. IAM 에도 여러가지 세분화가 되어 있는데. 이중에 IAM User는 사용자를 관리하는 항목이다.

IAM User와 AWS Configure를 이용한 AWS 접근

보통 웹 콘솔 말고도 내 컴퓨터나, 서버단에서 AWS 서비스를 사용해야 할 때가 있다. 이 AWS 서비스들을 사용하기 위해 사용자 인증을 하게 되는데 이때 사용되는 툴이 AWS Configure이다.

$ aws configure
AWS Access Key ID [****************]:
AWS Secret Access Key [****************]:
... 이하 생략 ...

IAM에서 유저를 생성하면 그 유저에 대한 엑세스 키 아이디(Access Key ID)와 시크릿 엑세스 키(Secret Access Key)를 발행하게 되는데, 이 두개를 AWS Configure에 입력을 해야 비로소 로컬 또는 특정 EC2 서버에서 AWS CLI를 통해 웹 콘솔 없이 AWS 리소스에 접근할 수 있다. 백엔드 서버에서 모듈로 사용하는 경우, 해당 모듈을 사용하기 전에 이 두개를 등록을 해 줘야 한다. 그런데, 로컬은 그렇다 쳐도 EC2에서 이렇게 AWS Configure로 유저 정보를 저장하면 발생하는 문제점이 몇가지 있다.

1. 파일에 저장하는 방식이기 때문에 정보가 유출될 가능성이 있다.
2. 엑세스 키에 기한이 설정되어 있는 경우, 만료됬을 때 AWS 서비스를 사용하는 프로덕트가 정상적으로 작동이 안될 수 있다.
3. 실무에서 AWS 정보의 주인이 퇴사를 하게 되면, AWS 정보를 바꿔야 하는 번거로움이 발생하게 된다.

이러한 문제점 때문에 EC2에서 AWS Configure를 사용하지 않고도 AWS를 접근할 수 있는 대안이 생기게 되는데 이게 바로 IAM Role(IAM 역할) 이다.

IAM Role

IAM User가 사용자의 권한을 의미한다면 IAM Role은 특정 AWS 서비스에서 다른 AWS 서비스에 접근하기 위한 권한을 관리하는 항목이다. 그러니까, IAM User가 “사람 대 서비스” 였다면, IAM Role은 “서비스 대 서비스” 라고 보면 된다. 예를 들어 아까 위에서 설명했던 EC2에서 S3를 접근하고 싶다고 할때, S3를 접근하는 IAM Role를 생성한 다음, 그 IAM Role을 EC2에 부착하면 된다.

사용법

이번 IAM Role 목표는, EC2에서 aws-cli로 S3에 있는 버킷과 파일들을 접근하기 위해 Role을 생성해서 EC2에 붙이려고 한다. (aws-cli는 설치가 되어 있다고 가정한다. aws-cli 설치방법)

Role 생성

IAM에 들어가서 IAM resources의 Roles를 클릭한다.

새 Role을 만들어야 하니 Create Role을 선택한다.

첫번째 스탭으로 누가 이 Role을 사용하는지 선택한다. 우리는 EC2에서 S3에 접근하는 것이 목표이기 때문에 EC2를 고른다.

이번엔 어느 서비스를 접근하는지 골라야 한다. 우리는 S3에 있는 데이터들을 읽는게 목표이기 때문에 AmazonS3ReadOnlyAccess 를 선택한다.

S3에 있는 데이터들을 읽기 만 하기 때문에 가급적 ReadOnly 권한을 설정해 줘야 한다. 왜냐하면 IAM에서 권한을 줄 때 딱 필요한 권한만 주는게 원칙이기 때문이다. 사실 특정 버킷을 의미하는 Resource도 모든 리소스를 조회하는 “*“가 아닌 조회하고자 하는 특정 버킷들의 arn만 작성해야 하지만 여기까지 하면 너무 길어지니 생략.

이제 Role의 이름만 지어주면 된다. 나는 example-for-ec2로 이름지었다.

다시 IAM Role로 돌아가 보면 생성이 되어있음을 알 수 있다.

EC2에 붙여넣기

EC2 인스턴스 중에 IAM Role이 적용되지 않는 인스턴스를 선택한 다음 Actions > Security > Modify IAM Role을 선택한다.

여기서 아까 만들었던 Role을 선택한다.

다시 돌아가 보면 IAM Role이 부착되었음을 알 수 있다.

IAM Role이 부착된 EC2를 콘솔로 접근한 다음 아래와 같은 명령어를 입력해 보자 S3 버킷 리스트를 불러올 수 있다면 정상적으로 작동이 된 것이다.

ubuntu@ip-127-00-00-000:~$ aws s3 ls
2024-01-26 09:06:37 bucket1
2023-11-29 11:01:03 bucket2
2024-01-26 04:57:58 bucket3

만약 접근이 안된다면 아래와 같은 결과가 나온다.

ubuntu@ip-127-00-00-000:~$ aws s3 ls

An error occurred (AccessDenied) when calling the ListBuckets operation: User: arn:aws:sts::00000000000:assumed-role/example-for-ec2/i-000000000000 is not authorized to perform: s3:ListAllMyBuckets because no identity-based policy allows the s3:ListAllMyBuckets action

해석을 하자면 s3 버킷 리스트를 불러오기 위해서는 s3:ListAllMyBuckets 라는 권한이 없기 때문에 불러올 수 없다는 뜻이 된다. 이럴 때는 IAM Role이 제대로 부착되어 있는지 확인하고, 부착이 되어 있더라도 Actions에 s3:ListAllMyBuckets가 제대로 명시되어 있는지 다시 한번 확인하자.

이밖의 다른 사용법들

위에 서술하다시피, IAM Role은 AWS를 사용하는 백엔드가 구축된 EC2 또는 ECS 컨테이너에서 IAM User 대용으로 사용하기도 하지만 이 외에도 여러 용도가 있다.

Cloudwatch Logging

서버를 운영하다 보면 무슨 이슈가 발생했다거나 뭔가를 확인하기 위해 로그를 살펴볼 때가 있다. 그런데 로그는 보통 서버 인스턴스 내부에서 출력이 된다. 그렇다고 해서 일일이 EC2 컨테이너에 들어가기에는 많이 번거롭기 때문에 EC2에 있는 로그들을 Cloudwatch로 내보내서 웹상에서 로그를 볼 수 있게 작업을 하는 경우가 있는데, 이는 EC2에서 Cloudwatch라는 서비스를 사용하는, 즉 “서비스 대 서비스”가 되기 때문에 이때 IAM Role이 사용된다. 정확히는 EC2의 IAM Role에 Cloudwatch 관련 권한을 부여하는 것이다. 이때 권한명은 CloudWatchLogsFullAccess 이다.

AWS Lambda

Serverless API 서비스로 유명한 AWS Lambda는 일단 만들기만 하면 IAM Role이 자동으로 생성된다. AWS Lambda는 말 그대로 Serverless 이므로 EC2 처럼 프린팅 해서 콘솔상에서 볼 수 있는 방법이 없기 때문에 바로 자동으로 Cloudwatch와 연동이 되는 것이다. 그래서 AWS Lambda에서 로직을 작성할 때 로그를 출력하는 코드를 작성하고 실행을 하면, 그 출력 정보는 Cloudwatch에 바로 기록이 된다.

마치며

IAM User가 각각 사용자들의 권한을 관리하는 서비스라면, IAM Role은 서비스 간의 연동 및 사용에 관한 권한을 관리하는 서비스로, AWS 서비스를 관리함에 있어 상당히 비중이 있는 항목이다. 그렇기 때문에 IAM Role에 대해서 공부해 보고 실제로 적용을 하면, AWS를 관리함에 있어 상당히 유용할 수 있다.