Coursera 과정 중 AWS Professional 을 위한 Google Cloud 강의가 있습니다.
GCP 의 기본 구조에 대해 설명하게 되는데, AWS 에 익숙하신 분들이 처음 GCP 를 접할 때 참조하면 좋을 것 같아서 해당 내용을 정리해둡니다.
1. 리소스 Hierarchy
1.1 AWS 리소스 구조
AWS 의 리소스 구조는 다음과 같이 표현됩니다.
- Organization root, Organization Unit(Optional), Account (Management Account or Member Account), Resource
- 가장 상단에 위치한 Organization root 는 조직 내에 공유되는 모든 계정들을 포괄합니다.
- Account(계정)은 리소스를 담는 컨테이너입니다. 관리계정, 혹은 멤버계정이 될 수 있고, Management account(관리계정)은 해당 Organization root 에서 발생하는 모든 비용을 책임집니다. 이 외의 모든 다른 계정은 Member account 로 동작합니다.
1.2 GCP 리소스 구조
GCP 의 리소스 구조는 다음과 같습니다.
- Organization, Folder, Project, Resource
- GCP 상에서는 최상위 Organization(조직) 하에 여러개의 폴더와 프로젝트가 생성될 수 있습니다. 실제 사용하는 리소스는 항상 특정한 프로젝트 내에 생성되게 됩니다.
- 폴더는 부서나, 팀, 혹은 업무 환경 등을 나타낼 수 있고, 계층적으로 하위 폴더를 가질수도 있습니다.
- 프로젝트는 폴더 내부, 혹은 하위 폴더 내부, 혹은 조직에 붙어있을 수 있습니다.
1.3 정책의 상속
GCP 에서는 상위(Organization)에서 하위(리소스) 방향으로, 부모 리소스의 정책, IAM 설정을 상속합니다.
GCP 내 환경의 적절한 제어를 위해 "Policy(정책)"을 설정할 수 있는데, 이 정책은 프로젝트, 폴더, 조직(Organization) 수준에서 정의할 수 있습니다. 가령, 조직 레벨에서 Organization node policy 중 일부를 활성화시켜 두었다면, 해당 조직 내 모든 리소스는 활성화된 정책의 영향을 받게됩니다.
1.4 조직 (Organization)
GCP 의 Organization Admin (조직 관리자) 는 조직 내 모든 클라우드 리소스를 제어할 수 있습니다.
또한 Project creator (프로젝트 생성자) 는 해당 조직 내 프로젝트의 생성을 제어합니다.
조직의 생성 및 관리
GCP 의 Organization (조직) 리소스는 Google Workspace(GWS) 혹은 Cloud Identity 와 긴밀히 연결됩니다. GWS, Cloud Identity 에 계정이 있는 사용자가 GCP 프로젝트를 생성하면 조직 리소스가 자동으로 프로비저닝됩니다. 이후, GWS, Cloud Identity 의 Super admin 은 GCP 에 생성된 조직과 하부 리소스를 제어할 수 있게됩니다.
- Super Admin : GWS, Cloud Identity 최고 관리자로서, 일부 사용자에게 Organization admin 역할을 부여할수 있고, 조직 리소스의 수명 주기를 제어함.
- Organization Admin : GCP 상에서 IAM 정책을 정의하고, 리소스 계층 구조를 결정, IAM roles 설정을 통해 중요 구성 요소에 대한 책임 위임함. (이 외, 폴더/프로젝트 등의 리소스 생성에 대한 부분은 별도 IAM 권한 설정이 필요함.)
1.5 폴더
GCP 폴더는 AWS 상에서의 Organization Unit 단위가 AWS Account 를 구성하는 방식과 유사하게 동작합니다. 일종의 조직 내 하위 조직을 구성할 수 있는 경계를 설정합니다.
- 폴더 레벨 별로 리소스에 대한 관리 권한 위임이 가능
- 각 폴더에 하위 폴더, 하나 이상의 프로젝트 포함 가능
1.6 프로젝트
프로젝트는 조직 (혹은 폴더) 아래의 별도의 엔터티로, 리소스를 보관합니다. 리소스는 생성 시, 단 하나의 프로젝트에만 포함됩니다. (프로젝트를 선택하고, 해당 프로젝트 내 리소스를 생성하는 형식)
프로젝트 별로 사용된 리소스 양에 따라 별도로 청구가 되며, 관리됩니다.
(참고사항) 프로젝트 생성 시 자동으로 붙게되는 id, number 는 고유하며, 프로젝트명 자체는 변경 가능합니다.
1.7 Resource Manager
AWS 상에서는 리소스 계층 관리를 위해 AWS Organizations, AWS Control Tower, AWS Resource Access manager 등의 도구모음들을 제공합니다.
- AWS Organizations : 관리자가 조직 단위 생성, 업데이트, 삭제, 계정에 대한 가드레일 역할하는 서비스 제어 정책(SCP) 적용
- AWS Control Tower : 관리자가 계정 프로비저닝을 중심으로 가드레일과 자동화 설정, 계정이 조직 모범 사례 따르고 있는지 확인할 수 있는 기능도 제공
- AWS Resource access manager : 조직 내 계정(Account) 간 리소스 공유를 위한 도구로서 제공
Q. AWS 리소스 계층 구조 상에서 "리소스"는 최초 생성된 상위 Account 에서 다른 Account 로 이동할 수 있는가?
==> A. 리소스는 생성 시 특정 계정에 귀속되며, 소유권은 변경이 불가능함. 단, 다른 계정에서 해당 리소스를 사용할 수 있도록 공유하거나, 리소스를 복사하거나, IAM 역할을 사용하여 다른 계정의 리소스에 접근하도록 할 수 있음.
==> GCP 에서는? 리소스는 프로젝트에 귀속되며, 마찬가지로 소유권의 변경이 불가능함. 리소스의 복사는 지원하지 않지만, 타 프로젝트에서 리소스에 접근하고자 할때 프로젝트 간 VPC 연결(ex. VPC Sharing/Peering)을 통해 구성이 가능함. IAM 의 역할 설정을 통해, 타 프로젝트에 속한 서비스 계정에서 리소스에 접근하도록 설정할 수 있음. (* 서비스 계정에 대한 부분은 뒤에서 설명)
GCP 상에서 Resource Manager 는 계정과 관련된 모든 프로젝트의 목록을 수집, 새 프로젝트 생성, 기존 프로젝트 업데이트, 삭제 등이 가능한 API 로 제공됩니다. (RPC API, REST API)
* AWS 의 기본 제공 Policy, Custom Policy vs GCP 의 기본 제공 roles, Custom roles
AWS 상에서 권한, 해당 권한 적용되는 리소스의 컬렉션 = Policy
AWS 는 서비스 제어 정책(SCP) 제한되지 않는 한, Account root 가 역할, 정책을 완전히 관리함. 이러한 Policy 는 사용자, 사용자 그룹, 역할에 첨부 가능
GCP 상에서는 미리 정의된 역할 세트(권한의 모음)를 roles 로 제공함. 해당 역할이 적용될 수 있는 "위치"를 정의하게 됨.
* GCP 권고사항
- 조직 구조에 계층구조를 반영하되, 스타트업의 경우 평평한 리소스 계층 구조로 시작 후 이후에 조직 리소스 확보도 가능
- 프로젝트는 동일한 신뢰 경계를 공유하는 리소스를 그룹화
- 개별 사용자 대신 Google Group 에 역할을 부여, 이후 멤버 관리
- 최소 권한 보안 원칙으로 IAM 역할 부여 (이미 정의된 roles 외, 사용자 지정 roles 를 생성 가능)
1.8 리소스 계층 구조 및 청구 차이점
GCP 는 프로젝트 별로 그룹화되어 비용이 청구되고, 여러개의 billing account(청구 계정)을 활용할 수 있습니다. 이에 비하여, AWS 는 Account(계정) 별 청구를 허용합니다.
- Billing account : AWS 계정 당 billing account 하나씩 존재하며, 통합 청구 기능을 사용할때 조직 당 billing account 가 하나 존재합니다. 이에 비하여, GCP 는 조직 내에서 여러개의 billing account 를 생성할 수 있고, 하나의 billing account 를 동시에 여러 프로젝트에 매핑하여 비용을 청구할 수 있습니다.
- Policy : AWS 의 Policy 는 IAM principal 에만 적용할 수 있고, 상속할 수 없습니다. GCP 에서는 다양한 Policies 들(ex. Organization Policies, Roles)을 조직, 폴더, 프로젝트, 계정 수준에서 적용할 수 있습니다.
- Admin : AWS 는 계정 관리를 위한 Root User 가 필요합니다. GCP 는 Gmail 사용자, GWS Super admin 을 통해 조직 리소스와 계정에 대한 관리가 가능하며, 조직 관리자(Organization Admin) 권한을 특정 사용자에게 부여하여 계정 및 조직 리소스 관리(Super Admin)와 GCP 상의 조직 내 리소스 관리자(Organization Admin)를 분리할 수 있습니다.
2. IAM 및 접근 제어
2.1 Cloud ID 관리
GCP 에서 사용자 ID 는 GCP 외부에서 관리(GWS, Gmail)하며, Cloud Identity 라는 도구를 사용해서 조직에서 Google admin console 사용하여 정책 정의 및 사용자, 그룹 관리 수행이 가능함. 기존에 AD 를 사용하는 경우 사용자 페더레이션 접근 관리가 가능함.
AWS Directory Service 통해 기존 Active Directory(AD) 솔루션과 통합 가능함.
** 기존 사용하던 LDAP 솔루션과의 통합? (참고 : GCP 의 인증 및 인가)
GCP 에서는 Cloud Identity, Google Workspace 를 통한 계정 관리 뿐만 아니라, 기존에 사용하던 LDAP 솔루션과의 통합도 제공합니다. Active Directory, Microsoft Entra ID(Azure AD), 그 외 기타 ID 공급 업체(ex. Okta)를 사용하는 경우, 기존 환경 ID 를 페더레이션 합니다.
- 방법 1. Cloud Identity 의 Google Cloud Directory Sync(GCDS) 를 활용해서 기존 IdP의 사용자 ID 를 Google Cloud ID 로 동기화하여 사용
- 방법 2. Workforce Identity Federation : 기존 IdP 사용자 ID 를 Cloud ID 로 동기화하지 않고, 속성 기반 단일 로그인 방식을 지원
2.2. IAM 원칙 및 정책
GCP 에서는 IAM 을 활용해서, "누가" "어떤 리소스에서" "무엇을 할수있는지" 제어합니다.
- "누가" = Principals 가 대상이 됩니다. (개별 구글 계정, 그룹, 서비스 계정, Cloud ID 혹은 GWS 계정)
- "어떤 리소스에서" = 스토리지, Compute engine, 빅쿼리 등의 클라우드 리소스
- "무엇을 할수 있는지" = Admin, Viewer, Editor, Creator, User 등 미리 정의된 Permissions 들의 묶음인 Roles 을 선택하여 부여합니다.
- Roles 에 주체 목록(Principals)을 바인딩하여 목록으로 구성됩니다.
- 리소스에 대해 누가, 어떤 접근 권한을 가지는지 정의할 때 허용하는 정책을 만들어 리소스에 바인딩합니다.
- IAM 정책은 모든 리소스 수준에서 설정되며(조직, 폴더, 프로젝트), 부모 노드의 정책을 상속합니다.
조직노드 정책 --> 폴더 정책 --> 프로젝트 정책 --> 리소스 로 상속됩니다. 만약 상위 노드(ex. 조직)에서 특정 주체에 대해 리소스의 editor 권한을 설정했는데, 하위 노드(ex. 프로젝트)에서 동일 주체에 대해 리소스의 viewer 권한을 설정하더라ㄷ, 상위 노드의 권한을 상속받아 editor 권한을 갖게 됩니다.
- 프로젝트를 폴더 A 에서 폴더 B 로 이동할 경우, 폴더 수준에 설정된 권한을 상속받게 됩니다. (즉, 권한이 폴더 B 에 설정된 것으로 적용됨.)
2.3 IAM 역할(Roles) 및 조건
GCP IAM 에는 기본 역할, 사전 정의된 역할, 사용자 지정 역할이 있습니다.
AWS IAM 은 세가지 유형의 ID 기반 정책을 제공합니다.
- AWS 관리, 고객 관리, 인라인
- 정책은 식별된 리소스에 대해 허용되는 작업의 집합입니다. 정책은 IAM ID 에 연결되며, 조직 관리자는 정책을 사용해서 IAM ID 의 권한을 제한합니다. 이 부분은 상속 가능한 서비스 제어 정책(SCP)을 적용하여 해당 그룹의 ID, 리소스에 적용할 수 있습니다. (!= IAM 정책과 다름)
- IAM 사용자는 프로그래밍 방식, 콘솔 액세스가 부여됨 != 정책의 일부가 아님
- AWS IAM 정책은 ID 와 권한을 관리하는 AWS IAM 을 통해 관리되며, 1) RBAC 을 통해 특정 리소스에 대한 접근을 허용하거나, 2) ABAC 을 통해 ID, 리소스의 속성 조건에 따라 특정 AWS 리소스에 대한 접근을 허용함.
IAM 조건(Condition) 은,
- 클라우드 리소스에 대한 조건부 ABAC 적용. 즉, 구성된 조건이 충족할 때만 ID(멤버)에 리소스 접근 권한 부여함
- GCP 에서 IAM 조건 지정은, IAM 정책의 role 바인딩 시 지정됨. 조건이 존재하는 경우, 조건 표현식이 true 일때만 접근 요청 허용됨. (참고 블로그 : GCP IAM Condition)
2.4 플랫폼 간 주요 IAM 개념 차이점
2.5 IAM 모범 사례 및 시나리오
- 최소 권한의 원칙
- 개인이 아닌 그룹에 역할을 부여
- 서비스 계정에 역할 부여 시(serviceAccountUser) 주의가 필요합니다. 서비스 계정의 모든 리소스에 대한 접근을 제공하게 됩니다. (serviceAccount.keys.list() method 로 키 감사)
- Identity-Aware Proxy(IAP) 를 사용
3. Service Account
3.1 서비스간 인증의 차이점
AWS 인스턴스 프로필
- 어플리케이션은 IAM 역할과 인스턴스 프로필을 사용하여 어플리케이션의 권한을 관리. 즉, 적절한 권한이 있는 역할이 서비스와 연결된 인스턴스 프로필에 생성되고 구성됨.
- 인스턴스 프로필은 AWS EC2 컨테이너에서 실행되는 어플리케이션에 연결 가능한 IAM 역할의 컨테이너임. 명명된 역할에서 부여한 권한을 제공. 즉, 인스턴스 프로필에서 자격 증명 관리가 없어도 지정된 리소스에 접근하는데 사용할 수 있는 지정된 역할이 포함되어 있음. (임시 자격 증명 및 해당 자격 증명의 순환을 처리)
GCP 서비스 계정
- Google Cloud IAM 서비스 계정은 Google Cloud 인스턴스에 할당되고, GCP 서비스, 리소스, 애플리케이션 코드에 접근하는데 사용됨
- 서비스 계정은 이메일 주소로 명명되지만, 비밀번호 대신 암호화 키를 사용하여 리소스에 접근함
3.2 Google Cloud 의 서비스 계정
세가지 유형의 서비스 계정이 존재함.
- 사용자가 임의로 생성하는 서비스 계정
- 기본적으로 제공되는 서비스 계정 : Compute engine 같이 일부 GCP 서비스는 다른 GCP 리소스에 접근하는 작업을 배포할 수 있도록 하는 "기본 서비스 계정"을 만들게 됨. 기본 서비스 계정은 프로젝트에 대한 editor 권한 가짐.
- 구글이 관리하는 서비스 계정 : GCP 서비스에 대해 구글 자체적으로 서비스 계정을 만들고 사용자를 대신하여 동작시킬 때 사용. 예를 들어, Cloud Run 사용 시, 해당 서비스는 컨테이너를 트리거 할 수 있는 모든 Pub/Sub Topic 에 접근할 수 있도록 하는 권한을 구글 서비스 계정으로 동작시킴. ==> 구글 관리 서비스 계정의 "서비스 계정" 페이지 목록에 보이지 않으며, 동작은 감사 로그에서 확인 가능.
서비스 계정 키
- 서비스 계정은 이메일의 형태를 띄지만, 비밀번호 대신 키를 이용함
- 구글은 서비스 계정 키를 자동으로 관리함. 단, GCP 외부에서 서비스 계정을 사용하거나, 구글에서 자체적으로 운영하는 키 로테이션 외 다른 로테이션 기간으로 관리하려는 경우 수동으로 키를 생성/관리 가능함
- 각 서비스 계정은 공개/비공개 RSA 키 쌍과 연결
- Service Account Credentials API 는 내부 키 쌍을 사용하여 단기 서비스 계정 자격 증명 생성, blob 과 JSON 웹 토큰(JWT)에 서명함 = 구글 관리 키 쌍
- 이 외, 사용자는 여러개의 공개/비공개 RSA 키 쌍을 만들고 개인 키를 사용하여 구글 API 로 인증할 수 있음 = 사용자 관리 키 쌍. 공개 키 부분은 구글에 저장하지만, 개인 키는 고객이 보안 책임을 가지고 유지함.
댓글 없음:
댓글 쓰기