티스토리 뷰
[구글 클라우드 플랫폼] GCP : Cloud IAM(Identity and Access Management)
로또_ 2020. 10. 4. 01:51
GCP : Cloud IAM
목차:
1. Cloud Identity and Access Management(IAM)
2. Organization
3. Roles
4. Members
5. Services Accounts
1. Cloud IAM(Identity and Access Management)
1.1 Identity and Access Management
IAM을 사용하면 특정 Google Cloud 리소스에 대한 세부적인 액세스 권한을 부여하고 다른 리소스에 대한 액세스를 방지할 수 있습니다. 또한 IAM은 최소 권한의 보안 원칙을 적용(중요)하여 특정 리소스에 액세스 하는 데 필요한 권한만 부여할 수 있게 해 줍니다.
IAM을 사용하면 누구(ID)에게 무슨 리소스에 대한 어떤 액세스 권한(역할)이 있는지 정의하여 액세스 제어를 관리할 수 있습니다. 예를 들어 Compute Engine Virtual Machine 인스턴스, Google Kubernetes Engine(GKE) 클러스터, Cloud Storage 버킷은 모두 Google Cloud 리소스입니다(GCP Services). 리소스를 구성하는 데 사용하는 조직, 폴더, 프로젝트도 리소스입니다.
1.2 Cloud IAM objects
Cloud IAM은 다음과 같은 objects들로 구성되어 있습니다. Organization, Folders, Projects, Resources, Roles, Members.
전에 공부한 걸 추가하자면, Policy = roles + members
1.3 Cloud IAM resource hierarchy
- GCP 리소스는 트리 구조에 표시된 것처럼 계층적으로 구성됩니다. 각 리소스에는 정확히 하나의 부모가 있습니다.
- Cloud IAM을 사용하면 역할 및 역할 구성원 집합이 포함된 모든 수준에서 정책을 설정할 수 있습니다. 리소스는 부모로부터 정책을 상속합니다.
- 조직(Organization) 리소스는 회사를 나타냅니다. 이 수준에서 부여된 Cloud IAM 역할은 조직의 모든 리소스에 상속됩니다.
- 폴더 리소스는 부서(department)를 나타낼 수 있습니다. 이 수준에서 부여된 Cloud IAM 역할은 폴더에 포함된 모든 리소스에 상속됩니다.
- 프로젝트(Project)는 회사 내의 신뢰 경계(Trust boundary)를 나타냅니다. 동일한 프로젝트 내의 서비스에는 기본 신뢰 수준이 있습니다.
- 위험에 대한 노출을 줄이기 위해 항상 작업에 필요한 가장 작은 범위를 선택해야 합니다.
2.Organization
2.1 Organization node
- 조직 리소스는 GCP 리소스 계층 구조의 루트 노드입니다.
- 조직 관리자(Organization Admin)는 Bob과 같은 사용자에게 자신의 조직에 속한 모든 리소스를 관리할 수 있는 액세스 권한을 제공하므로 감사에 유용합니다.
- 또한 Alice와 같은 사용자가 자신의 조직 내에서 프로젝트를 만들 수 있도록 하는 프로젝트 생성자(Project Creator) 역할도 있습니다. 조직 수준에서도 적용할 수 있고 조직 내 모든 프로젝트에 상속될 수 있습니다.
2.2 Creating and managing organizations
- 조직(Organization) 리소스는 G Suite 또는 Cloud ID 계정과 밀접하게 연결되어 있습니다.
- G Suite 또는 Cloud ID 계정이 있는 사용자가 GCP 프로젝트를 만들면 조직 리소스가 자동으로 프로비저닝 됩니다. 그런 다음 GCP는 G Suite 또는 Cloud ID 최고 관리자에게 가용성을 전달합니다. 최고 관리자 계정은 조직과 그 아래에 있는 모든 리소스를 많이 제어할 수 있으므로 신중하게 사용해야 합니다.
- G Suite 또는 Cloud ID super administrators(Cloud ID 최고 관리자) 및 GCP Organization admin은 setup process 및 조직 리소스의 수명주기 제어를 위한 핵심 역할을 합니다. 일반적으로 두 역할은 조직 구조 및 요구 사항에 따라 다르지만 다른 사용자 또는 그룹에 할당됩니다.
- GCP Organization setup과 관련하여 G Suite 또는 Cloud ID super administrators의 책임은 다음과 같습니다.
-
일부 사용자에게 조직 관리자 역할을 할당합니다.
-
복구 문제 발생 시 연락창구 역할을 할 수 있습니다.
-
G Suite 또는 Cloud ID 계정 및 조직 리소스의 수명주기를 제어합니다.
- 조직 관리자(Organization admin) 역할의 책임은 다음과 같습니다.
-
IAM 정책을 정의합니다.
-
리소스 계층 구조를 결정합니다.
-
IAM 역할을 통해 네트워킹, 결제 및 리소스 계층과 같은 중요한 구성 요소에 대한 책임을 위임합니다.
2.3 Folders
- 폴더는 프로젝트 간에 추가 그룹화 메커니즘과 격리 경계를 제공합니다. 폴더를 사용하여 회사 내의 다양한 법인, 부서 및 팀을 모델링할 수 있습니다.
- 폴더를 사용하면 관리 권한을 위임할 수 있습니다. 예를 들어 부서의 각 책임자는 해당 부서에 속한 모든 GCP 리소스에 대한 전체 소유권을 부여받을 수 있습니다. 마찬가지로 리소스에 대한 액세스는 폴더별로 제한될 수 있으므로 한 부서의 사용자는 해당 폴더 내의 GCP 리소스에만 액세스하고 만들 수 있습니다.
2.4 Resource manager roles
- 마찬가지로 프로젝트의 경우, 사용자가 새 프로젝트를 생성하여 해당 사용자를 자동으로 소유자로 만드는 생성자 역할이 있습니다. 프로젝트에 대한 삭제 권한을 부여하는 프로젝트 삭제자 역할도 있습니다.
3. Roles
3.1 Three types of IAM roles
- IAM roles에는 다음 세 가지 타입이 있습니다. Primitive, Predefined, Custom
3.2 IAM Premitive roles
- GCP Console에서 가능한 original roles입니다.
- GCP project에 적용시킬 수 있으며, project의 모든 리소스에 영향을 미칩니다.
- 즉, IAM primitive roles은 고정된 coarse-grained 액세스 수준을 제공합니다.
- Owner, Editor, Viewer역할이 있습니다.
-
소유자(Owner)는 전체 관리 액세스 권한이 있습니다. 여기에는 구성원을 추가 및 제거하고 프로젝트를 삭제하는 기능이 포함됩니다.
-
편집자(Editor) 역할에는 수정 및 삭제 권한이 있습니다. 이를 통해 개발자는 애플리케이션을 배포하고 리소스를 수정하거나 구성할 수 있습니다.
-
뷰어(Viewer) 역할에는 읽기 전용 액세스 권한이 있습니다.
- 소유자 역할에는 편집자 역할의 권한이 포함되고 편집자 역할에는 뷰어 역할의 권한이 포함됩니다.
- 프로젝트의 리소스를 변경할 권한 없이 결제를 관리하고 관리자를 추가 또는 제거하는 결제 관리자 역할도 있습니다. 각 프로젝트에는 여러 명의 소유자, 편집자, 뷰어 및 결제 관리자가 있을 수 있습니다.
3.3 IAM Predifined roles
- GCP 서비스는 predefined 된 자체 roles set를 제공하며 이러한 역할을 적용할 수 있는 위치를 정의합니다.
- 이를 통해 구성원에게 특정 GCP 리소스에 대한 세분화된 액세스 권한을 제공하고 다른 리소스에 대한 원치 않는 액세스를 방지합니다.
- 의미 있는 작업을 수행하려면 일반적으로 둘 이상의 권한이 필요하기 때문에 이러한 roles는 collections of roles입니다.
- 예를 들어 여기에 표시된 것처럼 사용자 그룹에는 project_a에 대한 InstanceAdmin 역할이 부여됩니다. 그러면 해당 그룹의 사용자에게 오른쪽에 나열된 모든 Compute Engine 권한 등이 제공됩니다. 이러한 권한을 역할(roles)로 그룹화하면 관리가 더 쉬워집니다. 권한 자체는 API의 클래스 및 메서드입니다.
- 위의 예시에서 더 설명하자면, InstanceAdmin Role을 부여하였기 때문에 List of Permissions에서 compute.instances.*인 권한을 모두 받습니다.
- Compute Engine에는 몇 가지 predefined 된 IAM 역할이 있습니다.
-
Compute Admin role은 모든 Compute Engine 리소스에 대한 모든 권한을 제공합니다. 여기에는 compute.으로 시작하는 모든 권한이 포함됩니다. 즉, 모든 유형의 Compute Engine 리소스에 대한 모든 작업이 허용됩니다.
-
Network Admin role에는 방화벽 규칙 및 SSL 인증서를 제외하고 네트워킹 리소스를 생성, 수정 및 삭제할 수 있는 권한이 포함됩니다. 즉, 네트워크 관리자 역할은 방화벽 규칙, SSL 인증서, 인스턴스에 대한 읽기 전용 액세스를 허용하여 임시 IP 주소를 볼 수 있습니다.
-
Storage Admin role에는 디스크, 이미지 및 스냅 샷을 생성, 수정 및 삭제할 수 있는 권한이 포함됩니다.
3.4 IAM Custom roles
- 많은 회사에서 조직의 각 개인에게 업무 수행에 필요한 최소한의 권한이 부여되는 "최소 권한"모델을 사용합니다.
4. Members
- 다섯 개의 다른 타입의 members가 있습니다.
-
Google 계정
-
서비스 계정
-
Google 그룹
-
G Suite 도메인
-
Cloud ID 도메인
- Google 계정은 개발자, 관리자 또는 GCP와 상호 작용하는 다른 사람을 나타냅니다. gmail.com 또는 기타 도메인을 포함하여 Google 계정과 연결된 모든 이메일 주소는 ID가 될 수 있습니다.
- 서비스 계정은 개별 최종 사용자가 아닌 애플리케이션에 속한 계정입니다. GCP에서 호스팅 되는 코드를 실행할 때 코드를 실행할 계정을 지정합니다. 애플리케이션의 다양한 논리적 구성 요소를 나타내는 데 필요한 만큼 서비스 계정을 만들 수 있습니다.
- Google 그룹은 Google 계정 및 서비스 계정의 명명된 모음입니다. 모든 그룹에는 그룹과 연결된 고유 한 이메일 주소가 있습니다. Google 그룹은 사용자 collection에 액세스 정책을 적용하는 편리한 방법입니다. 개별 사용자 또는 서비스 계정에 대해 한 번에 하나씩 액세스 제어를 부여하거나 변경하는 대신 전체 그룹에 대한 액세스 제어를 한 번에 부여하고 변경할 수 있습니다.
- G Suite 도메인은 조직의 G Suite 계정에서 생성된 모든 Google 계정의 가상 그룹을 나타냅니다. G Suite 도메인은 example.com과 같은 조직의 인터넷 도메인 이름을 나타내며 G Suite 도메인에 사용자를 추가하면이 가상 그룹 내의 사용자에 대해 username@example.com과 같은 새 Google 계정이 생성됩니다.
- G Suite 고객이 아닌 GCP 고객은 Cloud ID를 통해 동일한 기능을 얻을 수 있습니다. 클라우드 ID를 사용하면 Google 관리 콘솔을 사용하여 사용자와 그룹을 관리할 수 있지만 Gmail, 문서, 드라이브, 캘린더와 같은 G Suite 공동 작업 제품에 대한 비용을 지불하거나 받을 수는 없습니다. Cloud ID는 무료 및 프리미엄 버전으로 제공됩니다. 프리미엄 에디션은 모바일 장치 관리 기능을 추가합니다.
- Cloud IAM을 사용하여 사용자 또는 그룹을 만들거나 관리할 수 없다는 점에 유의해야 합니다. 대신 Cloud ID 또는 G Suite를 사용하여 사용자를 만들고 관리할 수 있습니다.
- 이미 다른 회사 디렉토리가있는 경우, 사용자와 그룹을 GCP로 어떻게 가져올 수 있습니다.
- 관리자는 Google 클라우드 디렉토리 동기화를 사용하여 이미 사용 중인 것과 동일한 사용자 이름과 비밀번호를 사용하여 GCP 리소스에 로그인하고 관리할 수 있습니다.
- 이 도구는 기존 Active Directory 또는 LDAP 시스템의 사용자 및 그룹을 Cloud ID 도메인의 사용자 및 그룹과 동기화합니다. 동기화는 단방향 전용(one-way sync)입니다. 이는 Active Directory 또는 LDAP 맵의 정보가 수정되지 않음을 의미합니다. Google 클라우드 디렉토리 동기화는 동기화 규칙이 설정된 후 감독 없이 예약된 동기화를 실행하도록 설계되었습니다.
- GCP는 Single sing-on(SSO)도 제공합니다. ID 시스템이 있는 경우 SSO가 구성된 자체 시스템 및 프로세스를 계속 사용할 수 있습니다.
- 사용자 인증이 필요한 경우 Google은 시스템으로 리디렉션 합니다. 사용자가 시스템에서 인증되면 Google Cloud Platform에 대한 액세스 권한이 부여됩니다. 그렇지 않으면 사용자에게 로그인하라는 메시지가 표시됩니다. 이렇게 하면 GCP에 대한 액세스도 취소할 수 있습니다.
- 기존 인증 시스템이 SAML2를 지원하는 경우 SSO 구성은 이 슬라이드에 표시된 것처럼 3 개의 링크와 인증서로 간단합니다. 그렇지 않으면 ADFS, Ping 또는 Okta와 같은 타사 솔루션을 사용할 수 있습니다.
5. Service Accounts
- 서비스 계정은 개별 최종 사용자가 아닌 애플리케이션에 속한 계정입니다. 이는 사용자 자격 증명을 제공하지 않고 프로젝트에서 서버 간 상호 작용을 수행하기 위한 ID를 제공합니다.
- 예를 들어 Google Cloud Storage와 상호 작용하는 애플리케이션을 작성하는 경우 먼저 Google Cloud Storage XML API 또는 JSON API에 인증해야 합니다.
- 서비스 계정을 활성화하고 애플리케이션을 실행할 인스턴스의 계정에 대한 읽기-쓰기 액세스 권한을 부여할 수 있습니다. 그런 다음 서비스 계정에서 자격 증명을 얻도록 애플리케이션을 프로그래밍합니다. 애플리케이션은 인스턴스, 이미지 또는 애플리케이션 코드에 비밀 키나 자격 증명을 포함하지 않고 API에 원활하게 인증됩니다.
5.1 Three types of Service account
- 다음 3가지 종류의 service account가 있습니다.
-
user-created or custom
-
built-in
-
Google APIs service accounts.
- 기본적으로 모든 프로젝트는 Compute Engine 기본 서비스 계정과 함께 제공됩니다.
- 기본 서비스 계정과는 별도로 모든 프로젝트에는 project-number@cloudservices.gserviceaccount.com 이메일로 식별할 수 있는 Google Cloud Platform API 서비스 계정이 제공됩니다. 이는 사용자를 대신하여 내부 Google 프로세스를 실행하도록 특별히 설계된 서비스 계정이며 프로젝트에 대한 편집자 역할이 자동으로 부여됩니다.
- 또는 custom service account로 인스턴스를 시작할 수도 있습니다. custom service account는 기본 서비스 계정보다 더 많은 유연성을 제공하지만 더 많은 관리가 필요합니다. 필요한 만큼 커스텀 서비스 계정을 만들고 임의의 액세스 범위 또는 Cloud IAM 역할을 할당하고 모든 가상 머신 인스턴스에 서비스 계정을 할당할 수 있습니다.
- project-number compute@developer.gserviceaccount.com으로 식별할 수 있으며 프로젝트에 대한 편집자 역할이 자동으로 부여됩니다.
- gcloud를 사용하여 새 인스턴스를 시작하면 해당 인스턴스에서 기본 서비스 계정이 사용 설정됩니다. 다른 서비스 계정을 지정하거나 인스턴스의 서비스 계정을 사용 중지하여 이 동작을 재정의 할 수 있습니다.
5.2 Scopes
- authorization은 인증된 ID가 지정된 리소스 집합에 대해 갖는 권한을 결정하는 프로세스입니다. Scope는 authorize 된 ID가 승인되었는지 여부를 결정하는 데 사용됩니다.
- 기본 서비스 계정을 사용하여 인스턴스를 만들 때 Scope를 맞춤 설정할 수 있습니다.
- Access Scope는 실제로 VM에 대한 권한을 지정하는 레거시 방법입니다. IAM 역할이 존재하기 전에는 액세스 범위가 서비스 계정에 권한을 부여하는 유일한 메커니즘이었습니다.
- user-created service account의 경우 access scope대신 Cloud IAM 역할을 사용하여 권한을 지정하세요.
5.3 Service account permissions
- Service account들은 다음과 같은 차이점을 가지고 있습니다. Default service acconts는 primitive 및 predefined IAM roles을 모두 지원하지만, user-created service accounts는 predefined IAM 역할만 사용한다는 것입니다.
- service account의 roles를 그룹 또는 사용자에게 할당할 수도 있습니다. 위의 그림의 예시를 살펴보면, 먼저 가상 머신 인스턴스 및 디스크를 만들고 수정 및 삭제할 수 있는 권한을 가지고 있는 InstanceAdmin 역할 서비스 계정을 만듭니다. 그런 다음이 서비스 계정을 리소스로 취급하고 사용자 또는 그룹에 서비스 계정 사용자 역할을 제공하여 누가 사용할 수 있는지 결정합니다. 이를 통해 해당 사용자는 해당 서비스 계정으로 작동하여 가상 머신 인스턴스 및 디스크를 생성, 수정 및 삭제할 수 있습니다.
- Service account를 사용하는 사용자는 서비스 계정이 액세스 할 수 있는 모든 리소스에 액세스 할 수 있습니다. 따라서 사용자 또는 그룹에 서비스 계정 사용자 역할을 부여할 때 주의해야 합니다.
- 예를 들어 설명하도록 하겠습니다. component_1을 실행하는 VM에는 서비스 계정 1을 사용하여 project_b에 대한 편집자 액세스 권한이 부여됩니다. component_2를 실행하는 VM에는 격리된 서비스 계정 2를 사용하여 bucket_1에 대한 objectViewer 액세스 권한이 부여됩니다. 이렇게 하면 VM을 다시 만들지 않고도 VM의 권한 범위를 지정할 수 있습니다.
- 기본적으로 Cloud IAM을 사용하면 각각을 나타내는 서비스 계정을 만들어 프로젝트를 서로 다른 리소스에 액세스 할 수 있는 여러 마이크로 서비스로 분할할 수 있습니다. VM이 생성될 때 서비스 계정을 VM에 할당하고 GCP에서 보안을 관리하므로 사용자 인증 정보가 올바르게 관리되고 있는지 확인할 필요가 없습니다.
- 사용자가 인증하려면 사용자 이름과 비밀번호가 필요하지만 서비스 계정은 키를 사용합니다.
- 서비스 계정 키에는 GCP-managed key와 user-managed keys의 두 가지 유형이 있습니다.
GCP-managed key
GCP-managed key는 App Engine 및 Compute Engine과 같은 GCP 서비스에서 사용됩니다. 이 키는 다운로드할 수 없으며 자동으로 순환되어 최대 2 주 동안 사용됩니다.
user-managed keys
user-managed keys는 사용자가 생성, 다운로드 및 관리합니다. 새 키 쌍을 만들 때 Google에서 보유하지 않는 개인 키를 다운로드합니다. 사용자 관리 키를 사용하면이 위의 그림에서 설명된 대로 개인 키의 보안과 키 순환과 같은 기타 관리 작업을 담당합니다.
6. ETC
Cloud Identity-Aware Proxy(Cloud IAP)
- 마지막으로 Cloud Identity-Aware Proxy 또는 Cloud IAP를 사용하는 것이 좋습니다. Cloud IAP를 사용하면 HTTPS로 액세스 하는 애플리케이션에 대한 중앙 authorization 레이어를 설정할 수 있으므로 네트워크 수준 방화벽에 의존하는 대신 애플리케이션 수준 액세스 제어 모델을 사용할 수 있습니다.
- Cloud IAP로 보호되는 애플리케이션 및 리소스는 올바른 Cloud IAM 역할이 있는 사용자 및 그룹만 프록시를 통해 액세스 할 수 있습니다. 사용자에게 Cloud IAP를 통해 애플리케이션 또는 리소스에 대한 액세스 권한을 부여하면 VPN 없이도 사용 중인 제품에서 구현 한 세분화된 액세스 제어가 적용됩니다. Cloud IAP는 오른쪽에 표시된 대로 사용자가 Cloud IAP 보안 리소스에 액세스 하려고 할 때 인증 및 승인 확인을 수행합니다.
수고하셨습니다~