GCP - Basic Information

리소스 계층 구조

Google Cloud는 전통적인 파일 시스템과 개념적으로 유사한 리소스 계층 구조를 사용합니다. 이는 정책 및 권한에 대한 특정 부착 지점이 있는 논리적인 부모/자식 워크플로를 제공합니다.

높은 수준에서, 이는 다음과 같이 보입니다:

Organization
--> Folders
--> Projects
--> Resources

A virtual machine (called a Compute Instance) is a resource. A resource resides in a project, probably alongside other Compute Instances, storage buckets, etc.

프로젝트 마이그레이션

조직 없이 프로젝트를 조직으로 마이그레이션하는 것이 가능합니다. 필요한 권한은 roles/resourcemanager.projectCreator와 roles/resourcemanager.projectMover입니다. 프로젝트가 다른 조직 내에 있는 경우, 먼저 조직에서 이동하기 위해 GCP 지원에 연락해야 합니다. 자세한 내용은 여기를 확인하세요.

조직 정책

조직의 클라우드 리소스에 대한 중앙 집중식 제어를 허용합니다:

• 조직의 리소스 사용 방식에 대한 제한을 구성하기 위해 중앙 집중식 제어를 설정합니다.

• 개발 팀이 준수 경계를 유지할 수 있도록 가드레일을 정의하고 설정합니다.

• 프로젝트 소유자와 그 팀이 준수를 깨뜨릴 걱정 없이 신속하게 이동할 수 있도록 돕습니다.

이러한 정책은 전체 조직, 폴더 또는 프로젝트에 영향을 미치도록 생성될 수 있습니다. 대상 리소스 계층 노드의 자손은 조직 정책을 상속합니다.

조직 정책을 정의하기 위해, 특정 제약 조건을 선택합니다. 이는 Google Cloud 서비스 또는 Google Cloud 서비스 그룹에 대한 특정 유형의 제한입니다. 원하는 제한으로 그 제약 조건을 구성합니다.

일반적인 사용 사례

• 도메인에 따라 리소스 공유 제한.

• Identity and Access Management 서비스 계정 사용 제한.

• 새로 생성된 리소스의 물리적 위치 제한.

• 서비스 계정 생성 비활성화.

조직의 리소스에 대한 세밀한 제어를 제공하는 더 많은 제약 조건이 있습니다. 자세한 내용은 모든 조직 정책 서비스 제약 조건 목록을 참조하세요.

기본 조직 정책

IAM 역할

이들은 AWS의 IAM 정책과 유사하며, 각 역할은 권한 집합을 포함합니다.

그러나 AWS와 달리 역할의 중앙 집중식 저장소가 없습니다. 대신 리소스는 Y 주체에게 X 액세스 역할을 부여하며, 리소스에 대한 액세스를 확인하는 유일한 방법은 해당 리소스에 대해 get-iam-policy 메서드를 사용하는 것입니다. 이는 주체가 어떤 권한을 가지고 있는지 확인하는 유일한 방법이 모든 리소스에 대해 권한을 부여하는 주체에게 물어보는 것을 의미하므로 문제가 될 수 있습니다. 사용자가 모든 리소스에서 권한을 가져올 수 있는 권한이 없을 수 있습니다.

IAM에는 세 가지 유형의 역할이 있습니다:

• 기본/원시 역할, 여기에는 IAM 도입 이전에 존재했던 소유자, 편집자, 뷰어 역할이 포함됩니다.

• 미리 정의된 역할, 특정 서비스에 대한 세분화된 액세스를 제공하며 Google Cloud에서 관리합니다. 미리 정의된 역할이 많이 있으며, 여기에서 그들이 가진 권한을 모두 확인할 수 있습니다 여기.

• 사용자 정의 역할, 사용자 지정 권한 목록에 따라 세분화된 액세스를 제공합니다.

GCP에는 수천 개의 권한이 있습니다. 역할에 권한이 있는지 확인하려면 여기에서 권한을 검색하고 어떤 역할이 그것을 가지고 있는지 확인할 수 있습니다.

또한 여기에서 미리 정의된 역할을 검색 각 제품에서 제공하는 역할을 확인할 수 있습니다. 일부 역할은 사용자에게 부여할 수 없으며 서비스 계정(SA)에게만 부여될 수 있습니다. 또한 권한은 관련 서비스에 부여될 때만 효과를 발휘합니다.

또는 사용자 정의 역할이 특정 권한을 사용할 수 있는지 확인할 수 있습니다 여기에서.

사용자

GCP 콘솔에는 사용자 또는 그룹 관리 기능이 없으며, 이는 Google Workspace에서 수행됩니다. 그러나 Google Workspace에서 다른 ID 공급자를 동기화할 수 있습니다.

Workspaces의 사용자 및 그룹에 접근할 수 있습니다 https://admin.google.com에서.

MFA는 Workspaces 사용자에게 강제 적용될 수 있지만, 공격자는 MFA로 보호되지 않는 GCP에 cli를 통해 액세스하기 위해 토큰을 사용할 수 있습니다 (사용자가 이를 생성하기 위해 로그인할 때만 MFA로 보호됩니다: gcloud auth login).

그룹

조직이 생성될 때 여러 그룹이 강력히 생성될 것을 권장합니다. 이들 중 하나라도 관리하는 경우, 조직의 모든 부분 또는 중요한 부분이 손상될 수 있습니다:

기본 비밀번호 정책

• 강력한 비밀번호 강제 적용

• 8자에서 100자 사이

• 재사용 금지

• 만료 없음

• 사용자가 제3자 공급자를 통해 Workspace에 접근하는 경우, 이러한 요구 사항이 적용되지 않습니다.

서비스 계정

이들은 리소스가 부착할 수 있는 주체로, GCP와 쉽게 상호작용할 수 있도록 액세스할 수 있습니다. 예를 들어, VM의 메타데이터에 부착된 서비스 계정의 인증 토큰에 접근할 수 있습니다. IAM과 액세스 범위를 동시에 사용할 때 충돌이 발생할 수 있습니다. 예를 들어, 서비스 계정이 compute.instanceAdmin IAM 역할을 가질 수 있지만, 침해한 인스턴스는 https://www.googleapis.com/auth/compute.readonly의 범위 제한으로 인해 제한될 수 있습니다. 이는 인스턴스에 자동으로 할당된 OAuth 토큰을 사용하여 변경을 할 수 없도록 합니다.

이는 AWS의 IAM 역할과 유사합니다. 그러나 AWS와 달리, 모든 서비스 계정은 모든 서비스에 부착될 수 있습니다(정책을 통해 허용할 필요가 없습니다).

여러 서비스 계정은 실제로 GCP에서 서비스를 사용하기 시작할 때 자동으로 생성됩니다, 예를 들어:

PROJECT_NUMBER-compute@developer.gserviceaccount.com
PROJECT_ID@appspot.gserviceaccount.com

그러나 사용자 정의 서비스 계정을 생성하고 리소스에 연결하는 것도 가능합니다. 이는 다음과 같이 보일 것입니다:

SERVICE_ACCOUNT_NAME@PROJECT_NAME.iam.gserviceaccount.com

키 및 토큰

GCP에 서비스 계정으로 접근하는 주요 방법은 2가지입니다:

• OAuth 토큰을 통한 접근: 메타데이터 엔드포인트나 HTTP 요청을 훔치는 등의 방법으로 얻는 토큰이며, 접근 범위에 의해 제한됩니다.

• 키: 서비스 계정으로 요청에 서명하고, 서비스 계정으로서 작업을 수행하기 위해 OAuth 토큰을 생성할 수 있게 해주는 공개 및 비공개 키 쌍입니다. 이 키는 제한하고 제어하기가 더 복잡하기 때문에 GCP는 생성하지 말 것을 권장합니다.

• 서비스 계정이 생성될 때마다, GCP는 사용자가 접근할 수 없는 서비스 계정용 키를 생성합니다 (웹 애플리케이션에 나열되지 않습니다). 이 스레드에 따르면 이 키는 GCP 내부에서 사용되어 메타데이터 엔드포인트가 접근 가능한 OAuth 토큰을 생성할 수 있도록 합니다.

접근 범위

접근 범위는 GCP API 엔드포인트에 접근하기 위해 생성된 OAuth 토큰에 첨부됩니다. 이들은 OAuth 토큰의 권한을 제한합니다. 즉, 토큰이 리소스의 소유자에게 속하더라도 해당 리소스에 접근하기 위한 범위가 토큰에 포함되어 있지 않으면, 토큰은 그 권한을 (남용) 사용할 수 없습니다.

구글은 실제로 권장합니다 접근 범위를 사용하지 말고 IAM에 전적으로 의존할 것을. 웹 관리 포털은 실제로 이를 강제하지만, 접근 범위는 여전히 사용자 정의 서비스 계정을 사용하여 인스턴스에 프로그래밍적으로 적용될 수 있습니다.

어떤 범위가 할당되었는지 쿼리하여 확인할 수 있습니다:

curl 'https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=<access_token>'

{
"issued_to": "223044615559.apps.googleusercontent.com",
"audience": "223044615559.apps.googleusercontent.com",
"user_id": "139746512919298469201",
"scope": "openid https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/cloud-platform https://www.googleapis.com/auth/appengine.admin https://www.googleapis.com/auth/sqlservice.login https://www.googleapis.com/auth/compute https://www.googleapis.com/auth/accounts.reauth",
"expires_in": 2253,
"email": "username@testing.com",
"verified_email": true,
"access_type": "offline"
}

이전의 scopes는 **gcloud**를 사용하여 데이터를 접근할 때 기본적으로 생성된 것입니다. 이는 **gcloud**를 사용할 때 먼저 OAuth 토큰을 생성하고, 그 후에 이를 사용하여 엔드포인트에 연락하기 때문입니다.

그 중 가장 중요한 scope는 **cloud-platform**으로, 이는 기본적으로 GCP의 모든 서비스에 접근할 수 있음을 의미합니다.

여기에서 가능한 모든 scopes의 목록을 찾을 수 있습니다.

gcloud 브라우저 자격 증명이 있는 경우, 다른 scopes로 토큰을 얻는 것이 가능합니다, 다음과 같은 방법으로:

# Maybe you can get a user token with other scopes changing the scopes array from ~/.config/gcloud/credentials.db

# Set new scopes for SDKs credentials
gcloud auth application-default login --scopes=https://www.googleapis.com/auth/userinfo.email,https://www.googleapis.com/auth/cloud-platform,https://www.googleapis.com/auth/sqlservice.login,https://www.googleapis.com/auth/appengine.admin,https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/accounts.reauth,https://www.googleapis.com/auth/admin.directory.user,https://www.googleapis.com/auth/admin.directory.group,https://www.googleapis.com/auth/admin.directory.domain,https://www.googleapis.com/auth/admin.directory.user

# Print new token
gcloud auth application-default print-access-token

# To use this token with some API you might need to use curl to indicate the project header with --header "X-Goog-User-Project: <project-name>"

Terraform IAM 정책, 바인딩 및 멤버십

terraform에서 정의한 바와 같이 https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam GCP와 함께 terraform을 사용하여 리소스에 대한 주체의 접근 권한을 부여하는 다양한 방법이 있습니다:

• 멤버십: 주체를 역할의 멤버로 설정하며 역할이나 주체에 대한 제한 없이 설정합니다. 사용자를 역할의 멤버로 설정한 다음, 같은 역할의 멤버로 그룹을 추가하고, 해당 주체(사용자 및 그룹)를 다른 역할의 멤버로 설정할 수 있습니다.

• 바인딩: 여러 주체를 역할에 바인딩할 수 있습니다. 이러한 주체는 여전히 다른 역할에 바인딩되거나 멤버가 될 수 있습니다. 그러나 역할에 바인딩되지 않은 주체가 바인딩된 역할의 멤버로 설정되면, 다음 번에 바인딩이 적용될 때 멤버십이 사라집니다.

• 정책: 정책은 권위 있는 것으로, 역할과 주체를 나타내며, 이러한 주체는 더 이상 역할을 가질 수 없고, 이러한 역할은 더 이상 주체를 가질 수 없습니다. 해당 정책이 수정되지 않는 한(다른 정책, 바인딩 또는 멤버십에서도 마찬가지입니다). 따라서 정책에 역할이나 주체가 지정되면 모든 권한이 해당 정책에 의해 제한됩니다. 명백히, 주체가 정책을 수정할 수 있는 옵션이나 권한 상승 권한(예: 새로운 주체를 생성하고 새로운 역할에 바인딩할 수 있는 권한)을 부여받는 경우에는 이를 우회할 수 있습니다.

References

• https://about.gitlab.com/blog/2020/02/12/plundering-gcp-escalating-privileges-in-google-cloud-platform/

• https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy