이 페이지는 플랫폼 관리자, 운영자, Fleet의 ID 동일성과 관련된 위험을 최소화하려는 보안 엔지니어를 대상으로 합니다.
이 페이지를 읽기 전에 Fleet 워크로드 아이덴티티 제휴 정보의 개념을 숙지해야 합니다.
용어
이 페이지에서는 다음 용어를 사용합니다.
- GKE용 워크로드 아이덴티티 제휴: 단일 Google Cloud 프로젝트에서 GKE 워크로드에 아이덴티티를 제공하는 기능입니다.
- Fleet 워크로드 아이덴티티 제휴: GKE용 워크로드 아이덴티티 제휴를 Google Cloud외부 및 여러 프로젝트를 비롯한 전체 Fleet의 워크로드로 확장하는 기능입니다.
- 워크로드 아이덴티티 풀: ID 및 액세스 관리 (IAM)와 호환되는 형식으로 워크로드에 ID를 제공하는 항목입니다. 각 클러스터는 워크로드 아이덴티티 풀의 ID 공급업체입니다.
Fleet의 ID 동일성
워크로드 아이덴티티 풀은 요청을 인증하고 승인할 때 IAM이 사용할 수 있는 형식으로 워크로드에 ID를 제공하는 항목입니다. GKE용 워크로드 아이덴티티 제휴를 사용하면 모든 프로젝트에는 기본적으로 해당 프로젝트에 고유한 고정된 Google 관리 워크로드 아이덴티티 풀이 있습니다.
Fleet 워크로드 아이덴티티 제휴를 사용하면 클러스터가 다른 프로젝트에 있는지 또는 다른 클라우드에 있는지에 관계없이 Fleet에 등록하는 모든 클러스터의 기본 워크로드 아이덴티티 풀이 Fleet 호스트 프로젝트의 Google 관리 워크로드 아이덴티티 풀이 됩니다. 원하는 경우 기본 풀 대신 사용할 특정 클러스터의 자체 관리형 워크로드 아이덴티티 풀을 설정할 수 있습니다.
Fleet 워크로드 아이덴티티 제휴와 GKE용 워크로드 아이덴티티 제휴 모두에서 IAM 허용 정책을 사용하여 Kubernetes ServiceAccount 또는 포드와 같은 클러스터의 항목에 특정 Google Cloud리소스에 대한 역할을 부여합니다. 허용 정책에서 IAM이 읽을 수 있는 명명 구문인 주 구성원 식별자를 사용하여 이러한 항목을 참조합니다. 주 구성원 식별자에는 클러스터에서 사용하는 워크로드 아이덴티티 풀의 이름과 클러스터에서 특정 항목을 선택하는 기타 정보가 포함됩니다. 예를 들어 다음 주 구성원 식별자는 네임스페이스의 Kubernetes ServiceAccount를 선택합니다.
principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_IDENTITY_POOL_NAME/subject/ns/NAMESPACE/sa/SERVICEACCOUNT
이 예시에서 다음 필드에는 주 구성원에 관한 정보가 있습니다.
PROJECT_NUMBER: Fleet 호스트 프로젝트의 프로젝트 번호WORKLOAD_IDENTITY_POOL_NAME: 워크로드 아이덴티티 풀의 이름입니다.NAMESPACE: 네임스페이스의 이름SERVICEACCOUNT: Kubernetes ServiceAccount의 이름입니다.
Google Cloud API에 대한 요청은 클러스터에서 생성하는 수명이 짧은 OAuth 2.0 액세스 토큰을 사용하여 인증됩니다. 이러한 액세스 토큰에는 요청을 만든 항목의 주 구성원 식별자가 포함됩니다. IAM은 주 구성원 식별자를 사용하여 허용 정책이 요청된 작업을 수행하도록 엔티티를 승인하는지 확인합니다.
멀티테넌트 Fleet의 ID 동일성 영향
주 구성원 식별자는 ID 동일성을 야기합니다. 즉, 특정 주 구성원 식별자와 일치하는 환경의 모든 항목은 IAM에서 동일한 것으로 간주됩니다. 단일 프로젝트 GKE용 워크로드 아이덴티티 제휴를 사용하면 해당 프로젝트에서 주 구성원 식별자를 공유하는 모든 엔티티에 ID 동일성이 적용됩니다. 하지만 Fleet 워크로드 아이덴티티 제휴를 사용하면 이 ID 동일성이 클러스터 프로젝트와 관계없이 전체 Fleet에서 기본 식별자를 공유하는 모든 항목에 적용됩니다.
예를 들어 이전 섹션의 주 구성원 식별자를 사용하면 동일한 ServiceAccount, 동일한 네임스페이스, 동일한 워크로드 아이덴티티 풀을 사용하는 포드의 요청은 클러스터나 프로젝트와 관계없이 동일한 주 구성원 식별자를 가져옵니다.
Fleet이 Fleet 호스트 프로젝트의 클러스터만 실행하는 경우 아이덴티티 동일성 영향은 GKE용 워크로드 아이덴티티 제휴와 동일합니다. 하지만 Fleet에 다른 프로젝트에서 실행되는 클러스터가 있는 경우 ID 동일성이 Fleet에 등록된 모든 클러스터로 확장됩니다.
Fleet ID 동일성의 복잡성 예시
다음 예시 시나리오에서는 Fleet 워크로드 아이덴티티 제휴를 구현할 때 발생할 수 있는 잠재적인 ID 동일성 복잡성을 설명합니다. 각 시나리오에서는 이러한 복잡성을 탐색하는 데 도움이 될 수 있는 가능한 완화 방법을 제공합니다.
모든 클러스터가 등록되고 동일한 워크로드 아이덴티티 풀이 있는 단일 프로젝트 Fleet
다음 플릿 구성을 고려하세요.
- Fleet의 모든 구성원 클러스터가 Fleet 호스트 프로젝트에 있습니다.
- 프로젝트의 모든 클러스터가 Fleet의 구성원입니다.
- 모든 클러스터가 동일한 워크로드 아이덴티티 풀을 사용합니다.
이 시나리오에서는 Fleet의 모든 구성원 클러스터가 Fleet 호스트 프로젝트에 있으며 해당 프로젝트의 모든 클러스터가 Fleet의 구성원입니다.
Fleet의 ID 동일성 영향 섹션에서 설명한 대로 이 시나리오에서 Fleet 워크로드 아이덴티티 제휴를 사용하는 것은 GKE용 워크로드 아이덴티티 제휴를 사용하는 것과 동일하며 추가적인 위험이 없습니다.
일부 클러스터가 등록되고 동일한 워크로드 ID 풀이 있는 단일 프로젝트 Fleet
다음 플릿 구성을 고려하세요.
- Fleet에는 Fleet 호스트 프로젝트에서 실행되는 두 개의 클러스터가 포함됩니다.
- Fleet 호스트 프로젝트에 Fleet 구성원이 아닌 세 번째 클러스터가 포함되어 있습니다.
- Fleet 구성원이 아닌 클러스터에도 GKE용 워크로드 아이덴티티 제휴가 사용 설정되어 있습니다.
- 프로젝트의 모든 클러스터가 동일한 워크로드 아이덴티티 풀을 사용합니다.
이 구성을 사용하면 프로젝트의 한 클러스터에 있는 항목에 부여한 역할이 주 구성원 식별자와 일치하는 프로젝트의 다른 항목에 적용됩니다. 이로 인해 차량의 일부가 아닌 항목에 의도치 않게 권한이 부여될 수 있습니다. 예를 들어 네임스페이스에서 특정 서비스 계정을 선택하는 주 구성원 식별자에 역할을 부여하면 다음과 같은 의미가 있습니다.
- 지정된 네임스페이스에서 실행되고 Fleet 구성원 클러스터에서 지정된 서비스 계정을 사용하는 워크로드가 액세스 권한을 공유합니다.
- 동일한 네임스페이스와 서비스 계정 이름을 사용하는 세 번째 비회원 클러스터에서 실행되는 워크로드도 동일한 액세스 권한을 받습니다.
다음 제안이 이러한 복잡성을 해결하는 데 도움이 될 수 있습니다.
- 자체 관리형 워크로드 아이덴티티 풀 (미리보기)을 사용하도록 Fleet 구성원 클러스터를 구성합니다. 이렇게 하면 Fleet 구성원 클러스터의 항목이 비구성원 클러스터와 다른 주 구성원 식별자를 갖게 됩니다. 자세한 내용은 혼합된 신뢰 Fleet 워크로드에서 Google Cloud API에 인증을 참고하세요.
전용 Fleet 호스트 프로젝트를 만들고 조직 정책을 사용하여 전용 Fleet 호스트 프로젝트에서 클러스터를 실행하지 못하도록 합니다. 이렇게 하면 Fleet 전체 워크로드 아이덴티티 풀 트러스트 도메인이 GKE 프로젝트 수준 트러스트 도메인과 분리됩니다. 등록된 클러스터만 Fleet 전체 워크로드 아이덴티티 풀을 공유합니다.
이러한 제안은 Google Cloud 의 클러스터와 연결된 클러스터에 적용됩니다.
일부 클러스터가 등록되고 동일한 워크로드 아이덴티티 풀이 있는 다중 프로젝트 Fleet
다음 플릿 구성을 고려하세요.
- Fleet에는
project-1및project-2라는 두 프로젝트에서 실행되는 구성원 클러스터가 포함됩니다. Google Cloud project-1는 Fleet 호스트 프로젝트입니다.project-1의 모든 클러스터는 Fleet 구성원입니다.project-2에는 Fleet 구성원 클러스터 1개와 미등록 클러스터 1개가 포함되어 있습니다.project-1의 모든 클러스터는 프로젝트의 Google 관리 워크로드 아이덴티티 풀을 사용하며, 이는 기본 Fleet 전체 워크로드 아이덴티티 풀이기도 합니다.project-2의 Fleet 구성원 클러스터는 Fleet 전체 워크로드 아이덴티티 풀을 사용합니다.
이 시나리오에서는 Fleet 호스트 프로젝트의 항목에 부여하는 모든 권한이 project-2의 멤버 클러스터에 있는 항목에도 적용됩니다. 이는 모든 항목이 동일한 워크로드 아이덴티티 풀을 공유하기 때문입니다.
이 복잡성을 해결하려면 Fleet 호스트 프로젝트로 사용할 전용 Google Cloud 프로젝트를 만드세요. 그러면 project-1 및 project-2의 Fleet 구성원 클러스터가 기본적으로 전용 프로젝트의 워크로드 아이덴티티 풀을 공유합니다. 그런 다음 주 구성원 식별자에서 project-1의 워크로드 아이덴티티 풀을 사용하여 project-1의 클러스터에 프로젝트 범위 액세스 권한을 부여할 수 있습니다.
유사한 ID 생성 방지
Fleet의 ID 동일성을 위해서는 의도적이거나 의도치 않은 유사한 ID 생성을 방지하기 위해 액세스 제어를 신중하게 구현해야 합니다. 예를 들어 네임스페이스에서 특정 ServiceAccount를 사용하는 모든 포드에 액세스 권한을 부여하는 시나리오를 생각해 보세요. 다른 Fleet 구성원 클러스터에서 해당 네임스페이스와 ServiceAccount를 만드는 경우 해당 클러스터의 포드에 동일한 액세스 권한이 부여됩니다.
이 문제가 발생할 가능성을 줄이려면 승인 메커니즘을 사용하여 신뢰할 수 있는 사용자 집합만 네임스페이스와 Kubernetes 서비스 계정을 만들거나 업데이트하거나 삭제하도록 허용하세요.
IAM의 경우 다음 권한이 이 액세스 권한을 제공합니다.
container.namespaces.*container.serviceAccounts.*
Kubernetes 역할 기반 액세스 제어 (RBAC)의 경우 다음 예시 ClusterRole은 이러한 Kubernetes 리소스와 상호작용하기 위한 특별한 액세스를 구성합니다.
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: namespace-admin rules: - apiGroups: [""] resources: ["namespaces"] verbs: ["create","delete","update","patch"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: serviceaccount-admin rules: - apiGroups: [""] resources: ["serviceaccounts"] verbs: ["create","delete","update","patch","impersonate"]