[AWS] IAM - policy

오늘도 베하아~~

수 지 타 산 입니다

갑자기 날씨가 더워지면서 옷차림이 가벼워 지는 요즘이지만,

이럴 때일수록 감기 조심 하셔야 하는거 아시져!!??

 

그럼 저번 주에 이어서 오늘도 IAM에 대한 공부를 이어갈텐데요,

먼저 복습부터 하고 갈까요??

팔로팔로팔로미

 

---

 

IAM 이란 ? AWS 리소스에 대한 액세스를 안전하게 제어할 수 있는 웹 서비스입니다. IAM을 사용하여 리소스를 사용하도록 인증 및 권한 부여된 대상을 제어합니다.

 

계정을 처음 생성하는 경우에는 전체 AWS 서비스 및 계정 리소스에 대해 완전한 액세스 권한을 지닌 단일 로그인 자격 증명으로 시작합니다. 이 자격 증명은 AWS 계정 루트(ROOT) 사용자라고 하는데, 일상적인 작업, 심지어 관리 작업의 경우에도 루트 사용자를 사용하지 마실 것을 강력히 권장합니다.

 

---

 

이어서 오늘 공부 시작하겠습니다

 

 

Policy ? IAM 리소스 내에서 Policy는 AWS의 리소스에 대한 사용 권한을 부여하여 리소스에 액세스 접근을 막거나 허용할 수 있습니다. 이러한 Policy는 Entity에 적용합니다.

 

 

앞의 실습에서 저희는 사용자 그룹 생성 후, 그룹에 리소스 접근 권한을 선택을 해줬습니다. 리소스 사용에 대한 권한들을 "정책 혹은 policy"라고 지칭하며, 정책을 부여해준 그룹이 "entity" 임을 알아주시면 되겠습니다.

 

 

Entity

• User : IAM을 통해 IAM User를 생성할 수 있습니다. Role과 Policy로 사용자의 권한을 조정할 수 있습니다.
• Group : User의 집합입니다. Group단위로도 권한을 조정할 수 있습니다.
• Role : Policy의 집합입니다. 여러 개의 Policy를 합쳐 하나의 Role을 만들 수도 있고, 다른 Role과 Policy를 합쳐 하나의 Role로 만들 수도 있습니다.

 

Policy는 크게 3가지 유형으로 나뉩니다.

• Inline
• Managed
• Customer

 

Inline Policy

Inline Policy는 User나 Group 을 생성할때 직접 Policy를 심어주는 것을 말합니다. 중요한 점은 User, Group, Policy는 

1대1 관계여야 한다는 것입니다. 예를 들어 어떤 Policy를 한 User에 부여하게되면 그 Policy는 다른 User나 Group에 적용시킬 수 없게 됩니다. 꼭 하나의 Inline Policy는 하나의 개체에만 존재해야 합니다.

그리고 User나 Group을 삭제하면 Inline Policy도 같이 삭제됩니다.

 

Managed Policy

Managed Policy는 AWS에서 생성되고 관리되어집니다. 따라서 직접 Policy를 만들 필요가 없고 다수의 User와 Group에 적용 가능하지만 Managed Policy를 수정하는 것은 불가능합니다. 쉽게 말해, 이미 AWS 내에서 만들어진 정책입니다.

ex) AmazonDynamoDBFullAccess

 

Customer Policy

Customer Policy는 직접 새로 만드는 Policy를 뜻합니다. 기존에 존재하는 Managed Policy를 가져와서 필요한 부분을 넣고 불필요한 부분을 삭제해 개인의 입맛에 맞는 Policy를 구성할 수 있습니다.

Managed Policy에 원하는 Policy가 없다면 Customer Policy로 요구사항에 맞게 수정하고 사용하면 됩니다.

 

 

 

이렇게 3가지 Policy 종류에 대해 알아봤는데요. 사실 Inline Policy는 잘 사용되지 않고 Managed Policy에 원하는게 없을 경우 Customer Policy로 직접 만들어 사용하는 경우가 대부분입니다.

 

---

이론에 대해 공부했으니 , customer policy에 대한 실습을 해볼까요?

 

 

 

1. 먼저 AWS 콘솔에 접속한 후 IAM을 검색하여 클릭합니다.

 다음 왼쪽 메뉴에 Policies로 들어가 줍니다.

 

 

2. 그 다음 오른쪽 상단에 Create Policy를 클릭해 줍니다.

 

 

 

3. IAM Policy의 경우 JSON파일로 구성되어 있기 때문에 직접 커스터마이징 하기위해 Visual editor가 아닌 JSON을 선택해 줍니다.

 

 

 

여기서 잠깐! JSON을 통한 커스텀마이징을 위해 중요한 부분을 짚고 넘어가겠습니다

IAM Policy은 Version과 Statement로 나뉘고, Version 에는 두가지 버전이 존재합니다.

- 2012-10-17 : 현재 사용되는 버전이며, 항상 Version을 2012-10-17로 설정해야 합니다. 설정하지 않을 경우 policy variables등의 기능을 사용할 수 없습니다.
- 2008-10-17 : 이전 버전입니다. AWS는 이전 버전 사용을 권장하고 있지 않습니다. policy variables등의 기능을 지원하지 않고, ${aws:username} 과 같은 전역 조건 키도 변수로 인식되지 않고 문자열로 인식됩니다.

Statement는 Policy에서 가장 중요한 속성입니다.

Statement 속성으로 전체적인 Policy를 정의할 수 있으며, 한개 또는 각각을 구성요소를 지정해 줄 수 있습니다.

- Sid : statement ID로 각각의 Statement를 구분하는 구분자 역할을 합니다.
- Principal : 해당 Statement를 적용할 대상을 지정합니다.
- Resource : 대상이 사용할 리소스를 지정합니다.
- Action : 리소스에 대한 행동을 지정합니다.
- Effect : 리소스 접근의 허용 여부를 지정합니다. 기본적으로 리소스 접근은 거부(Deny)됩니다.
- Condition : 리소스 접근에 대해 조건을 지정합니다. (프로그래밍에서의 if문 같은 역할)

 

Policy의 구조에 대해 알았으니, 이제 직접 Policy를 커스터마이징 해봅시다.

조건은 다음과 같습니다.

 

EC2의 Tag중 owner tag의 값이 자신의 계정명으로 되어있는 EC2만 시작/정지/삭제 만 가능해야합니다.
owner tag의 값이 자신의 계정명과 다르다면 해당 EC2에 대한 작업은 모두 불가능해야합니다.

 

4. IAM editor에 다음과 같은 코드를 입력해줍니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ec2DescribeAll",
            "Effect": "Allow",
            "Action": [
                "ec2:Describe*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "ownEC2",
            "Effect": "Allow",
            "Action": [
                "ec2:StartInstances",
                "ec2:StopInstances",
                "ec2:TerminateInstances"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/owner": [
                        "${aws:username}"
                    ]
                }
            }
        }
    ]
}

 

 

 

 

-> ec2DescribeAll Statement는 IAM계정에서 다른 모든 계정의 EC2목록을 불러오기 위함입니다.

Resource를 전체("*")로 지정해 줌으로써 내 계정 뿐만아니라 다른 모든 계정의 EC2목록을 불러올 수 있습니다.

이는 Root계정에서 EC2를 생성하고 IAM계정으로 접속해 테스트하기위해 설정해 주었습니다.

 

-> ownEC2 Statement는 해당 Policy의 메인이 되는 Statement입니다. 

Action에서 다음과 같이 EC2에 대한 시작/정지/삭제 권한을 부여 하였습니다.

그리고 Resource의 경우 내 계정뿐만아니라 다른계정에서 생성한 EC2에도 접근은 할 수 있어야 하기에

전체("*")로 지정해 주었습니다.

 

-> Condition을 해석해보면 EC2의 Tag중 owner라는 이름을 가진 Tag의 값(aws:ResourceTag/owner)이 자신의 계정명(${aws:username})과 일치한다면(StringEqauls) 해당 Resource에 대한 Action을 허용하겠다 라는 뜻입니다.

 

 

 

 

5. 다 작성하셨다면 Next tags버튼을 눌러 다음으로 넘어가 줍니다.

별도의 태그는 지정해주지 않도록 하겠습니다

 

 

6. Name과 Description은 본인이 원하는 대로 작성한 후 Create policy 버튼을 눌러 정책을 생성해 줍니다.

 

 

7. 잘 생성된 것을 볼 수 있습니다.

 

 

 

 

만들어진 정책이 User에 권한이 잘 부여되는지 확인해보겠습니다.

 

 

 

 

8. IAM-1 에서 공부했던 그대로 User(유저)를 생성한 후, 다음과 같은 화면이 보이면 방금 생성한 Policy를 지정해 줍니다.

 

 

 

9. 태그는 건너뛰고 다음으로 와서 Create user 버튼을 눌러 IAM User를 생성해 줍니다.

 

 

 

10. 잘 생성된 것을 볼 수 있습니다.

 

---

정책(policy)을 커스텀마이징 하고, 유저(entity)에 적용하는 것 까지가

오늘 학습한 내용이었습니다.

루트 사용자에 대한 사용은 절대적으로 위험하기에

IAM 및 policy, role 들을 잘 활용하여

AWS 내 여러 리소스를 사용하는 것을 강력 추천합니다

그럼 다음 주에도 수 지 타 산 과 

함께해요

제에발~~~~