[AWS] RDS 권한만을 가진 IAM 사용자로 RDS 인스턴스 생성 시 오류가 발생하는 문제

lsjbh45·2023년 1월 29일
1

AWS 서비스를 이용할 때 루트 사용자 계정으로 모든 서비스를 이용하는 것은 대단히 위험하다. AWS에서는 루트 사용자 계정을 관리자 권한을 가진 IAM(Identity and Access Management) 사용자를 처음 생성하거나 꼭 자격 증명이 필요한 작업일 때만 사용하고, 나머지 작업들은 모두 IAM 사용자를 별도로 만들어서 하기를 권고하고 있다.

세분화된 조직이 아닌 경우라면 모든 서비스에 액세스가 가능하도록 하는 PowerUserAccess 정책을 부여한 IAM 사용자를 만들어 개발용으로 사용해도 무방하다고 한다. 하지만 어차피 IAM 사용자를 만들어서 사용해야 하는 김에, 서비스 별로 IAM 사용자를 생성하고 분리해서 작업을 해 보기로 했다. 사용할 서비스는 EC2와 RDS였기 때문에 AmazonEC2FullAccess 정책을 부여한 EC2group에 IAM 사용자 ec2를, AmazonRDSFullAccess 정책을 부여한 RDSgroup에 IAM 사용자 rds를 각각 생성했다. EC2 인스턴스는 ec2 사용자로 문제 없이 만들어졌는데, RDS 인스턴스를 rds 사용자로 생성하려는 과정에서 계속 오류가 발생했다.

발생하는 오류

당시 발생하던 오류는 아예 다음과 같은 메시지가 나타나면서 인스턴스 생성이 되지 않는 오류였다.

DB 인스턴스 database-1 생성 요청이 실패했습니다. User: arn:aws:iam::****:user/rds is not authorized to perform: iam:CreateRole on resource: arn:aws:iam::****:role/rds-monitoring-role

최근에 다시 당시 상황을 재현해 보니, RDS 인스턴스 자체는 생성되지만, 정상적으로 생성되었다는 메시지 대신 다음과 같은 오류 문구가 발생하는 것을 확인할 수 있었다.

권한 누락으로 인해 데이터베이스 null에 대해 향상된 모니터링을 활성화하지 못함 User: arn:aws:iam::****:user/rds is not authorized to perform: iam:CreateRole on resource: arn:aws:iam::****:role/rds-monitoring-role because no identity-based policy allows the iam:CreateRole action

Enhanced Monitoring과 정책 부여

오류 문구들을 확인해 보면 ‘Monitoring Role’, ‘향상된 모니터링’ 등 모니터링과 관련된 권한 문제일 것으로 예상되었다. RDS 인스턴스를 생성하기 위해 설정하는 여러 옵션들 중 모니터링 > 추가 구성 > 향상된 모니터링 부분을 확인해 보니 Enhanced 모니터링 활성화가 기본적으로 선택되어 있는 것을 볼 수 있었다. Enhanced Monitoring을 활성화하지 않도록 설정한다면 되었겠지만, 당시에는 활성화해야 하는 것인 줄 알고 관련된 내용들을 여러 가지 찾아보게 되었다.

RDS 인스턴스를 생성하기 위한 권한에 대해 설명해 둔 공식 문서의 ‘Enhanced Monitoring 및 성능 개선 도우미 활성화’ 문단을 보면, RDS가 만들어질 때 사용자가 Enhanced Monitoring을 활성화할 수 있도록 관련 권한을 부여해 주어야 한다. 공식 문서를 참조해서, 다음과 같은 정책을 직접 만들어서 rds 사용자가 포함되어 있는 RDSgroup에 부여해 주었다. 문서에서는 iam:PassRole의 경우에는 모든 리소스에 대해(와일드카드 * 사용) 부여하지 않을 것을 권장하고 있었지만, 우선은 테스트를 위해 모든 리소스에 대해 허용해 보았다. (이 부분은 아래 문단에서 자세히 다룰 예정이다.)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "iam:GetRole",
                "iam:ListRoles",
                "rds:ModifyDBInstance",
                "iam:PassRole",
                "rds:Describe*",
                "ec2:Describe*",
            ],
            "Resource": "*"
        }
    ]
}

문제가 해결될 줄 알았지만, 그럼에도 불구하고 계속해서 권한이 부족하다는 메시지가 발생하였다.

RDS Monitoring Role

자동 생성을 위한 권한 정책 부여

다시금 여러 내용들을 확인해 보니, 한 글에서 정책 부여 시에 다음과 같은 권한 정책 두 가지를 추가로 부여해서 문제를 해결했다는 내용을 확인하게 되었다.

{
		...,
    "Statement": [
        {
						...,
            "Action": [
								...,
								"iam:CreateRole",
                "iam:AttachRolePolicy"
						],
						...
				}
		]
}

위 권한 정책이 필요한 이유는 Monitoring Role 때문이었는데, 공식 문서를 보면 RDS 인스턴스 생성 시 설정에서 역할 모니터링 (Monitoring Role)을 ‘기본값’으로 설정하면 RDS가 자동적으로 IAM 역할 rds-monitoring-role을 생성하도록 권한을 부여한다는 안내가 있었다. rds-monitoring-role 이 만들어지지 않은 상태였기 때문에, IAM 역할 rds-monitoring-role을 함께 생성하기 위해 관련 권한을 부여해 주어야 했던 것이다.

이렇게 추가적인 권한까지 포함한 정책을 사용자에게 부여해 주면 드디어 문제 없이 RDS 인스턴스가 만들어진다. 또한 실제로 IAM 서비스의 역할 항목을 확인해 보면 원래 없었던 rds-monitoring-role이라는 역할이 새로 생성되어 있다.

직접 역할 생성

한편, 앞서 정책을 생성할 때 iam:PassRole을 모든 리소스에 대해 부여하도록 정의하게 되면 다음과 같은 보안 경고를 맞닥뜨리게 된다.

PassRole With Star In Resource: 리소스 내 와일드카드(*)를 포함하는 iam:PassRole 작업을 사용하면 여러 리소스에 대해 iam:PassRole 권한을 허용할 수 있으므로 지나치게 허용적일 수 있습니다. 대신 리소스 ARN을 지정하거나 iam:PassedToService 조건 키를 문에 추가하는 것이 좋습니다. 자세히 알아보기

이 보안 경고를 없애고 정책을 깔끔하게 정의하는 방식은 없을까? 공식 문서에 따르면 RDS Monitoring Role을 생성하는 방식으로는 위 문단처럼 자동으로 생성되도록 하는 방식만 있는 것이 아니라 직접 생성하고 사용자가 위임받아 권한을 가지도록 설정하는 방식도 존재한다.

후자의 방식을 사용해 1) IAM 권한을 가진 계정으로 미리 AmazonRDSEnhancedMonitoringRole 정책을 부여받은 역할을 생성해 두고, 2) 사용자가 해당 역할만을 위임받아 사용할 수 있도록 iam:PassRoleResource를 지정한 정책을 사용자에 부여한 뒤, 3) RDS 인스턴스 생성 시 설정에서 역할 모니터링을 해당 역할로 지정하여 Enhanced Monitoring 활성화를 수행하도록 하는 것이 바람직해 보인다.

이 방식대로 진행하게 되면 드디어 위 문단과 같은 추가적인 권한 부여 없이 처음 확인했던 공식 문서에서 제시하는 다음 정책을 생성하고, RDS가 만들어질 때 사용자가 Enhanced Monitoring을 활성화할 수 있도록 권한을 부여해 줄 수 있다.

{
	  "Version": "2012-10-17",
	  "Statement": [
		    {
			      "Effect": "Allow",
			      "Action": [
				        "iam:GetRole",
				        "iam:ListRoles",
				        "rds:ModifyDBInstance",
				        "rds:Describe*",
				        "ec2:Describe*"
			      ],
			      "Resource": "*"
		    },
		    {
			      "Effect": "Allow",
			      "Action": [
				        "iam:PassRole"
			      ],
			      "Resource": "arn:aws:iam::************:role/rds-monitoring-role"
		    }
	  ]
}

마치며

AWS의 복잡한 권한 관리를 경험해 보며 AWS의 세분화된 정책(Policy)과 역할(Role)에 관해 잘 알고 사용해야 함을 몸소 이해할 수 있었다. 특히 보안적인 측면에서 상당히 민감한 것이 클라우드 서비스이기에, 필요한 권한의 범위에 맞게 IAM 사용자를 생성하는 것이 필요하다는 것을 체험했다. 관련 작업을 하며 참고한 정책과 역할에 관해 명확히 설명해 둔 블로그 글이 있어서 링크를 남겨두고자 한다.

또한, AWS의 프리 티어를 이용하고 있다면 인스턴스를 생성할 때 프리 티어에 맞는 설정을 정확히 했는지를 반드시 확인해야 한다(RDS 인스턴스라면 단일 AZ, db.t2.micro/db.t3.micro/db.t4g.micro, 스토리지 20GB 제한 등). 이 포스팅의 주제인 권한과 관련된 작업을 십수 번 반복적으로 시도하다가 정작 중요한 인스턴스 설정을 빼먹어 기본 설정에 해당하는 db.m6g.large Multi-AZ instance가 만들어져 시간당 $0.441, 총 $20에 달하는 금액을 납부하는 참사가 발생했다…

profile
개발을 공부하며 깊게 고민했던 트러블슈팅 과정을 공유하고자 합니다.

1개의 댓글

comment-user-thumbnail
2023년 8월 22일

감사합니다!

답글 달기