승인 및 액세스 제어

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와 페더레이션됩니다. Gmail과 같은 Google 계정 또는 Cloud ID 또는 Google Workspace를 통해 페더레이션된 회사 ID입니다.
승인 엔진 권한을 평가하고 적용하는 기본 시스템입니다. 주로 Kubernetes 역할 기반 액세스 제어 (RBAC)입니다. 여기서 액세스 요청은 API 서버에서 역할 바인딩에 대해 로컬로 평가됩니다. 조직 정책을 사용하여 리소스 제한을 설정할 수 있습니다. Google의 전역 Cloud IAM 서비스입니다. 리소스 계층 구조의 모든 수준에서 연결된 액세스 정책에 대해 API 요청을 중앙에서 평가합니다.
역할 바인딩 구성원이 특정 리소스의 역할에 매핑되는 방식입니다. 개별 IAMRoleBinding 커스텀 리소스입니다. 각 바인딩 은 구성원을 하나의 역할에 연결하는 객체입니다. IAM 역할 권한은 완전히 가산적입니다 (거부 규칙은 조직 정책을 통해 별도로 구성할 수 있음). 각 리소스, 폴더 또는 조직에 연결된 단일 IAM 액세스 정책입니다. 구성원을 역할에 매핑하는 여러 바인딩을 포함하며 조건부 규칙 또는 거부 규칙을 지원합니다.
서비스 계정 애플리케이션 및 자동화된 워크로드에서 사용되는 인간 외의 ID입니다. 특정 프로젝트(ProjectServiceAccount) 내에서 생성된 로컬 서비스 계정입니다. 공개 키는 클러스터에 저장되고 비공개 키는 클라이언트에서 로컬로 관리되고 보호됩니다. Google에서 중앙에서 관리하는 전역 ID입니다. 사용자 인증 정보는 Google에서 자동으로 관리하거나 키 파일로 다운로드하여 어디서나 인증할 수 있습니다.
리소스 계층 구조 리소스를 구성하고 권한을 상속하는 데 사용되는 컨테이너 구조입니다. 2단계 계층 구조: 조직 > 프로젝트 다단계 계층 구조: 조직 > 폴더 > 프로젝트
멀티 영역 권한 범위 권한이 가용성 영역 또는 리전에서 평가되고 전파되는 방식입니다. 영역 API 서버에서 역할 바인딩을 조정하고 복제하여 기본적으로 모든 영역에 액세스 권한이 적용되도록 하는 전역 API 서버에서 관리하는 Kubernetes RBAC를 사용합니다. 완전 관리형 전역 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)를 사용합니다.

다음 단계