[GCP공부] Coursera: Google Cloud Platform Fundamentals: Core Infrastructure - Getting Started with Google Cloud Platform

Introduction

프로젝트를 조직화하고 관리하기 위해서 Google Cloud Identity and Access Management 를 사용해야 합니다.(IAM, IM)

The principle of least privilege is very important

This principle says that each user should have only those privileges needed to do their jobs.

In a least-privilege environment, people are protected from an entire class of errors. 

A coworker of mine once accidentally deleted a running production database. 

Why? Because he was working as the root user on the system when he shouldn't have been.

GCP customers use IM to implement least privilege

 

GCP's management layer

There are four way to interact with GCP's management layer 

- web-based console

- sdk command-line tools 이거 두개만 쓸꺼임

- APIs

- mobile app

 

예전에 클라우드 없었을때는 (on-premises시절) 에는 보안의 모든것을 책임져야만 했다.

From the physical security of the hardware, and the premises in which they're housed, through the encrption of the data on disk, the integrity of your network, all the way up to securing the content stored in those applications.

근데 구글은 

Layers

 

 

When you move an application to Google Cloud Platform, Google handles many of the lower layers of security. 

Because of its scale, Google can deliver a higher level of security at these layers than most of its customers could afford to do on their own. 

The upper layers of the security stack remain the customers' responsibility. 

Google provides tools such as IAM to help customers implement the policies they choose at these layers.

The Google Cloud Platform resource hierarchy

모든 리소스는 '프로젝트' 안에서 관리된다.

프로젝트는 폴더에 담을수 있고, 폴더도 폴더에 담을수 있고 

All the folders and projects used by your organization can be brought together under an organization node.

여기에는 다 정책이 적용된다. (예외가 있음 ex ) cloud storage buckets)

remember that policies are inherited downwards in the hierarchy.

 

Projects can have different owners and users - 

they're built separately and they're managed separately.

projectId: unique

projectName: 내맘대로

proejctNumber: unique -> 이건 이번에 배우는 범위에 없음

 

So, if project three and four are administered by the same team by design, 

you can put IAM policies into folder B instead.

 

Doing it the other way, putting duplicate copies of those policies on project three and project four would be tedious and error prone. 상식이지만 난 이런거 설명해주는게 좋음

 

organization node는 G Suite customer면 자동으로 생기고 아니면 Google Cloud Identity로 만들어줘야함

organization node 있으면 할수있는거 

1. you can designate an organization policy administrator so that only people with privilege can change policies. 

2. You can also assign a project creator role, which is a great way to control who can spend money.

 

하여튼 organization node를 만들면 

When you get a new organization node, it lets anyone in the domain create projects and billing accounts just as they could before. That's to avoid surprises and disruption. But it'd be a great first step with a new organization node to decide who on your team should really be able to do those things. 

이게 먼말이지;; resource는 우리 팀이면 다 만들수 있다고 하는것 같음 그러니 정하는게 좋을것 같음

 

if you set a policy at the organization level, it is automatically inherited by all its children projects. 

And this inheritance is transitive, which means that all the resources in those projects inherit the policy too

 

The policies implemented at a higher level in this hierarchy can't take away access that's granted at a lower level.

권한을 뺐는다는게.. ㅇㅇ

uppose that a policy applied on 

the bookshelf project gives user Pat the right to modify a cloud storage bucket, 

but a policy at the organization level says that Pat can only 

view cloud storage buckets not change them. 

The more generous policy is the one that takes effect. 

Keep this in mind as you design your policies. 

Identity and Access Management (IAM)

IAM lets administrators authorize who can take action on specific resources.

An IAM role is a collection of permissions.

For example, to manage instances in a project, you need to create, delete, start, stop, and change an instance.

So the permissions are grouped together into a role that makes them easier to manage.

롤은 퍼미션의 묶음이라고 생각하고 읽자.

 

Cloud IAM에는 3가지 종류의 role이 있다. 

- Primitive roles: you apply them to a GCP project and they affect all resources in that project. 

- Custom roles: 좀더 세부적으로 할수있는 권한

- Predefined roles: 정해저 있는 롤

리소스가 권한을 줄수도 있음 특정 프로젝트에 아니면 특정 리소스에 big table이 그렇다함

 

IAM roles

Compute Engines InstanceAdmin Role 이거에 대해 설명함 (다시한번 상기: Role은 권한의 묶음)

이 롤을 부여한 사람들에게 어떤 action을 하게 함:  listing them, reading and changing their configurations, 

and starting and stopping them. 그리고 어느 리소스에 적용할지 선택하면 됨 .

 

그리고 least-previlige 규칙 따르는게 좋음

롤은 커스텀 해서 세세하게 설정하수도 있음, custom roles 라는걸 사용하면됨

주의사항 1: custom roles를 사용하기로 결정해야함 (회사에서!) 왜냐면 그냥 기존에 정해진 권한만 사용하길 원하는 회사가 있음

주의사항 2: custom roles 은 오직 project or organization levels에 만 사용가능해

 

사람이 아닌 Compute engine에 롤을 주고 싶으면 어떻게 할까? 

예를 들어 내 Compute engine만 Cloud storage에 접근하게 하고 싶어. (다른서비스랑 다른 유저들은 접근 못하게 하고 싶어)

Then you would use a service account.

 

서비스 어카운트를 만들어서 내 compute engine -> cloud storage 를 인증하면 됨

서비스 어카운트의 이름은 email address 로 해야함 비번은 안쓰고 cryptographics keys 를 사용한다고 함 to access resources

 

예를 들어 service account has been grated compute Engine's InstanceAdmin Role.

적용하고 싶은롤에 Service Account 만들어서 -> 리소스에 할당하면 됨

ex) 엘리스(사람이)는 Service Account 에서 어떤 행동을 할수있는지 관리하고 싶어해

밥은 그냥 Service Account 에서 어떤 행동이 있는지 확인(Just view)만 하고 싶음

근데 Service Account 또한 리소스여서 it can have IAM policies on its own.

그래서 이전에 했던것 처럼 엘리스는 에디터 롤을 주면되고 밥은 뷰어롤을 주면 됨

위의 그림에서 서비스 어카운트가 없다고 생각하고 보자

프로젝트 b에 접근하고 싶다. 그러면 프로젝트에 있는 모든 resource (즉, compute engine)에  Service Account 를 줘서 프로젝트에 접근하게 하면 된다. 근데 이렇게하면 잠재적인 위험이 있으니 필요한 부분만 권한을 줘보자

 

비슷한 기능을하는 compute engine 들끼리 묶어서 component_1, component_2 라고 하기로 하자

근데 component_1 만 project b에 접근하게 하고 싶어 이럴때 component_1만 Service Account 1를 사용해서 Editor 권한을 주면 된다. component_2는 걍 뷰어권한 정도..

 

Ps. 문제풀면서 느낀거

organization node를 언제만드냐면, 폴더 사용할때, 정책 전반적으로 적용할때

Interacting with Google Cloud Platform

GCP와 상호작용하는 방법은 4가지 있습니다.

- console:  It lets you view and manage all your projects and all the resources they use. It also lets you enable, disable and explore the APIs of GCP services. And it gives you access to Cloud Shell

- sdk and cloud shell:  That's a command-line interface to GCP that's easily accessed from your browser. From Cloud Shell, you can use the tools(ex. gcloud, gsutil, bq) provided by the Google Cloud Software Development kit 

SDK, sdk make you can use to manage your resources and your applications on GCP.

- mobile app: 리소스확인하고 대쉬보드만들고 .. 별거아님

- APIs: 구글 서비스들이 API를 제공함. 그럼 내 코드로 컨트롤 할수 있음 (JSON) Many APIs are off by default, 

and many are associated with quotas and limits. These restrictions help protect you from using resources inadvertently. 

만들때 어떤 API 가 있고 어떤것이 사용가능하지 보려면 console에서 APIs Explorer 를 사용해서 알수있음 (rest swagger 같은 것 같음) 코드를 다 짜기 또 힘들까봐 라이브러리도 제공해줌(Cloud Client LIbrary-> 최신꺼없을수도 , Google API Client Library-> 여기서 내가 짜면됨)

Cloud Marketplace (formerly Cloud Launcher)

create react app 처럼 이것도 Google Cloud Launcher 가 있다.  함수형 소프트웨어 패키지를 빠르게 배포해준다. 

 compute instances, storage, network setting 자동으로 해준다. 근데 배포전엔 수정을 해줘야한다. 특별히 더 붙는 가격은 없고, 일반 인스턴스 비용이랑 똑같다. 근데 third part commercially licensed software 가 붙으면 추가 비용이 붙을수 있다. 근데 이것들 다 시작전에 예상금액이 보여주니다. 확인하자 . 예상금액은 '예상'일 뿐이다. 기본적인 이미지가 업데이트되면 deployed systems에서 maintain them 해주면 됨

 

동영상에서 LAMP stack 배포하는거 보여줌. (별거없음)  (퀵랩으로 해봄)

퀴즈도 품 모듈 1끝