Google Cloud associate 강의 요약: Organization

리소스 계층

• Organization>Folder>Project>Resources
• 서로 다른 환경에서 프로젝트를 분리해 생성하는 것을 추천, 각 구역마다 폴더를 분리해 생성하는 걸 추천, 각 환경마다 다르게 프로젝트, 어플리케이션 분리하라. (결론: 다 분리해서 써라)

Billing accounts

• Billing account는 프로젝트에 의무적으로 있어야 함. 한개 이상의 projects를 하나의 계좌에 연결시킬 수 있음
• 조직 내에 여러개의 billing acounts를 가질 수 있음.
• Billing accounts의 2가지 종류
  • Self serve: 바로 신용카드나 계좌에서 결재되는 것
  • Invoiced: 큰 회사의 경우 invoice를 생성해서 씀
• 예산을 정해두고 alerts 설정 가능, billing data는 big query나 cloud storage 로 내보내기 가능

IAM 권장사항

• 최소 권한 원칙: 가능한 역할에 딱 필요한 최소한의 권한만 주어야 한다. 그래서 기본 권한을 그대로 사용하는 건 권장하지 않으며, 서로다른 app들에 만능 계정 하나 만들어 놓고 쓰는 것도 권장하지 않는다.
• 업무 분담 : 민감한 업무를 할때 최소 2명이상 두어라. 그래서 그 둘의 업무 권한을 분담시켜 한명이 망치는 것을 방지해야 한다.
• 지속적인 모니터링
• 그룹을 사용하라

User identity 관리

• 이메일로 슈퍼관리자 계정을 만들 수 있다. 이 슈퍼관리자는 iam을 다른 유저의 계정에 binding 함으로써 권한을 부여할 수 있다. 하지만 이는 기업단위에서는 권장되지 않는다. 기업단위에서는 그보다는 다른 해결책을 권장한다.
• 1. Google workspace 이용 : 구글 클라우드와 연동 가능함
• 2. Identity provider 이용: 마찬가지로 구글 클라우드와 연동 가능함
• 즉 extenernal identity provider (IDP) 로 연동 시켜 이걸로 로그인을 해서 구글클라우드에도 로그인 되게 할 수 있음
• IAM identity로 구글 계정, 서비스 계정(개인X), 구글 group, 구글 workspace(다른 구글 서비스들과 연계하기 좋음), cloud identity domian 등 사용 가능
• 시나리오.
  • Q1. 팀의 모든 멤버가 G suite 계정을 가니고 있다. 너가 새로운 production project를 만들고 팀을 연결시키고 싶다
  • A1. group만들고 너의 팀에게 접근 권한을 주어라
  • Q2. 마찬가지로 모든 멤버가 G suite 계정을 가지고 있다. 너가 새로운 프로젝트를 구성할때 팀 멤버들에게 일회성 액세스 할수 있게 하면 좋겠다.
  • A2. 필요한 권한을 팀 멤버의 G suite Email에 할당해라. 일회성 엑세스 되지 않는다면 그룹 만드는 걸 추천한다.
  • Q3. 너가 외부 감사에게 모든 리소스를 보이게 하고 싶으나 그에게 변경 권한을 주싶지는 않다.
  • A3. viewer role을 주어라. 이때 기본 viewer권한은 권장하지 않으나 가장 간단한 방법이긴 한다.
  • Q4. 너가 A 프로젝트를 GCE VM에 배포 했는데 다른 프로젝트 B의 클라우드 스토리지 버킷에 접근이 필요하다
  • A4. 프로젝트 B에서 프로젝트 A의 GCE VM 서비스에게 올바른 권한을 할당하라.

    Organization policy service

• 조직에서 중앙화된 규칙, 즉 누구나 따라야 하는 규칙을 만들기 위해서는 Organization Policy Administrator 권한을 가진 사람이 Organziation policy를 구성해야 한다.
• IAM은 who에 초점을 맞춘거고 Organization Policy는 무엇을 하면 되는지 안되는지 What에 초점을 맞춘 것이다.
• 특정 지역에서만 resource 생성을 허용하거나, sql 접근 여부 허용 등 다양하다.

Heirachy

• IAM 정책은 Hierarchy같이 레벨이 정해져 있고, 상위 부모 정책들로부더 상속받는다.
• 효율적인 정책을 만들기 위해서는 부모정책을 고려해서 만들어야한다. 하위 정책이 상위 정책을 거스를 수 없기 때문이다.

이제부터 아래 역할들을 굳이 외울 필요는 없고 그냥 이런게 있구나 알아두면 됨

IAM predefined role

• Organization Administrator: 리소스 계층 정의, 접근 정책 관리, 유저와 역할 관리
• Billing account creator: 말그대로 결제 계좌만 생성
• Billing account administrator: 결재 계좌 생성 제외 결제 관련 관리일
• Billing account user: 보통 project Creator과 엮이며 프로젝트와 계좌를 연결시킴
• Billing account viewer: 그냥 결제 되는 거 다 볼수 있음 (감사원 viewer)

Compute Engine role

• compute Engine admin: 다함
• compute instance admin: 인스턴스와 디스크 수정,삭제,생성
• compute engine network admin: 리소스로 네트워크 연결 관련 모든 권한(routes, health checks, vpn, gateway, 방화벽, ssl)
• compute engine security admin: firewall rule, ssl 관리
• compute storage admin: disk, image, 스냅샷 접근
• compute engine viewer: 모든 것을 읽기만 할 수 있음
• compute os admin login: admin 유저로 compute engine 인스턴스에 로그인
• compute os login: standard 유저로 compute engine 인스턴스에 로그인

App engine role

• App engine creator: application CD
• app engine admin: appication RU, 그외 세부 작업 모든 것
• app engine viewer: 모든것 R
• app engine code viewer: 유일하게 code 볼수 있음
• app engine deployer: 배포담당, version CRD, application, service, versions의 R, 일반적으로 서비스 계정과 연결하면 좋음
• app engine service admin: version RUD, application R, service,instance CRUD
• 앱 엔진에서 허용되지 않는 권한: 로그 보고 다운로드, 클라우드 콘솔에서 그래프 모니터링, 결재 활성화 비활성화, 다른 서비스의 접근 구성이나 데이터 저장에 접근
• 위의 이런것들은 app engine이 아닌 다른 데에서 허용해주어야 함

쿠버네티스 Role

• Kurbernetes Engine Admin: 클러스터와 쿠버네티스 API 오브젝트 접근
• Kurbernetes Engine Cluster Admin: 클러스터 관리와 접근 관리, API 오브젝트 자체에 접근할 수는 없음
• Kurbernetes Engine Developer: 쿠버네티스 API 오브젝트 관리
• Kurbernetes Engine Viewer: 클러스터와 쿠버네티스 api 오브젝트 목록들 읽기

클라우드 스토리지 role

• Storage Admin: storage.buckets와 storage.objects. 이 붙는 모든 권한
• Storage Object Admin: storage.objects. 이 붙는 모든 권한
• Storage Object Creator: storage.objects.create
• Storage Object viewer: storage.objects.get/list
• 컨테이너 레지스트리는 클라우드 스토리지 버킷 안에 저장되기에 이미지에 접근하려면 클라우드 스토리지의 적절한 권한이 필요하다.

Bigquery Role

• BigQuery Admin: 전부다
• BigQuery Data Owner: jobs 빼고 다
• BigQuery Data Editor: jobs 빼고 그외 많은 작업
• BigQuery Data Viewer: 그냥 get,list
• BigQuery Job User: bigquery.jobs.create
• BigQuery User: BigqueryData viewer get/list
• 즉 데이터를 보고싶으면 user나 data viewer role 을 부여해야 한다. 또한 data owner과 data viewer는 jobs에 접근할 수 없다는 사실을 알아야 한다.

Logging roles:

• logs viewer: transparency logs 제외한 모든 로그 읽기
• private logs viewer: 모든 로그 읽기
• logging admin: 로그에 관한 모든 권한

Service accounts roles:

• iam.serviceAccountAdmin:서비스 계정 생성관리 모든 권한
• iam.serviceAccountUser: 서비스 계정에서 실행
• iam.serviceAccountTokenCreator: 서비스 계정에 토큰 부여
• iam.serviceAccountKeyAdmin: 서비스 계정 키 생성 및 관리

기타 Roles:

• iam.securityAdmin: IAM 정책 정하기
• iam.securityReviewer: 모든 resource와 IAM 정책 보기
• iam.organizationRoleAdmin: organization과 projects 에서 모든 roles 관리
• iam.organizationRoleViewer: organization, project의 모든 역할 읽기
• iam.roleAdmin: 프로젝트의 role에 접근 제공
• iam.roleViewer: 프로젝트의 role 읽기만
• browser: 리소스 제외 정책이나 구조 읽기

SSH Linux Engine

• Linux vm에서 SSH key를 관리하는 방법:
  • 1. metadata
  • 2. OSLogin: r개별 관리 없이 구글 identity와 연동시켜 활성화 가능, 메타데이터에서 oslogin을 true로 설정함으로써도 가능하긴 함.
• WIndows는 key가 아닌 비밀번호 인증을 사용
• 관리여부와 상관 없이 1. SSH버튼이나 gloud 에서 2.gcloud compute ssh ,3. 커스텀 SSH 키 의 방법으로 상욯라 수 있음.
• 3. 커스텀 SSH key의 경우: metadata로 관리할지 OS login으로 관리할 지 선택할 수 있음. metadata가 중앙집중화 방법임. 명령어를 통해 몇몇 인스턴스에서는 SSH가 안되게 설정할 수 있음

시나리오.

• Q: cloud storage bucket 하위집합에 영구적인 접근 원함.
• A: ACLS
• Q: cloud storage bucket 안의 entire bucket 에 영구적인 접근 구너한 원함
• A: IAM
• Q: cloud storage bucket에 시간 제한 있는 접근 원함
• A: Signed URL
• Q: 개발팀에 resource들 접근 권한을 주고 싶음
• A: 개발 팀에 멤버로 그룹을 만들고, predefined roles 부여
• Q: Cloud storage에 objects upload하는 role은?
• A: Storage Object Creator
• Q: Kubernetes API Objects 들 관리하는 role은?
• A: Kubernetes Engine Developer
• Q: Manage Service accounts 관리하는 역할은?
• A: Service Account Admin
• Q: BigQuery 의 데이터 보는 권한
• A: BigQuery Data Viewer