Table of Contents
Creating projects
GCP를 할 때 가장 먼저 해야할 일은 바로 프로젝트를 설정하는 것이다.

- Project name은 내가 만들 수도 있고, 고유하지 않아도 되고, 바꿀 수도 있다. 사용자 입장에서 제일 편함.
- Project ID는 내가 만들 수 있지만 GCP안에서 식별자로 쓰이기 때문에 전세계적으로 고유해야 하고, 변경이 불가하다.
- Project number은 구글이 만들고, 고유하며, 변경되지 않는다.
실질적으로 사용자 입장에선 Cloud Shell를 사용할 때, Project ID를 쓸 일이 제일 많다.
Resource hierarchy basics

새 조직 노드가 있으면 기본적으로 도메인의 모든 사용자가 프로젝트 및 결제 계정을 만들 수 있다. 그러나 팀에서 누가 그러한 일을 관리할 지 정하는 게 안전하다.
- 조직 관리자가 모든 클라우드 리소스에 대한 포괄적 제어
- 프로젝트 생성자는 담당한 프로젝트의 세분화된 생성 제어
그림을 예시로 들면,
- CEO : project 1, 2, 3, folderA, B 모두 포괄적으로 제어할 수 있다.
- Bob : 프로젝트3에 대하여 세밀한 제어 가능

GCP의 정책 상속
- 상위 정책이 리소스에 상속된다.
- 리소스 정책은 상위 리소스와 현재 리소스의 합집합이다.
- 정책이 리소스에 설정되며, 각 정책은 역할 및 역할 구성원 집합을 명시한다.
- 하위 리소스에 부여된 (하위 리소스 자체 권한 말고)상위 권한은 동일한 수준의 다른 시소스 또는 더 아래에 있는 하위 리소스에 의해 제거될 수 없다.
- 덜 엄격한 상위 정책이 더 엄격한 리소스 정책을 재정의(override)한다.
Assigning users to pre-defined IAM roles within a project
IAM을 정의하는 요소
- 누가
- 구글 계정
- 서비스 계정
- Google Group
- G suite 도메인 or Cloud ID
- 무엇을
- 어느 리소스에
IAM의 세가지 유형
- Primary role
- 민감한 데이터를 다루는 여러 사람이 일하는 프로젝트에서는 너무나도 coarse하고 rough한 권한 설정(=위험하다)

- Pre-defined role
- 특정 리소스에서 미리 정의 된 역할들에는 해당 역할이 일반적으로 수행 할 작업에 따라 고유 한 맞춤 권한 목록이 있다.
- 예: Compute Engine(특정 리소스) InstanceOperator 역할(미리 정의된 역할)은 compute instance를 get, list, start, stop 작업(일반적으로 수행할 작업)할 수 있다.
- 특정 리소스에서 미리 정의 된 역할들에는 해당 역할이 일반적으로 수행 할 작업에 따라 고유 한 맞춤 권한 목록이 있다.
- Custom role
- Custom role은 사용자가 정의하며 지원되는 권한을 사용자의 필요에 맞도록 하나 이상 결합할 수 있다.
- Custom role은 Google에서 관리하지 않는다. 즉, GCP에 새로운 권한, 기능, 서비스가 추가되어도 Custom role은 자동으로 업데이트되지 않는다.
- 조직, 프로젝트 수준에서는 Custom role을 만들 수 있으나, 폴더 수준에서는 Custom role을 못 만든다.
- Custom role의 ID는 고유해야 한다.
- GCP 콘솔에 표시되는 것은 역할 이름이다. 따라서 Custom role에는 조직 수준인지 프로젝트 수준인지 파악할 수 있는 정보를 포함하는 게 좋다.
이렇게 권한 정책을 세밀하게 두는 이유는?
- 사람이 실수로, 또는 고의적으로 리소스를 손상하지 못하도록
- 보안 규정 위반을 방지하도록
Managing users in Cloud Identity (manually and automated)
- 신규 GCP 고객들은 Gmail 계정으로 GCP 콘솔에 로그인 하여 시작한다.
- 시작하긴 쉬운데 팀의 ID를 중앙에서 관리하지 않는다는 단점 있음
- 팀을 떠난 사람에게 접근 권한을 즉시 제거해야하는 방법이 필요함
- G suite
- G suite 는 GCP 정책을 정의할 수 있다.
- 이렇게 하면 팀을 떠난 사람에게 접근 권한을 즉시 제거할 수 있다.
- Cloud Identity
- G suite 안 써도 Cloud Identity 쓰면 동일하게 그룹 관리 가능하다
- G suite의 공동 작업 제품에 대한 비용은 지불하지 않음
Enabling APIs within projects
GCP 리소스와 서비스와 상호작용할 수 있는 4가지 방법
- GUI 환경의 콘솔
- CLI 환경의 Cloud shell, Cloud SDK
- 모바일 App
- REST-based API
모바일 App
- 가상 머신 및 데이터베이스 인스턴스 관리
- Google App Engine에서 앱 관리
- 결제 관리
- 맞춤 설정 가능한 대시보드로 프로젝트 시각화
REST-based API
- GCP 서비스는 API를 제공하므로 사용자는 제품 및 서비스에 프로그래머틱 액세스가 가능하다
- 일반적으로 JSON을 교환 형식으로 사용
- 인증 및 승인에 OAuth 2.0 사용
- GCP console을 통해 사용 설정
- 지출을 관리할 수 있도록 대부분의 API에 일일 할당량 및 요금(한도)가 적용됨
- 요청에 따라 할당량 및 요금 상향 조정 가능
- GUI 콘솔에서 사용하는 것과 거의 동일하게 코드로 GCP사용 가능
코드 작성시 유용한 API Explorer
- API Explorer은 사용자가 브라우저에서 쉽게 API를 사용할 수 있게 해주는 대화형 도구.
- API Explorer 가 할 수 있는 것들
- 사용 가능한 API와 버전을 신속하게 검색
- 각 API에서 사용 가능한 메서드 및 지원되는 매개변수를 인라인 문서로 확인
- 실시간으로 각 메소드에 request를 실행하고 응답 확인
- 인증되고 승인 된 API를 쉽게 호출
클라이언트 라이브러리를 사용해 코드로 GCP 리소스 관리하기
Client Library엔 두종류가 있다.
- Cloud Client Library
- Google Cloud의 최신 API 권장 라이브러리
- 커뮤니티에서 소유하며 직접 개발한 클라이언트 라이브러리
- Google API Client Library
- Cloud Client Library가 최신 기능을 지원하지 않을 경우 쓸 수 있는 라이브러리
- generality와 completeness를 위하여 설계된 라이브러리다.
- 오픈 소스
- 자동 생성
- 다양한 언어 지원
- Java, Python, JavaScript, PHP, .NET, GO, Node.js, Ruby, Dart
Provisioning one or more Stackdriver workspaces
Stackdriver는 메트릭, 로그 및 이벤트를 집계하는 멀티 클라우드 모니터링 및 관리 서비스.
Stackdriver의 기능
- 통합 모니터링, 로깅, 진단
- 여러 플랫폼들의 리소스를 관리
- GCP
- AWS
- on-premises
- 개발자, 운영자 및 보안 전문가에게 근본 원인 분석 속도와 평균 해결 시간(MTTR)을 단축하는 일련의 관찰 가능한 신호를 제공
Built-in monitoring
많은 GCP 서비스에는 Stackdriver monitoring 통합 기능이 이미 내장되어 있다.
- Compute Engine
- App Engine
- Kubernetes Engine
- Cloud SQL
- Datastore
- BigQuery
- Networking
- Pub/Sub
- 등등..
Stackdriver logs
- Stackdriver은 log을 제한된 기간 동안 저장한다.
- 제한된 기간은 log의 종류에 따라 다르다.
- Admin Activity audit log은 400일 동안 보관된다.
- Data Access audit log은 30일동안만 보관된다.
- 분석과 더 긴 보관을 위해 log을 export 할 수 있다.