승인 및 액세스 제어

Google Distributed Cloud(GDC) 공기 간격의 Identity and Access Management(IAM)를 사용하면 리소스에 액세스할 수 있는 사용자와 해당 리소스에서 수행할 수 있는 작업을 제어할 수 있습니다.

GDC에서 IAM이 작동하는 방식을 이해하면 액세스를 효과적으로 관리하여 구성원이 역할을 수행하는 데 필요한 권한을 확보하는 동시에 에어 갭 환경의 보안을 유지할 수 있습니다.

이 문서는 GDC 에어 갭의 승인 및 액세스 제어를 이해하려는 플랫폼 관리자 및 애플리케이션 운영자 그룹 (예: IT 관리자, 보안 엔지니어 또는 애플리케이션 개발자)을 대상으로 합니다. 또한 이 문서는 인프라 운영자가 액세스 제어 개념에 대한 기본적인 이해를 쌓는 데 도움이 됩니다. 자세한 내용은 GDC 에어 갭 문서 대상을 참조하세요.

액세스 제어 모델

GDC는 구성원(누가), 역할(무엇을), 리소스 범위(어디에서)라는 세 가지 핵심 구성요소를 중심으로 액세스를 구조화합니다.

액세스 제어 모델

액세스 제어는 신원 증명(인증)과 수행 가능한 작업 결정 (승인)이라는 두 가지 단계로 구성됩니다.

  • 인증: GDC는 사용자 계정이나 비밀번호를 저장하지 않습니다. GDC는 조직의 ID 공급업체(IdP)에 연결되므로 기업 사용자 인증 정보로 로그인할 수 있습니다.
  • 승인: 인증 후 GDC IAM은 할당된 역할을 확인하여 액세스할 수 있는 리소스와 수행할 수 있는 작업을 결정합니다.

회원

구성원은 리소스 액세스 권한을 부여할 수 있는 ID입니다. GDC는 관리 위치에 따라 구성원을 인간 ID와 비인간 ID라는 두 가지 주요 카테고리로 그룹화합니다.

인간 ID

인간 ID는 GDC에 로그인하는 사용자와 그룹입니다. GDC는 사용자 계정이나 비밀번호를 저장하는 대신 OpenID Connect(OIDC) 또는 SAML 2.0과 같은 표준 ID 제휴 프로토콜을 사용하여 조직의 기존 로그인 시스템 또는 IdP(예: Active Directory, LDAP, Okta)에 연결합니다.

인간 ID에는 두 가지 유형이 있습니다.

  • 사용자: 회사 사용자 인증 정보를 사용하여 시스템에 로그인하는 개별 사용자입니다.
  • 그룹: 조직의 IdP 내에서 관리되는 사용자 모음입니다. 그룹에 역할을 부여하면 해당 그룹의 모든 구성원에게 자동으로 역할이 부여됩니다.

GDC는 IdP를 사용하여 인간 ID를 고유하게 식별합니다. 환경이 여러 IdP에 연결될 수 있으므로 (예: 부서마다 다른 로그인 시스템을 사용하는 경우) GDC는 IdP를 구분하여 올바른 사용자에게 액세스 권한을 부여합니다.

액세스를 관리할 때 GDC는 모든 외부 사용자 이름과 그룹에 고유한 IdP 프리픽스를 자동으로 추가합니다.

  • 형식: idpprefix-username@domain.com (또는 그룹의 경우 idpprefix-group-name)
  • 예시: 조직의 IdP가 agency-a 프리픽스로 구성되어 있고 alice@example.com로 로그인하면 GDC IAM에서 사용자를 agency-a-alice@example.com로 인식합니다.

인간 외의 ID

인간이 아닌 ID를 서비스 ID (또는 서비스 계정)라고 합니다. 애플리케이션, 스크립트 또는 자동화된 워크로드가 API와 안전하게 상호작용할 수 있도록 GDC 내에서 직접(ProjectServiceAccount 리소스로) 만들고 관리합니다.

서비스 계정은 GDC에서 내부적으로 관리되므로 IdP 프리픽스를 사용하지 않습니다. 대신 프로젝트 및 이름으로 식별됩니다 (예: gdcloud CLI를 사용하는 경우 serviceAccount:projectName:serviceAccountName).

자세한 내용은 서비스 계정 키 보안을 참조하세요.

권한 및 역할

권한은 리소스에 대해 특정 작업 (예: VM 만들기 또는 데이터베이스 삭제)을 수행할 수 있는 권한입니다. 구성원에게 권한을 직접 부여하지 않습니다. 대신 GDC는 권한을 역할로 번들로 묶습니다.

GDC는 두 가지 유형의 역할을 제공합니다.

  • 사전 정의된 역할: GDC에서 만들고 관리하는 기본 제공 권한 번들입니다. GDC는 특정 직무 및 서비스에 맞게 조정된 사전 정의된 역할의 포괄적인 라이브러리를 제공합니다(프로젝트 뷰어와 같은 광범위한 역할부터 버킷 프로젝트 관리자 또는 KMS 뷰어와 같은 세분화된 서비스 역할까지).
  • 커스텀 역할: 기존의 사전 정의된 역할이 조직의 요구사항을 충족하지 않는 경우 만들 수 있는 사용자 정의 권한 번들입니다.

IAM 역할을 통해 부여된 권한은 순수하게 가산적입니다. 액세스 권한을 부여하지만 거부 규칙은 포함하지 않습니다. 구성원에게 여러 역할을 부여하면 구성원은 해당 역할의 모든 권한을 합친 권한을 받습니다. 조직 전체에서 특정 서비스에 대한 액세스를 제한하거나 거부하려면 조직 정책을 설정하면 됩니다.

리소스 범위

항상 GDC 리소스 계층 구조의 특정 수준에서 액세스 권한을 부여합니다. 범위에 따라 구성원이 액세스할 수 있는 리소스가 결정됩니다. 멀티 영역 환경에서는 두 범위 중 하나에서 할당된 역할이 기본적으로 모든 영역에 자동으로 적용됩니다.

다음 리소스 범위에서 역할을 부여할 수 있습니다.

  • 조직: 환경의 최상위 컨테이너입니다. 조직 수준에서 부여된 역할은 조직 전체에 적용되며 조직 내의 모든 프로젝트와 리소스에 자동으로 상속됩니다.
  • 프로젝트: 특정 팀 또는 애플리케이션의 리소스를 그룹화하는 데 사용되는 조직 내 컨테이너입니다. 프로젝트는 엄격한 보안 경계 역할을 합니다. 프로젝트 수준에서 부여된 역할은 해당 특정 프로젝트와 해당 리소스 (예: 가상 머신, 데이터베이스, Kubernetes 클러스터)에만 적용됩니다.

자세한 내용은 리소스 계층 구조 및 멀티 영역 유니버스의 권한 제어를 참조하세요.

액세스 승인 방법

GDC는 주로 역할 기반 액세스 제어(RBAC) 모델을 사용하여 액세스를 관리하고 승인합니다. RBAC 모델에서는 개별 사용자 또는 워크로드에 직접 권한을 할당하지 않습니다. 대신 특정 리소스 범위에서 구성원에게 역할을 할당하여 액세스 권한을 결정합니다.

GDC는 다음 Kubernetes 커스텀 리소스를 사용하여 RBAC를 구현합니다.

  • IAMRole: 특정 권한 번들을 정의합니다.
  • IAMRoleBinding: 구성원 (사람 사용자, 그룹 또는 서비스 계정)을 조직 또는 프로젝트 범위의 IAMRole에 연결합니다.

조직 또는 프로젝트 리소스에 대한 액세스 권한을 부여하려면 GDC 콘솔, gdcloud CLI를 사용하거나 kubectl CLI를 사용하여 커스텀 리소스 매니페스트 (YAML 파일)를 적용하여 IAMRoleBinding를 만들면 됩니다.

예를 들어 팀 구성원이 프로젝트 내에서 가상 머신을 볼 수 있도록 하려면 해당 프로젝트 범위에서 구성원의 ID를 뷰어 역할에 연결하는 IAMRoleBinding을 만들면 됩니다. 구성원이 가상 머신을 보려고 하면 GDC는 활성 역할 바인딩을 확인하고 할당된 역할에 필요한 권한이 포함되어 있는지 확인한 후 요청을 승인합니다.

GDC 콘솔과 gdcloud CLI는 리소스에 자동으로 연결되지만 kubectl CLI를 사용한 직접 API 액세스에는 kubeconfig 파일을 생성하여 해당 리소스를 호스팅하는 특정 Kubernetes 클러스터 또는 API 서버에 인증해야 합니다. 자세한 내용은 로그인 및 kubeconfig 파일 생성을 참조하세요.

역할 바인딩 관리에 대한 자세한 내용은 액세스 권한 부여 및 취소를 참조하세요.

GDC(에어 갭 적용형) IAM과 Google Cloud의 차이점

Google Cloud에서 액세스를 관리한 경험이 있는 경우 GDC는 유사한 개념을 사용하지만 에어 갭 적용 Kubernetes 기반 인프라 내에서 작동하도록 다르게 구현합니다.

다음 표에서는 GDC의 IAM과 Google Cloud를 비교합니다.

기능 설명 GDC(에어 갭 적용형) Google Cloud
사용자 ID (인증) 사람 사용자를 인증하는 데 사용되는 ID 시스템입니다. 필수 IdP 프리픽스 (예: idpprefix-user@domain.com)를 사용하여 외부 IdP와 제휴됩니다. Google 계정 (예: Gmail) 또는 Cloud ID나 Google Workspace를 통해 제휴된 회사 ID
승인 엔진 권한을 평가하고 시행하는 기본 시스템입니다. 주로 Kubernetes 역할 기반 액세스 제어 (RBAC)로, API 서버가 역할 바인딩에 대해 액세스 요청을 로컬에서 평가합니다. 조직 정책을 사용하여 리소스 제한을 설정할 수 있습니다. Google의 전역 Cloud IAM 서비스 리소스 계층 구조의 모든 수준에 연결된 액세스 정책을 기준으로 API 요청을 중앙에서 평가합니다.
역할 바인딩 구성원이 특정 리소스의 역할에 매핑되는 방식 개별 IAMRoleBinding 커스텀 리소스 각 바인딩은 구성원을 하나의 역할에 연결하는 객체입니다. IAM 역할 권한은 순수하게 가산적입니다(거부 규칙은 조직 정책을 통해 별도로 구성할 수 있음). 각 리소스, 폴더 또는 조직에 연결된 단일 IAM 액세스 정책입니다. 구성원을 역할에 매핑하는 여러 바인딩을 포함하며 조건부 규칙 또는 거부 규칙을 지원합니다.
서비스 계정 애플리케이션 및 자동화된 워크로드에서 사용하는 인간 외의 ID입니다. 특정 프로젝트(ProjectServiceAccount) 내에서 생성된 로컬 서비스 계정입니다. 공개 키는 클러스터에 저장되고 비공개 키는 클라이언트가 로컬에서 관리하고 보호합니다. Google에서 중앙 집중식으로 관리하는 전역 ID입니다. 사용자 인증 정보는 Google에서 자동으로 관리하거나 키 파일로 다운로드하여 어디서나 인증할 수 있습니다.
리소스 계층 구조 리소스를 구성하고 권한을 상속하는 데 사용되는 컨테이너 구조입니다. 2계층 구조: 조직 > 프로젝트 다중 계층 구조: 조직 > 폴더 > 프로젝트
멀티 영역 권한 범위 가용성 영역 또는 리전에서 권한이 평가되고 전파되는 방식 전역 API 서버에서 관리하는 Kubernetes RBAC를 사용합니다. 이 서버는 영역 API 서버 간에 역할 바인딩을 조정하고 복제하므로 기본적으로 모든 영역에 액세스가 적용됩니다. 완전 관리형 글로벌 IAM 서비스를 사용합니다. 리소스 수준에서 할당된 권한은 본질적으로 전역적이며 모든 리전과 영역에 자동으로 적용됩니다.
클라이언트 도구 액세스를 관리하는 데 사용되는 기본 인터페이스, CLI 도구, API GDC 콘솔, gdcloud CLI, KRM API Google Cloud 콘솔, gcloud CLI, REST 또는 gRPC API를 사용합니다.
직접 API 액세스 도구 및 스크립트가 API를 사용하여 리소스를 직접 관리하기 위해 인증하는 방법 kubectl CLI를 사용하여 API에 직접 액세스하려면 kubeconfig 파일을 생성하여 해당 리소스를 호스팅하는 특정 Kubernetes 클러스터 또는 API 서버에 인증해야 합니다. (GDC 콘솔 및 gdcloud CLI는 리소스에 자동으로 연결됩니다.) gcloud 또는 REST/gRPC 엔드포인트를 사용하는 직접 API 액세스는 클러스터별 로그인 없이 모든 서비스에 전역적으로 적용되는 중앙 집중식 사용자 인증 정보(gcloud auth login)를 사용합니다.

다음 단계