안녕하세요!
[머리말]
IAM 의 Role 과 Policy에 대한 정의는 대부분 이해하고 계실 것입니다. Role은 Policy와 연계되어 그에 정의된 권한을 보유하며, Service 또는 User에도 sts:AssumeRole 방식으로 부여될 수 있습니다. Policy는 AWS Managed Policy와 Customer Managed Policy의 타입이 존재하며 Inline 형태로 자세한 권한 부여가 가능합니다.
위의 내용이 각각 무엇인지 쉽게 이해가 가능하시다면, 잘 알고 계신 것입니다. 하지만 한 가지 질문을 드려보겠습니다.
AWS service-linked role 과 AWS service role, Role, service role for an EC2 instance가 각각 어떤 것인지 이해하고 계신가요??
때론 위의 차이가 리소스 배포에서 큰 차이를 불러옵니다. 이번 글에서는 IAM Role에 대한 상세한 정보를 확인해 보겠습니다.
[ 정의 ]
우선 정의에 대해 알아보겠습니다.
참고 : https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html
위 참고에 정의된 내용을 기반으로 아래와 같이 정리해 보겠습니다.
1. Role : AWS Account에 생성할 수 있는 특정 권한을 정의한 IAM identity입니다.
우리가 콘솔에서 손으로 생성한 role은 대부분 Role입니다.
arn:aws:iam::Account_ID:role/AMI-Factory-01
2. AWS Service-linked role : “AWS 서비스에 직접적으로 연결(link) 된 유니크한 형태의 서비스”라고 설명되어 있습니다
arn:aws:iam::Account_ID:role/aws-service-role/eks.amazonaws.com/AWSServiceRoleForAmazonEKS
3. AWS service role : AWS Service가 특정 권한을 사용할 수 있도록 만들어진 Role입니다.
일반적으로 AWS Service를 구축할 때 IAM 항목에서 서비스가 사용할 수 있는 권한을 부여하고 그때 사용되는 role입니다.
Create a Role을 선택하면 AWS 내부적으로 신규로 생성되며 서비스가 정상적으로 작동하기 위한 필요 권한을 모두 보유하게 됩니다.
arn:aws:iam::Account_ID:role/service-role/CloudTrailRoleForCloudWatchLogs
4. service role for an EC2 instance : EC2에 부여하여 EC2에서 실행되는 application이 AWS resource에 대한 사용 권한을 갖도록
허용해 주는 Role입니다. EC2 생성 시 IAM Role을 지정할 수 있습니다.
arn:aws:iam::Account_ID:instance-profile/Role-EC2-SSM-Full
그 외에도 위의 참고 문서엔 Role chaining, Delegation, Federation, Trust policy 등 다양한 특징이 정의되어 있으니 꼭 참고해주십시오.
* Tips!
각 role 별 ARN을 보면 Path 정의가 다르게 되어 있는 것을 볼 수 있습니다!
즉 Policy를 통해 똑같은 권한을 부여했다고 해도, 위의 Role마다 AWS 내부에서 서로 다른 정의와 작동 방식을 가지고 있음을 알 수 있습니다.
이게 어떤 차이를 불러올까요??
** Tips!!
IAM 콘솔에서 개인이 직접 생성할 수 있는 것은 1, 2, 4입니다. 3번은 수동 생성이 불가능합니다!
AWS 서비스 배포 시 IAM 선택항목에서 Create Role 을 통해 AWS 직접 생성 방식으로 만들어야 합니다.
한번 생성 한 후에 남아 있는 role을 지정하여 권한을 부여할 수 있습니다.
다음 회에서 정리할 S3 replication with S3 function에서 바로 위의 특징이 커다란 차이를 불러옵니다.
S3 replication을 구현할 때 필요한 IAM role은 바로 3번, AWS Service role이 필요합니다.
즉 Create Role을 통해 롤을 생성한 후 그대로 사용하거나, 해당 Role을 생성 후 Role에 몇 가지 권한을 추가하여 사용해야 합니다.
*Tips!!
service role의 경우 콘솔 및 IaC(Terraform)에서 생성할 수 없는데, 서비스 구축 시 특별히 service role이 필요하다고
명시가 되어 있는 것도 아닙니다. 이 경우 서비스 구축 시 계속 에러는 발생하는데 원인 찾기는 매우 어렵습니다.
실제 제가 경험한 스텝은 아래와 같습니다.
(1) s3 replication 구성 시 우선 IAM role을 생성하여 권한 부여 > 에러 발생
(2) administrator acess와 같은 최상위 권한을 부여 > 에러 발생
(3) IAM role을 지정하지 않고 Create a Role 을 선택 > 에러 발생
(4) s3는 다 encryption 되어 있어 KMS에 대한 권한이 IAM에 추가되어 있어야 함 > Policy 수정, 권한 부여
(5) s3 replication 구성 시 IAM을 (4) 작업을 통한 role 선택 > 성공
위 작업에서 볼 수 있는 에러는 s3 replication 구성 실패 및 s3 object replication failed뿐이라 IAM의 개념을 잘 이해하지 못하면 상당한 시간이 트러블 슈팅에 소모됩니다!
또한 Terraform을 통한 IaC 구현 시엔 콘솔을 보지 않게 되고 ,terraform에서 떨어지는 error는 또 다른 메시지라 더욱 혼돈의 시간을 겪게 됩니다!!!
위 Role의 차이를 반드시 숙지해 주시고, 권한 이슈 발생 시 테스트 대상에 참고해 주십시오!!
이 내용은 향후 S3 replication with Feature에서 다시 한번 반복되며 다른 서비스 활용 글에서도 IAM 필요 시마다 강조할 예정입니다.
[ 결론 ]
IAM의 서비스는 상당히 단순해 보이는 콘솔 구조에 비해 룰을 타이트하게 가지고 갈수록 많은 에러와 좌절을 경험하게 됩니다.
오히려, 아무 이슈 없이 사용해 오셨다면 상당히 넓은 범위의 권한을 부여해 오셨다고 생각할 수도 있습니다.
하지만 항상, 필요한 핵심 권한만 부여하고, 인증된 사용자에게만 지정하는 것이 보안의 첫걸음 임을 유념해 주십시오!
