들어가며
위에 실습들을 진행하며 권한 때문에 오류가 나고 권한설정을 하는것이 어려움이 있어 권한을 이해하려고 IAM 권한 정책에 대해 간단하게 실습하고 알아볼 예정이다.
IAM 구성요소
IAM 기본 구성요소
-
IAM USER
AWS 콘솔/CLI에 로그인하는 개별 주체이다. 자체적으로 정책을 가질 수도 있고 그룹 소속으로도 권한을 받을 수 있다. -
IAM Group
여러 USER들을 묶어 그룹 정책을 붙여서 일괄적으로 부여하는 용도이다. User는 여러 그룹에 동시에 속할 수 있다. -
IAM policy
Action을 어떤 Resouce에 허용/거부할지 JSON 으로 표현한것이다. -
Effect : Allow or Deny
정책은 User/Group/Role에 붙일 수 있다.
정책 종류
-
관리형 정책(Managed Policy)
AWS 가 제공하거나 사용자가 만들어서 재사용 가능한 정책이다. 여러 대상에 반복 적용하기에 좋다. -
인라인정책
특정 대상에만 종속되는 정책으로 예외처리/강제 제약과 같은 목적에서 사용된다.
권한 평가 로직
AWS는 요청이 들어오면 허용할지 거부할지를 최종적으로 결정하는데 이때는 아래의 규칙을 따른다.
1. 기본은 거부이다. -> 아무 정책도 없으면 거부한다.
2. 명시적 거부가 있으면 무조건 거부이다. -> Allow가 있어도 Deny가 우선 시
3. Deny가 없고 Allow 만 있으면 허용한다.
권한 경계(Permission Boundary)
권한 경계는 IAM 사용자(User) 또는 역할(Role)에 대해 최대 허용 가능한 권한의 상한선을 정하는 기능이다.
권한 경계는 Deny 처럼 막는것이 아닌 권한 평가 로직에서 Allow 가 나와도 그 Allow 가 경계 안에 있어야 최종 허용되는 구조이다.
결국엔 최종 허용 = (유저/그룹/역할 정책이 허용) AND (권한 경계도 허용)
실습
사용자 생성
IAM -> 사용자 -> 사용자 생성
admin 사용자 생성 (기본적으로 권한은 따로 지정 x)
사용자 그룹 생성
amdin group 생성 (그룹에는 AdministratorAccess 권한 추가)
이때 AdministratorAccess 권한은 AWS에서 제공하는 관리자급 관리형 정책이다.
거의 모든 AWS 서비스에 대해 모든 작업을 허용한다.
사용자 추가 (dev, infra)
dev, infra 사용자 생성 (기본적으로 권한은 따로 지정 x)
사용자 그룹 생성
dev group 생성 (그룹에는 ReadOnlyAccess 권한 추가)
ReadOnlyAccess 권한은 AWS 서비스와 리소스에 대해 읽기 전용 권한을 묶어둔 정책이다.
inframanager group 생성 (그룹에는 PowerUserAccess 권한 추가)
PowerUserAccess는 AWS가 제공하는 관리형 정책 (AWS managed policy) 중 하나로 공식 문서를 확인하면 IAM / Organizations / Account 관련 액션만 빼고는 전부 허용한다.
dev 계정에서 권한 확인
dev 계정에서 로그인
IAM 유저에는 개인 권한 X, 그룹 권한 (ReadOnly) 즉 조회는 가능하지만 쓰기는 안된다.
하지만 infra 계정에서 로그인해보면
써지는것을 볼 수 있다. IAM 유저에는 개인 권한 X, 그룹 권한(PowerUserAccess)
즉 위에 실습을 통해 개인권한이 없어도 특정 그룹권한으로 실행할 수 있는것을 볼 수있다.
인라인정책
인라인정책은 특정 권한은 Deny 하기 위해 사용한다. 실습을 통해 확인해보면
dev group
IAM 권한 제거 정책을 인라인을 넣고 확인해보면
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyAllIAMActions",
"Effect": "Deny",
"Action": "iam:*",
"Resource": "*"
}
]
}
아래와 같이 원래있던 ReadOnly 권한도 사라진것을 볼 수 있다.
만약 인라인 정책을 삭제하고 확인해보면
다시 접근이 가능한것을 볼 수 있다.
infra 유저에 권한 경계 설정
IAM -> 사용자 -> 권한 경계 설정
원래 infra 유저가 속한 inframanger 그룹은 PowerUserAccess 이지만 권한 경계를 통해 ReadOnlyAccess를 추가해주면 infra 유저는 ReadOnly 만 가능하다.
infra 유저로 로그인해서 확인하면
엑서스가 거부되는것을 볼 수 있다.
role switch
role switch란 권한을 잠깐 빌려쓰는것이다. STS 라는 임시 자격증명을 사용한다.
IAM -> 역할 ->역할 생성
AWS 계정으로 생성
AdministratorAccess 권한
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::593927188341:root",
"arn:aws:iam::593927188341:user/lab-edu-user-dev"
]
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}
같은 AWS 계정(593927188341) 안의 root(=그 계정 전체)와 특정 사용자 lab-edu-user-dev(dev)가 이 Role을 sts:AssumeRole로 맡을 수 있게 허용한다.
lab-edu-role → 신뢰관계 → 신뢰 정책 편집 (임시로 dev 에게 access 권한을 준다)
dev 로그인 → 역할 전환
IAM Account ID 와 ROLE NAME 을 넣어주면
기존에는 dev 는 ReadOnly 이지만 임시적으로 AdministratorAccess 을 부여받는다.
확인해보면
가능한것을 볼 수 있다.
마무리
이번 실습에서는 간단한 권한 정책과 범위에 대해 공부하였다. 이러한 권한 정책들을 어디까지 허용하고 누구한테 허용할지에 대한 감을 잡는것이 중요한거같다. 권한을 너무 넓게 줘도 문제가 생길 수 있고 너무 작게 줘도 불편할것같다. 실습을 통해 흐름을 공부했으니 나중엔 실전으로 직접 권한을 지정해서 프로젝트를 진행하며 적절한 권한을 찾는것을 공부할것이다.
