스윗한 GCP IAM 입문 도우미

알고리마 백엔드 엔지니어 이상훈입니다. 이 문서는 GCP IAM 소개글입니다.

 

 

들어가며

 

안녕하십니까, 알고리마 백엔드 엔지니어 이상훈입니다.

 

이제 막 첫발을 내디딘 개발자라 할지라도 대부분 클라우드 서비스 근처에는 가보셨겠죠. 그런 다음 또 첫 관문으로 자연스레 IAM(혹은 이와 비스무리 한 것)을 만나 봤을 겁니다. 이 글의 주제입니다, IAM. 오늘은 그중에서도 GCP(Google Cloud Platform)의 IAM에 집중해 살펴볼 예정입니다.

 

1   GCP IAM

 

GCP의 IAM(Identity and Access Management, 신원 및 접근 관리). 간단히 정의부터 살펴보겠습니다.

 

사진 = Google Cloud Platform (https://cloud.google.com/iam)

 

IAM을 사용하면 특정 google cloud 리소스에 대한 세부 액세스 권한을 부여하고 다른 리소스에 대한 액세스를 방지할 수 있습니다. IAM은 최소 권한의 보안 원칙을 적용하여 실제로 필요한 것보다 더 많은 권한을 갖지 않도록 합니다.

(출처 Google Cloud IAM 문서)

 

말이 어렵네요. 쉽게 말하자면 클라우드 서비스에 접근하는 모든 것들의 권한을 관리하는 경비대장입니다. 권한을 가진 사람은 들여보내고 없는 사람들은 돌려보내는 일을 하죠. (가끔은, 사람이 아닌 것들이 접근할 때도 있습니다!)

 

사실 IAM은 오늘 알아볼 GCP뿐만 아니라 AWS, IBM Cloud 등 다양한 클라우드 서비스에서 운용되고 있습니다. 대부분 클라우드 서비스들에 접근하기 위해 알아야 할 핵심 보안 시스템 중 하나라는 이야기죠. 그렇다고 겁내지는 마세요. 초급자 과정입니다. 모든 개발자가 조금이라도 쉽게 GCP 첫걸음을 떼도록 도와주고 싶어서 쓰는 겁니다. 저 역시 기술 글은 처음이거든요. 초보와 초보, 딱이네요.

 

자 그럼 이제 GCP IAM은 왜 있는 것이며, 어떻게 쓰이는 건지, 봅시다.

 

IAM 메뉴판

 

GCP의 권한을 관리하는 서비스, 클라우드 서비스의 경비원, GCP IAM.

말은 참 쉽죠? 할 일도 그리 많지 않아 보입니다. 자신감 있게 들어갑니다. 메뉴판부터 볼까요.

 

정체를 알 수 없는 메뉴판. 맛없어 보이는 식당이네요.

 

허, 이게 무슨 말인가... 구성원은 뭐고 역할은 뭐지? 권한 주는 일에 종류는 왜 이리 많은 거야? 싶으신가요.

같이 알아볼게요. 다만 오늘 이 글에서는 저 모든 항목을 다루지 않을 겁니다. 꼭 알아야 할 기본적인 요소들만 설명할 예정입니다. 그러나 그것만으로도 기본 서비스 활용에는 충분합니다.

 

다만 본격적으로 설명하기에 앞서, 알아야 할 것이 있습니다. GCP의 resource hierarchy.

 

---

2   리소스 계층Resource Hierarchy

 

아래 사진을 보시죠. GCP의 리소스 계층을 정리한 사진입니다.

 

사진 = Google Cloud Blog

 

무난하네요. 그리 복잡해 보이지도, 간단해 보이지도 않습니다. 차근차근 짚어나가죠.

 

리소스Resource

 

맨 아래부터 먼저 볼게요. 이 표의 주인공, 리소스resource.

 

딱 봐도 감이 오시리라 믿습니다. 리소스는 GCP에서 우리가 빌려와 쓰고자 하는 서비스, 단어 뜻 그대로 자원들을 말합니다. 기본적인 예시로 compute engine, app engine 혹은 cloud storage가 있네요. 더 나아가면 cloud pub/sub, BigQuery 등등 자원들도 있을 테고요. 개발자들은 누구나 한 번쯤을 써봤을, 혹은 써볼 기능들이죠.

 

그럼 이런 리소스를 쓰려면 어떻게 해야 할까요? 그냥 쓴다고요? 안됩니다.

리소스는 단독으로 쓰일 수 없습니다. 이 기능 줘, 한다고 어떤 리소스든 마음대로 쓸 수는 없다는 말입니다. 필요한 건 프로젝트입니다.

 

프로젝트Project

 

자원들은 특정 프로젝트 아래에서만 사용할 수 있습니다. '63빌딩'처럼 원하는 "프로젝트"를 먼저 설정해야 '벽돌, 기왓장, 목수' 등 "필요한 것(리소스)"을 활용할 수 있습니다.

 

사진 = Google Cloud Blog

 

사진은 가장 간단한 형태의 리소스와 프로젝트의 관계입니다. 하나의 프로젝트가 여러 리소스를 포함하고 있죠.

우리는 이런 방식으로 프로젝트를 하나 생성하고 원하는 GCP 리소스를 사용해 개발을 진행할 수 있습니다.

 

폴더Folder와 조직Organization

 

한 단계 더 올라가기 전에, 사진 한 장만 더 불러오겠습니다. 마지막입니다.

 

사진 = Googblogs (https://url.kr/u1hxig )

처음 보여드렸던 사진과 유사합니다. 가운데 폴더 층을 제외하고는요. 폴더는 프로젝트를 묶음으로 관리하기 위한 계층입니다. 우리가 평소에 쓰는 폴더 혹은 디렉토리와 똑같아요. 이름도 똑같잖아요. 단, 폴더는 최상위 계층에 올 수 없습니다.

 

그 위에 있어야 하는 것. organization입니다. 사진에서는 Org Node라고 쓰여 있네요. 같은 의미입니다.

감이 잡히시리라 믿습니다. 딱 봐도 위잖아요. 그대로 번역하면 조직, 뭐 그런 건데, 일단 회사 혹은 단체에서 아래 계층의 모든 것을 관리하기 위해 있는 계층이라고 생각하시죠.

---

예시

계층 구조를 더 알기 쉽게 설명하기 위해 예시 두 가지를 만들어 보겠습니다.

 

1

먼저 개인 프로젝트를 하는 학생, 홍길동의 예시입니다.

 

홍길동 :

  아, 망함. 서버 호스팅 과제해야 하는데 서버를 어떻게 만들지?
  오, GCP에서 compute engine 인스턴스 빨리 하나 만들어서 시작해야겠다!
  와, 'My Project' 생성, 'my-compute-engine' 생성. 끝!

길동 님이 아, 오, 와 만으로 학교 과제를 끝내버렸습니다.

 

2

두 번째 예시입니다. AI 교육 플랫폼 개발사 알고리마에서 일하는 백엔드 엔지니어 이상훈 님의 예시입니다. 네, 접니다.

 

  우리 회사, 알고리마가 인공지능 교육 플랫폼과 코딩 교육 플랫폼, 인공지능 훈련 플랫폼을 개발한다고 해보죠.

  리소스들을 가져오기 위해 각 플랫폼을 프로젝트로 만들어야겠네요.

 

  그런데 언뜻 보니 인공지능 교육 플랫폼과 코딩 교육 플랫폼은 사용할 리소스가 비슷합니다. 그럼 우선 위에서 배운 대로 'Edu Platform' 이라는 폴더로 묶어버리겠습니다. 'Edu Platform' 폴더 아래에 'ai-edu-platform', 'coding-edu-platform' 프로젝트를 만듭시다.

  인공지능 훈련 플랫폼은 딱히 폴더에 넣을 필요가 없으니 'ai-training-platform' 프로젝트를 org node 바로 아래에 만들었습니다.

  가장 위에는 '우리 회사' organization이 있습니다. 프로젝트와 폴더를 모두 관장합니다.

 

발퀄 이해해주세요. 제가 만들었습니다.

 

회사를 위한 GCP 리소스 계층까지 만들어봤습니다. 제가 만든 예시지만, 이렇게 보니 정말 쉽고 친절하네요.

 

---

3   다시 IAM

 

본론으로 돌아왔습니다. 잠깐 알아보려고 했는데, 생각보다 조금 더 걸렸네요.

 

정책Policy

 

IAM은 어떤 면에서 간단하다고 볼 수도 있습니다. 이것만 알고 가면 되니까요.

 

Who, Can do what, On which resource

= 누가, 무슨 짓을 할 수 있나, 어떤 리소스에서.

 

예를 들면 이런 구조. "사용자 A, 읽기를 할 수 있다, storage를". 이렇게 한 선언들을 GCP IAM에서는 policy정책이라고 표현합니다. 경비원이 사람을 들여보내거나 내보낼 때 따라야 할 규칙이죠.

 

사진 = Google Cloud Platform

 

역할Role

 

저 문구에서 중요한 것은 "Can do what(무슨 짓을)"입니다.

 

can do what은 곧 IAM role(역할)이 됩니다. 사용자에게 권한을 주기 위해 부여하는 role은 종류를 보며 이해하면 쉽습니다. IAM role은 크게 3가지로 나뉩니다.

 

Primitive role: 광범위한 역할입니다. 하나의 프로젝트 안에 있는 모든 리소스에 적용됩니다.

어떤 프로젝트에서 'Lee'(네, 접니다)라는 사용자에게 primitive role 중 하나인 viewer role을 준다고 해봅시다. 이제 Lee는 프로젝트 안에 있는 모든 리소스를 볼 수 있습니다. primitive role의 힘이죠.

 

Predefined role: primitive role보다 섬세한 역할입니다. 사전에 정의한 자체 역할 셋을 활용해 권한을 어디까지 적용할 지 범위를 지정합니다. predefined role은 project, folder, organization node부터 DB 인스턴스까지 다양하게 범위를 지정할 수 있습니다.

 

Custom role: 사실은 말입니다. 어떤 사용자든 최소한의 권한만 주는 것이 안전하고 바람직합니다. 이를 위해 조직의 필요에 맞춰 권한 중에 필요한 것만 선택하여 사용하는 방식, custom role입니다. 단, 이 custom role은 folder 레벨에선 사용할 수 없습니다.

관대한 정책

우리는 각 리소스 계층별로 정책을 설정할 수 있습니다. 정책은 보통 상위 계층을 따릅니다. 다만 상위 계층과 하위 계층 간에 정책의 차이가 발생했을 때는 더 '관대한' 정책을 따르죠. 말로만 봐서는 아리송합니다. 예시를 들어보겠습니다.

 

예시

My Org라는 organization이 있습니다. 이 단계에서는 사용자 A에게 storage 읽기 권한만 부여했습니다. 그런데 My Org 아래 My Project라는 프로젝트에서는 사용자 A에게 storage 읽기 및 쓰기 권한까지 부여했습니다.

문제 : My Project에서 적용되는 사용자 A의 storage 권한은?

정답 : 읽기 및 쓰기 권한

 

읽기 및 쓰기 권한은 하위 계층에만 주어졌지만 더 관대하기 때문에, 이 정책을 따르는 거죠.

 

반대입니다. My Org에서 사용자 A에게 storage 읽기 및 쓰기 권한을 부여했습니다. My Project에는 storage 읽기 권한만 부여했죠.

문제 : My Project에서 적용되는 사용자 A의 storage 권한은?

정답 : (이것 또한) 읽기 및 쓰기 권한.

 

관대하니까요. GCP IAM은 관대한 정책을 좋아합니다.

 

---

리소스에도 권한을

 

IAM. 이제 좀 감이 잡히는 느낌이 듭니다. 이제 프로젝트를 만들고 코드를 짜봅시다.

 

...

음...

문제가 생겼습니다.

 

사용자에게 storage 권한을 주는 건 잘하겠습니다. 그런데 그것만으로는 충분하지 않습니다. 리소스를 더 잘 쓰고 싶다는 욕심. 그러려면 compute engine에서 실행되는 프로그램 역시 storage를 읽거나 쓰게 해야 하는 경우가 생깁니다.

즉, 리소스에 다른 리소스에 대한 권한이나 역할을 주고 싶은 겁니다. 어떻게 해야 할까요?

 

서비스 계정Service Account

 

123456-compute@developer.gserviceaccount.com이나 my-project@appspot.gserviceaccount.com같은, 내가 만든 적도 없는 낯선 이메일 주소. GCP 좀 만져보신 분들이라면 많이 봤을 법한 것입니다. 이것들이 바로 service account입니다. compute engine이나 app engine 같은 컴퓨팅 리소스들이 service account를 갖고 있습니다.

 

어려울 것 없습니다. 이 service account를 IAM 정책에서 "Who"에 대입하면 됩니다. 쉽게 말해 리소스가 가진 계정을 마치 사용자처럼 취급해 권한을 부여한다는 말입니다. 예시를 보시죠.

 

예시

상황 : My Project의 compute engine 리소스는 my-project@appspot.gserviceaccount.com라는 service account를 갖고 있습니다. storage에 저장된 이미지 파일을 가져오기 위해 이 리소스에 storage 읽기 권한을 주고 싶습니다.

정책 : my-project@appspot.gserviceaccount.com에게, 읽기 권한을 준다, storage의

결과 : My Project에 있는 compute engine들은 storage에서 자유롭게 데이터를 읽어올 수 있습니다.

 

이해하셨나요. 조금만 더 나아가 봅시다.

 

My Project라는 프로젝트가 하나 있다고 가정합시다. 이 프로젝트에서는 compute engine 리소스를 씁니다. 알차게 쓰기 위해 compute engine 인스턴스를 여러 개 만들었습니다. 이런, 인스턴스에 따라 권한을 다르게 주고 싶어졌습니다. 욕심이 끝이 없네요.

하지만 걸리는 게 있습니다. service account가 리소스에 할당되는 거라면, 인스턴스 각각에는 권한을 줄 수 없는 거 아닌가?

 

네, 답은 "줄 수 있다" 입니다. 별거 아닙니다.

 

service account를 여러 개 만들면 되는 거죠. service account는 프로젝트에 하나만 있는 것이 아니고 우리가 원하면 더 만들 수 있습니다. 그리고 리소스 인스턴스에 따라 service account를 할당해주면 완료입니다. (여기서 service account 역시 리소스입니다. 즉, service account에 대한 권한 또한 우리가 설정할 수 있습니다.)

 

---

4   마치며

 

사실 저 역시 GCP 초보라고 해도 이상할 것 없어요. 그래서 이렇게 안내 글을 쓰고 있자니 어색한 느낌이 가득했습니다.

 

그러나 분명 IAM 같은 초기 단계에서부터 어려움을 겪는 분들이 많지 않을까요. 과거의 제가 이 IAM을 앞에 두고 얼마나 헤맸는지 모르겠습니다. 더 큰 난관을 헤쳐 나가야 하는 모든 분들에게 도움이 되었으면 하는 바람을 담아 썼습니다.

우리 모두 GCP를 제집처럼 드나드는 개발자가 됩시다. IAM이 집의 현관문을 열어주는 열쇠 역할을 할 겁니다.

저는 다시 개발하고 공부하러 가보겠습니다. 긴 글 읽어주셔서 감사합니다.

 

 

---

 

<알고리마 채용> 알고리마에서는 '상훈'님과 함게 성장하며 AI 에듀테크 시장을 이끌어갈 개발자를 기다립니다. 

 

(이미지를 클릭해 보세요!)