AWS IAM 파헤치기 - 역할과 정책, 신뢰관계

 

단일 AWS의 리소스를 사용할 때는 몰랐던 것들이 있다.

(루트 사용자로서 EC2만 하나 덜렁 사용할 때는 다른것들을 고려할 필요가 없었다.)

 

AWS 리소스가 다른 AWS 리소스를 사용하려면, 리소스를 사용할 수 있다는 것을 명시해야 한다는 것이다.

 

그리고 AWS에서는 루트 사용자로 AWS 리소스 접근을 권장하지 않는다.

 

AWS 사용자 별로 역할을 부여해 AWS 리소스에 대한 권한을 주고 사용하길 권장한다.

(실수 방지, 모니터링 등 많은 이유가 있다)

 

이 두 가지는 IAM(AWS Identity and Access Management)이라는 이름으로 관리된다.

 

해당 페이지에 진입해보면 생소한 내용이 많은데, 하나씩 알아보자.

 

IAM 이란?

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

 

AWS IAM 페이지에서는 IAM을 위와 같이 설명하고 있다.

https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/introduction.html

 

IAM은 우측 상단에 메뉴에 보안 자격 증명 메뉴를 통해 설정할 수 있다.

페이지에 진입해보면 어려운 이야기가 많은데, 액세스 관리 탭에서 지정할 수 있다.

 

IAM 사용자 그룹과/사용자(User Group/User)

 

조직에 새인원이 들어오면 IAM 사용자를 만들어주고, 역할을 부여해줘야한다.

 

IAM 역할 지정을 하기 위해서는 가장 먼저 사용자를 만들어줘야 한다.

 

사용자와 그룹 생성은 그냥 만들면되니까 따로 다루진 않겠다.

 

사용자를 만들 때, 정책 지정을 할 수 있는데 이 부분만 잘 기억해두자.

 

 

사용자 그룹은 같은 권한을 갖는 IAM 사용자의 묶음이다.

 

사용자에 사용자 그룹을 지정해 생성하면, 아래의 그림과 같이 정리된다.

 

 

그림에는 사용자 별로 하나의 정책만 사용하는 것 같지만, 사용자는 다양한 정책들을 가지게끔 설정할 수도 있다. 

 

위 그림에서 정책(policy)이 권한의 묶음이다.

 

정책(Policy)

정책 탭에 들어가보면, AWS에서 제공하고 있는 기본 정책들을 확인할 수 있다.

 

 

정책 하나를 열어보면, json으로 정리되있는 권한들을 확인할 수 있다.

 

 

Statement 아래에 Action, Effect, Resource에 대한 정보들이 있다.

 

Action은 어떤 동작을 허용할 것인지, Effect는 Allow, Deny 허용/거부를 나타내고, Resource는 어떤 리소스가 이 권한을 사용할 수 있을지를 나타낸다.

 

하나의 {}가 하나의 권한을 나타낸다.

 

곧 정책 = 권한의 묶음이 된다.

 

 

그런데, 여러 서비스를 이용하는 사용자나 AWS 리소스에 권한들을 하나씩 지정해주는건 굉장히 번거로운 일이다.

 

그래서 AWS에서는 다양한 권한의 묶음을 기본 정책으로 제공하는데,

 

내가 찾는 정책이 없을 수 있기 때문에, 커스텀하게 권한을 설정할 수 있는 커스텀 정책을 제공한다.

 

노랑색 네모 상자가 없는게 커스텀 정책이다.

 

 

커스텀 정책을 만드는 방법은, 별로 어려운 과정이 아니니 이 내용 역시 따로 다루진 않겠다.

 

여기까지는 사용자가 AWS 리소스에게 접근할 수 있는 권한을 지정하는 것과 이를 관리하기 위한 정책과

 

같은 정책을 갖는 사용자를 묶은 사용자 그룹에 대해서 알아 봤다.

 

하지만 처음 언급했던 내용 중 하나가 더 남았는데, AWS 리소스가 다른 AWS 리소스에 접근을 허용하는 방법이다.

 

이 제약 조건은 역할과 신뢰관계로 지정할 수 있다. 

 

역할과 신뢰관계

AWS 리소스에서 다른 AWS 리소스에 접근하려면 역할과 신뢰관계가 필요하다.

(하나의 리소스만 사용할 경우에는 필요 없음)

 

이전에 API Gateway - Lambda - DDB를 연동할 때를 보면, 따로 언급하진 않았지만,

 

이때도 Lambda에서 DDB를 허용한다는 역할이 생성됐다.

(serverless에서 자동으로 만들어 준 듯하다)

 

 

권한을 열어보면, log(cloud watch)와 ddb의 권한을 열어준 것을 확인할 수 있다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "logs:CreateLogStream",
                "logs:CreateLogGroup",
                "logs:TagResource"
            ],
            "Resource": [
                "arn:aws:logs:ap-northeast-2:301591718339:log-group:/aws/lambda/apigw-lambda-dev*:*"
            ],
            "Effect": "Allow"
        },
        {
            "Action": [
                "logs:PutLogEvents"
            ],
            "Resource": [
                "arn:aws:logs:ap-northeast-2:301591718339:log-group:/aws/lambda/apigw-lambda-dev*:*:*"
            ],
            "Effect": "Allow"
        },
        {
            "Action": [
                "dynamodb:*"
            ],
            "Resource": "arn:aws:dynamodb:ap-northeast-2:301591718339:table/serverless-ddb-dev",
            "Effect": "Allow"
        }
    ]
}

역할에는 신뢰관계라는 제약조건이 추가되었는데,

 

신뢰관계는 특정 엔티티(AWS Resource, 계정 등)가 역할을 맡을 수 있는지를 정의 한다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "lambda.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

이 역할은 람다에만 지정할 수 있어요!! 란 뜻이다.

 

AssumeRole은 내가 제대로 이해한건지는 모르겠는데,

 

현재 AWS 리소스의 IAM 사용자의 자격증명을 가져와 사용하겠다는 의미인 것 같다.

 

역할/신뢰관계를 정리하면 아래와 같다.

 

 

역할은 정책과 신뢰관계의 묶음이고, 정책과 신뢰관계도 커스텀하게 만들 수 있다. 

 

정확히는 신뢰관계는 JSON 파일을 수정해서  AWS 리소스를 사용할 수 있게 지정할 수 있다.

 

각각의 세부 옵션들이 많은데 거기까지 다루기엔 너무 깊이 들어갈 것 같아 이정도로 마쳐야할 것 같다.

 

마치며

IAM은 terraform을 사용하기 전에 반드시 알아야 할 것 같아서 한번 정리해봤다.

 

실습도 할 수 있겠지만, 거기까지 따로 진행하진 않았다. 그리고 딥하게 들어가면 너무 어려워지긴 하는 것 같다.

 

다음 글들은 아마 AWS 리소스에 대한 내용을 정리하면서 terraform을 작성하지 않을까 싶다.

 

 

참고자료

https://jonnung.dev/posts/2021-01-28-aws-iam-role/#gsc.tab=0