Setting up cloud projects and accounts

Creating projects

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

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

실질적으로 사용자 입장에선 Cloud Shell를 사용할 때, Project ID를 쓸 일이 제일 많다.

Resource hierarchy basics

GCP 는 계층 구조를 가지며 정책은 위에서 아래로 상속된다.
여성 CEO 😎

새 조직 노드가 있으면 기본적으로 도메인의 모든 사용자가 프로젝트 및 결제 계정을 만들 수 있다. 그러나 팀에서 누가 그러한 일을 관리할 지 정하는 게 안전하다.

  • 조직 관리자가 모든 클라우드 리소스에 대한 포괄적 제어
  • 프로젝트 생성자는 담당한 프로젝트의 세분화된 생성 제어

그림을 예시로 들면,

  • 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한 권한 설정(=위험하다)
GCP primary role
콘티 때 쓴 거 그냥 씀..
  • 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