[GCP] Cloud IAM(Identity and Access Management)

• Cloud IAM : 구글 클라우드 서비스의 ID 및 액세스를 관리해주도록 하는 서비스. 즉, 누가(ID) 어떤 리소스(GCP서비스)에 대한 어떤 액세스 권한(Role)을 갖는지 제어하도록 해주는 것

Cloud IAM에서 정책(policy)를 만들면 IAM에서 사용하는 ID별로 역할을 주는데, 이것은 GCP 내의 리소스 별로 개별 설정이 가능하다.

Coud IAM

<Cloud IAM에서 사용하는 ID에는 크게 4가지가 있다.> 

1. 구글 계정 - 개별 사용자 계정, ID는 모든 이메일 주소로 가능.

2. 서비스 계정 - 애플리케이션 또는 가상 머신 속한 계정(사용자 X), 코드를 실행하는 계정을 지정 

                   - 주요 특징 => ID로 사용되며 서비스 계정에 역할을 부여하고 리소스에 엑세스 가능

                                        리소스로 사용되며 사용자에게 해당 서비스 계정에 엑세스할 권한 부여 가능

                   - 서비스 계정 키 => GCP에서 관리 or 사용자 관리

서비스 계정

3. 구글 그룹 = 여러 구글계정 + 서비스 계정 으로 이루어진 그룹. 전체 그룹을 동시에 엑세스 제어 가능

4. G Suite - 보통 회사 도메인에서 생성된 모든 구글 계정으로 구성된 가상 그룹

 

# 잠깐! 엑세스 관련 용어 개념을 정리하고 넘어가자!

• 리소스 : GCP 리소스에 대한 엑세스 권한 부여(GCP 리소스란, Compute engine 같은 GCP에서 제공하는 서비스들)
• 권한 : 리소스에 어떤 작업을 허용할지 결정
• 역할(=권한의 모음) : 사용자에게 직접 '권한'을 배정할 수 없기에 사용자에게 '역할'을 부여 가능(그러면 자동으로 포함된 권한들이 따라오게 됨)

<Cloud IAM 정책> : 사용자에게 부여되는 액세스 권한의 유형을 가지고 있는 리스트

정책은 역할(Role)별 해당 역할에 대한 권한을 가진 멤버 리스트(Members)로 구성되며 사용자가 리소스에 엑세스할 때,

이 정책을 통해서 엑세스 제어를 한다. 정책에 대해 도식화하면 다음과 같다.

 

정책(=Policy)----------------------------------------------------------

  Bindings(리소스별 역할을 가진 멤버 정의)

 

      역할(Role) : ex) Compute Engine 인스턴스 관리자

      멤버 목록(Members) : ex) 구글 계정, 구글 그룹, 서비스 계정..

-------------------------------------------------------------------------

 

<정책 계층 구조>

GCP리소스는 계층적으로 정리되어 있다. Organization Node는 계층구조의 루트노드이다. 그리고 폴더, 프로젝트, 리소스의 대소관계를 그려보면 다음과 같다.   [ 조직 노드 > 폴더 > 프로젝트 > 리소스 ]

리소스는 기본적으로 상위 리소스의 정책을 상속하기 때문에 상속된 계층은 상위 계층의 정책을 상속받는다. 즉, 폴더A에 프로젝트1, 프로젝트2 가 존재한다고 가정하면 폴더A에 정책을 만든다면 자동으로 프로젝트1,2에 똑같은 정책이 상속된다는 것이다. 그리고 리소스 계층 구조와 동일한 경로를 따르므로 리소스 계층 구조를 변경하면 정책 계층 구조도 변경이 된다. 마지막으로 주의할 것은 하위정책은 상위 수준에서 허용된 액세스 권한을 제한할 수가 없다. 다시말해서, 상위의 정책이 '야 하위야, 너 A라는 권한 할 수 없어' 라고 한다면 하위 정책에서는 군말없이 따라야 한다는 것이다..!

Organization Node

정책 계층 구조

<Cloud IAM의 역할>

1. 기본적 역할 : Owner, Editor, Viewer 권한이 있다.

   - Owner : 프로젝트 및 프로젝트 내 모든 리소스에 대한 역할 및 관리 가능

   - Editor : 변경 작업까지 가능

   - Viewer : 읽기 전용

2. 사전 정의된(predefined) 역할 : 기본역할보다 세부적인 액세스 제어를 부여하는 역할로, 구글에서 만들고 유지 및 관리 함. 따라서 GCP에서 새로운 기능이나 서비스가 추가될 때 같이 필요한 경우 자동으로 업데이트 됨

3. 커스텀 역할 : 2번 역할 이상의 세부적인 관리가 필요할 때 사용. 사용자가 직접 정의하며 하나 이상 결합 가능.

                     커스텀 역할을 만들기 위해선 소유자가 아닌 사용자에게는 '조직 역할 관리자' 역할이나 'IAM역할 관리자 역할'이 부여되어야 한다! ( 단, Organization/Project 수준에서는 커스텀역할을 만들 수 있지만 Folder수준에서는 불가!)

 

<Project란>

원래 Cloud IAM보다는 앞서 나오는 개념이지만 뒤늦게 정리를 한다. 모든 GCP서비스들은 사용자가 만든 project와 관련이 있다. 먼저 리소스를 추적하고 사용 한도량을 체크해주며 청구된 돈이 얼마인지 확인가능하다. 또한 허가와 credential(한국어로 뭐라써야할지 모르겠다..)을 관리하며 서비스와 API를 가능케 해준다.

Project의 기능

그리고 프로젝트는 3가지의 식별 속성들을 갖고 있다.

1. Project ID : 유니크(중복X)해야 하고 사용자가 선택할 수 있으며 한 번 정하면 수정이 불가하다.
2. Project name : 중복되도 상관이 없고 사용자가 선택할 수 있으며 수정이 가능하다.
3. Project number : 유니크(중복X)해야 하고 GCP가 정해주며 수정이 불가능하다.

Project 식별 속성

 

<QUIZ 오답>

오답문제<1>

문제가 루트노드인 조직 노드를 언제 선택해야 된다는 문제이다. 문제에 2개의 응답을 선택하라고 해서 했는데 하나는 맞고 하나는 틀렸다. 내가 오답으로 선택한 선택지는 조직노드에 상관 없이 리소스들은 항상 프로젝트에 정리가 된다.

답은 내가 제대로 선택한 '조직처럼 넓은 정책을 중앙에서 적용하도록 하고 싶을 때' 와 첫번째 선택지의

'When you want to create folders' 이다. 왜냐하면 폴더를 만들기 위해서는 무조건 조직노드가 필요하기 때문이다!!

 

헷갈렸던 문제<1>

다음은 내가 풀 때 헷갈렸던 문제이다.. 기본적인 문제일 수도 있었는데 은근 헷갈렸다. 문제에서 서비스와 API은 뭐에 근거하여 가능하냐 라고 물은건데... 순간 Billing account인가 생각했다..( 단순히 계정이 하나 생겨야 쓸 수있으니까 계정이 생길려면 돈을 내야하는....? 이 때 너무 주관적으로 생각하는 듯 싶었다...) 하지만 다시 정신차리고....강의내용에 근거해서 project를 선택했다. project를 만드는 순간 서비스와 API들은 따라온다..! 

 

오늘 2일차는 Cloud IAM 과 Project에 대해서 공부해 보았다. GCP한국어로 된 책이 도착했는데... 오늘 IAM강의내용을

영어로 듣다가 책 속 한국어 내용으로 된 IAM 내용을 보았는데 한국어가 확실히 이해가 잘 되긴 했다... 앞으로 코세라 강의 진도에 맞춰서 미리 책 속 해당 주제내용을 먼저 읽고 강의를 듣는게 훨씬 더 효율적일 거 같다. 다음 공부할 내용은 아마 VPC(Virtual Private Cloud) 네트워크에 대해서 공부할 예정이다!