Setting up cloud projects and accounts

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 할 수 있다.

Stackdriver? 백문이 불여일타!

Stackdriver Qwiklabs

---