디자인 권한 설정

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

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

조직별 ID 공급업체 구성

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

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

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

ID 공급업체의 다중 인증(MFA) 구성

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

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

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

프로젝트에서 서비스 액세스를 거부하려면 서비스의 커스텀 리소스 정의와 네임스페이스 목록에 Gatekeeper 제약조건을 적용합니다. Gatekeeper를 사용하여 액세스를 거부하는 방식은 관리형 서비스와 마켓플레이스 서비스에 적용됩니다.

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

운영 태스크에 따라 다른 클러스터에 연결해야 합니다. 예를 들어 IAM 역할을 프로젝트에 바인딩하는 작업과 Kubernetes 클러스터에 Kubernetes Pod 리소스를 배포하는 작업을 수행합니다.

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

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

Kubernetes 서비스 계정 권장사항

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

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

최소 권한의 원칙 고려

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

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

과도한 권한이 있는지 정기적으로 감사

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

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