Google Cloud Associate 강의 요약: IAM

IAM 이란?

• 사용자나 프로그램의 authentication 과 authorization를 제어함. 작업종류, 시간대, IP등을 제한할 수 있음.
• Role(permission)에 따른 policy(mapping) 함으로 써 결정됨
• 즉, 멤버하나하나에 바로 permission이 부여되는게 아니라, permission을 가진 role을 만들고 그 role을 각 멤버에게 부여함으로써 생김

Roles

• Role은 permissions이다,
• 기본적인 역할의 종류
  • 1. Basic roles
       • viewer: read
       • editor: read+ edit
       • owner: read+ edit+ manage+ billing
  • 2. predefined roles
       • 구글에 의해 미리 정의된 역할로 목적에 따라 다르다.
       • Cloud Storage role들, 이 넷은 기본적으로 resourcemanager.progects.get/list에 대한 권한을 가진다.
         1. storage admin
            • storage.buckets와 storage.objects에 대한 모든 권한
         2. storage object admin
            • storage.objects에 대한 모든 권한
         3. storage object creator
            • storage.objects.create
         4. storage object viewer
            • storage.objects.get
            • storage.objects.list
  • 3. custom roles
       • 자기가 새롭게 만든 역할

활용

• gcloud projects 나 gcloud iam 으로 명령어가 전개된다.
  • gcloud projects로 시작하는 것들
    • gcloud projects add-iam-policy-binding :IAM policy binding
    • gcloud projects get-iam-policy : Get IAM policy for a project
    • gcloud projects remove-iam-policy-binding :Remove IAM policy binding
    • gcloud projects set-iam-policy :Set the IAM policy
    • gcloud projects delete : Delete a project
      • gcloud iam
      • gcloud iam roles describe
      • gcloud iam roles create
      • gcloud iam roles copy
      • 그 외
      • gcloud compute project-info describe
      • gcloud auth info
      • gcloud auth revoke
      • gcloud auth list

서비스 계정

• cloud storage에 접근해야 하지만 personal credential을 허용하고 싶지는 않을때 씀
• 서비스 계정은 email주로 식별되며, 골뱅이 뒤에 developer.gserviceaccount.com이 붙음
• 비밀번호가 없음. 개인키 공용키만 할당됨. 그래서 브라우저나 쿠키로 로그인이 안되고, 컴퓨터에 할당된 계정임
• 서비스 계정의 종류
  • 1. default service account: 서비스가 사용될때 자동으로 만들어짐, 기본으로 editor role을 가지기에 추천하지 않음
  • 2. user managed: 유저가 생성함: 세밀하게 권한 제어 할 수 있어 추천됨
  • 3. google-managed service accounts: 구글에 의해 생성 관리됨, 우리는 신경 쓸 필요 없음 안중요함.

Use case

• 1. VM과 cloud storage 연결
     • 1. service account role 에 올바른 권한들 넣어 계정 만들기
     • 2. service account role을 VM에 할당하기.
     • 이때 구글 cloud-managed keys 사용되어 자동으로 편하게 다룰 수 있다. 즉 암호나 자격증명 파일 없이 접근할 수 있는 장점이 있다.
     • 그리고 인스턴스 작동중에 service account를 삭제해버리면 접근 권한을 잃을 수 있으니 삭제하지 말것
• 2. on prem(자체 서버)와 cloud storage 연결(long-lived)
     • service account를 prem에 바로 할당할 수는 없다.
     • 1. service 계정을 올바른 권한으로 만든다.
     • 2. service accoint user managed key를 생성한다.
          • 명령어 gcloud iam service-accounts keys create 를 통해 key를 만들고 service account key file을 다운로드 한다.
     • 3. 환경 변수로 계정을 key file에 적용한다.
     • 4. 구글 클라이언트 라이브러리는 ADC(application default credentials) 를 기본 자격증명으로 제공하는데 이게 환경변수의 key file에 적용하는데 도움이 된다.
• 3. on prem(자체 서버)와 google cloud APIs 연결(short lived)
     • 잠깐만 사용할거라 오히려 장기간용 key쓰면 나중에 보안상 위협이 됨.
     • 이런 경우 OAuth 2.0 access tokens, OpenId connect ID tokens, self-signed Json Web Tokens(JWTs) 를 사용할 수 있다.

시나리오

• Q: VM 응용 프로그램이 cloud storage bucket과 통신하길 바랍니다.
• A: VM을 사용하기 위해 올바른 권한들을 넣은 service account를 구성하세요
• Q: 서비스 계정은 identity인가요 resource 인가요?
• A: 둘다임. 서비스 계정을 규칙으로 첨부 가능(identitiy) 그리고 다른 맴버들도 서비스 계정에 역할을 부여 함으로써 접근 가능하다. (resource)
• Q: 프로젝트 A의 기본 서비스 계정이 B 프로젝트의 storage bucket에 접근해야 합니다.
• A: 프로젝트 B에서 A의 서비스 계정을 추가하고 버킷상의 저장소 개체를 할당하세요

ACL(access control lists)

• 누가 buckets과 object에 접근할지 level을 정함.
• IAM과 다른점. IAM은 모든 오브젝트에 동일한 권한을 주지만 ACL은 object에 따라 개별화된 접근 권한 제공 가능. 즉 좀더 세밀화됨

Signed URL

• URL을 통해 제한된 일정시간동안만, 특정 액션을 제공한다.
• 별도의 구글 계정이 필요 없다.
• Signed URL은 permission에 따른 key를 만들고 아래 명령어를 통해 생성된다.
  gsutil signurl -d 10m YOUR_KEY gs://BUCKET_NAME/OBJECT_PATH

Cloud storage로 부터 정적인 website 만들기

• 1. website 이름과 동일한 bucket을 만든다.
• 2. 파일들을 bucket으로 복사한다.
• 3. Storage Object viewer 옵션을 allusers로 허용한다. 이제 url로 모두 접근 할 수 있다.