[Google Cloud Platform 기초] 리소스 상속과 IAM

1. GCP management layer와 상호작용하는 법

Web-based console (SDK) / Command-line / API / Mobile app 

 

고객인 개인의 on-premises 인프라 applicaiton을 개발하면, 전체 보안 stack을 책임져야 합니다. 물리적인 하드웨어부터, prmises가 위치한 곳, 디스크 데이터의 암호화, 네트워크 무결성과 같은 application에 저장되는 content의 보안을 생각해야 합니다. 반면에 GCP로 application을 옮기게 되면, 낮은 계층의 보안을 신경 쓰지 않아도 되며, 더 높은 계층의 보안은 사용자가 해결해야 합니다. 이를 돕기 위한 Google Cloud Identity and Access Management (IM, IAM)을 제공합니다.

 

2. Resource hierarchy

프로젝트와 폴더는 사용자의 organization node에 위치하게 됩니다. Policy는 프로젝트, 폴더, organization node에 모두 존재할 수 있으며 cloud storage bucket과 같은 개별적인 리소스에도 놓을 수 있습니다. Policy는 하위계층으로 상속됩니다.

 

프로젝트는 GCP 서비스를 사용하는 기준입니다. 각 프로젝트는 분리되어 있으며 각 리소스에 하나씩 속합니다. 각 GCP 프로젝트는 이름과 ID가 있습니다. 프로젝트 ID는 영구적이며 바꿀 수 없고 unique 해야 합니다. GCP에 어떤 프로젝트를  수행하고 싶은지 알리고 싶을 때 사용합니다. 프로젝트 이름은 사용자가 설정할 수 있습니다. GCP는 프로젝트마다 특정한 project number를 부여해 프로젝트를 언급할 때 사용합니다.

 

폴더는 각각 독립적으로 운영할 수 있도록 관리자 권한을 위임합니다. 폴더에 있는 리소스는 IAM policy를 폴더로부터 상속받습니다. 폴더 안의 리소스들에 각각 적용을 해도 되나, 번거롭고 오류가 날 확률이 높습니다. 폴더를 사용하려면 hierarchy의 top에 organization node가 필요합니다. Oragnization node는 중앙 가시성과 policy를 중앙에서 적용하는 역할을 합니다. G Suite 고객이라면 GCP 프로젝트가 자동적으로 orgaization node에 속하게 됩니다. 아니라면, IAM으로 생성하면 됩니다. 여러 Policy가 적용된다면, level이 높은 곳에 적용된 policy만 영향을 줍니다.

 

3. Identity and Access Management (IAM)

IAM은 특정 리소스에 누가 행동할 수 있는지 권한을 부여합니다. IAM은 3가지 part로 나뉘어 있습니다.

 

3.1 Who

'Who'는 사용자로 Google account, Google group, Service account, entire G Suite, Cloud Identity domain가 해당됩니다. 

 

3.2 Can do what

'Can do what'은 허가의 모임은 IAM의 role을 정의합니다. 대부분 하나 이상의 permission이 있습니다. Create, delete, start, stop 그리고 instance 변경이 그 예입니다. 그리하여 permission들을 하나의 그룹인 role로 만들면, 관리하기가 편리합니다. Role은 하나의 GCP 프로젝트에 적용되며 기본(primitive) role은 3가지가 있고, 조정도 가능합니다.

 

• Owner: Editor의 role + 관리 + 리소스에 대한 허가 + 청구 설정
• Editor: Viewer의 role + 상태 변경
• Viewer : 보기만 할 수 있고 변경하지 못함.

 

3.3 On which resource

'On which resource'는 role이 적용되는 리소스를 의미합니다.

 

4. IAM roles

Compute Engines InstanceAdmin Role은 가상 머신에 role을 수행합니다. listing, reading & changing configurations, starting & stopping이 있습니다. 

 

4.1 Custom role

Custom role 기본 role을 조정한 것입니다. Custom role은 project나 organization levels에서 사용할 수 있고, 폴더에서는 사용하지 못합니다. 몇몇 회사에서는 predefined role로 고정할지 cutom role을 적용할지 고려합니다.

 

4.2 Predefined role

Role이 적용되는 특정 서비스를 지정할 수 있습니다.

 

4.3 Service account

Service account는 사람대신 가상 머신에 permission을 부여합니다. 이메일로 지정되며 패스워드 대신 암호키를 사용하여 리소스에 접근합니다. 다른 VM에 대한 create, modify, delete 권한을 부여합니다. Service account도 일종의 리소스이며 IAM policy가 존재합니다. VM마다 다른 권한을 부여할 수 있고, VM 재생성하지 않고 service account의 permission을 변경할 수 있습니다. 첫 번째 service account만 다른 프로젝트에 대한 특권이 있어 코드를 잘못 작성하거나 취약한 가상 머신이 될 수 있는 영향을 줄입니다.