디자인 권한 설정

이 문서에서는 Google Distributed Cloud (GDC) 에어 갭 환경에서 권한 부여 설계에 관한 권장사항을 설명합니다. 여기서 다루는 주제는 다음과 같습니다.

다음 설계가 권장되지만 규정된 대로 정확하게 따를 필요는 없습니다. 각 GDC 환경에는 사례별로 충족해야 하는 고유한 요구사항과 고려사항이 있습니다.

조직별 ID 공급업체 구성

운영자는 조직당 하나 이상의 ID 공급업체를 구성해야 합니다. 그러면 관리자가 ID 프로바이더에 연결하여 GDC 환경의 애플리케이션에 대한 인증 서비스를 관리합니다.

회사에 별도의 조직이 있는 여러 부서가 있고 각 조직이 인증을 위해 동일한 ID 프로바이더에 연결되는 시나리오가 있을 수 있습니다. 이 경우 사용자가 조직 전반에서 보유한 권한 조합을 파악하고 감사하는 것은 사용자의 책임입니다. 여러 조직에서 권한이 있는 사용자가 워크로드를 별도의 조직으로 분리하기 위한 요구사항을 위반하지 않도록 합니다.

또는 여러 공급업체팀이 단일 조직에서 함께 작업하는 경우와 같이 서로 다른 사용자 집합이 서로 다른 ID 공급업체를 사용하여 단일 조직 내에서 인증하는 시나리오가 있을 수 있습니다. 사용자 ID를 단일 ID 공급업체로 통합하거나 별도의 ID 공급업체를 유지하는 것이 회사의 ID 관리 접근방식에 가장 적합한지 고려합니다.

ID 공급업체에 다중 인증 구성

GDC는 다중 인증과 같은 추가 보안 설정을 포함하여 인증을 위해 IAM 플랫폼을 사용합니다. 민감한 리소스에 액세스할 수 있는 모든 사용자에 대해 실제 키로 다중 인증을 구성하는 것이 좋습니다.

관리형 서비스 및 Marketplace 서비스 제한

프로젝트에서 잠재적인 공격 노출 영역을 제한하거나 승인되지 않은 서비스의 사용을 방지하기 위해 특정 서비스에서 일부 프로젝트를 차단하는 것이 좋습니다. 기본적으로 인공지능 및 머신러닝과 같은 관리형 서비스는 모든 프로젝트에서 사용할 수 있습니다. 관리형 서비스와 비교하여 Marketplace 서비스는 먼저 조직에 사용 설정해야 합니다.

프로젝트에서 서비스 액세스를 거부하려면 서비스의 커스텀 리소스 정의 및 네임스페이스 목록에 대해 Gatekeeper 제약 조건을 적용합니다. Gatekeeper로 액세스를 거부하는 접근방식은 관리형 서비스 및 Marketplace 서비스에 적용됩니다.

여러 클러스터의 kubeconfig 파일 관리

운영 작업마다 서로 다른 클러스터에 연결해야 합니다. 예를 들어 IAM 역할을 프로젝트에 바인딩하는 작업과 Kubernetes 클러스터에 Kubernetes Pod 리소스를 배포하는 작업이 있습니다.

GDC 콘솔을 사용하는 경우 GDC 콘솔이 클러스터에 연결하는 것과 같은 하위 수준 작업을 추상화하므로 작업이 수행되는 기본 클러스터를 알 필요가 없습니다.

하지만 gdcloud CLI 또는 kubectl CLI를 사용하는 경우 작업을 완료하기 위해 여러 kubeconfig 파일이 있을 수 있습니다. 작업에 적합한 클러스터의 kubeconfig 사용자 인증 정보를 사용하여 로그인해야 합니다.

Kubernetes 서비스 계정 권장사항

Kubernetes 서비스 계정의 경우 승인은 보안 비밀 토큰을 기반으로 합니다. 서비스 계정 토큰의 위험을 완화하려면 다음 권장사항을 고려하세요.

  • GDC 외부에서 사용할 영구 서비스 계정 사용자 인증 정보를 다운로드하지 마세요.
  • 포드를 만들고 수정할 수 있는 사용자 또는 서비스 계정의 Kubernetes 에스컬레이션 경로 를 알고 있어야 합니다.
  • 워크로드의 서비스 계정 토큰 프로젝션에 대해 expirationSeconds 필드를 짧은 기간으로 설정합니다.
  • 서비스 계정 사용자 인증 정보를 정기적으로 순환합니다.

최소 권한의 원칙 고려

사용자에게 역할 바인딩을 부여할 때는 최소 권한의 원칙 (PoLP)을 고려하세요. PoLP에 따라 작업을 완료하는 데 필요한 권한만 할당하는 것이 좋습니다.

예를 들어 사용자가 해당 프로젝트 내에서 역할을 부여할 권한을 위임하도록 단일 프로젝트 내에서 사용자에게 프로젝트 IAM 관리자 역할을 부여합니다. 그러면 이 사용자는 사용하는 특정 서비스를 기반으로 프로젝트의 다른 개발자에게 세분화된 역할을 부여합니다. 프로젝트 IAM 관리자 역할은 신뢰할 수 있는 리드로 제한해야 합니다. 이 역할은 권한을 에스컬레이션하여 자신 또는 다른 사용자에게 프로젝트에서 추가 역할을 부여하는 데 사용될 수 있기 때문입니다.

과도한 권한에 대한 정기 감사

조직 내에서 부여된 역할을 검토하고 과도한 권한에 대해 감사해야 합니다. 부여된 역할이 개별 사용자가 작업을 완료하는 데 필요하며 프로젝트 전반의 역할 조합이 에스컬레이션 또는 유출 위험으로 이어지지 않도록 해야 합니다.

회사에서 여러 조직을 사용하는 경우 개별 사용자가 여러 조직에서 높은 권한이 있는 역할을 보유하는 것은 권장되지 않습니다. 이는 조직을 분리하는 이유를 위반할 수 있기 때문입니다.