이 가이드를 읽기 전에 Fleet 워크로드에서 API 및 서비스에 인증에 설명된 개념을 숙지해야 합니다.
다른 Fleet 기능 채택에 대한 권장사항은 Fleet 기능 계획을 참조하세요.
Fleet 및 프로젝트 ID 풀
특히 다중 프로젝트 Fleet을 사용할 때 Fleet 전체 워크로드 아이덴티티 제휴를 신중하게 채택해야 하는 이유를 이해하기 위해 GKE용 일반 워크로드 아이덴티티 제휴 및 Fleet 워크로드 아이덴티티 제휴의 작동 방식을 자세히 살펴보겠습니다. 두 경우 모두 클러스터에서 생성된 단기 토큰을 사용하여 워크로드가 인증되며, 각 클러스터가 특수 워크로드 아이덴티티 풀에 ID 공급업체로 추가됩니다. 그러면 특정 네임스페이스에서 실행되는 워크로드는 클러스터 전반에서 동일한 IAM ID를 공유할 수 있습니다.
클러스터에 사용 설정된 경우 GKE용 일반 워크로드 아이덴티티 제휴에서 다음과 같은 상황이 발생합니다. 참고로 GKE용 워크로드 아이덴티티 제휴는 기본적으로 Autopilot 클러스터에 사용 설정되어 있습니다.
- GKE는 클러스터의 프로젝트
PROJECT_ID.svc.goog.id에 Google 관리형 워크로드 아이덴티티 풀을 만듭니다. - GKE는 클러스터를 풀에 ID 공급업체로 추가합니다.
- 따라서 특정 네임스페이스에서 실행되는 워크로드는 한 프로젝트 내 클러스터에서 동일한 IAM ID를 공유합니다. ID는
serviceAccount:PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME]형식입니다.
Autopilot 클러스터, 이 기능이 명시적으로 사용 설정된 Standard 클러스터, Google Cloud 외부의 GKE 클러스터를 비롯하여 GKE용 워크로드 아이덴티티 제휴가 사용 설정된 클러스터를 Fleet에 추가하면 Fleet 전체 워크로드 아이덴티티 제휴가 자동으로 사용 설정됩니다.
사용자가 GKE용 워크로드 아이덴티티 제휴가 사용 설정된 클러스터를 Fleet에 등록하면 다음과 같은 상황이 발생합니다.
- 풀이 아직 없는 경우 Fleet 호스트 프로젝트에 Google 관리형 Fleet 전체 워크로드 아이덴티티 풀
FLEET_PROJECT_ID.svc.goog.id가 생성됩니다. Fleet 호스트 프로젝트의 프로젝트 워크로드 아이덴티티 풀과 동일합니다. - 클러스터가 풀에 ID 공급업체로 추가됩니다.
- 따라서 특정 네임스페이스에서 실행되는 워크로드는 Fleet 내의 클러스터 간에 동일한 IAM ID를 공유합니다. 이를 Fleet 워크로드 아이덴티티의 암시적 동일성이라고 합니다. ID는
serviceAccount:FLEET_PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME]형식입니다. 그러면 여러 프로젝트의 Fleet 워크로드가 인증에 동일한 ID를 사용하여 Google API를 호출할 수 있습니다.
즉, Fleet에 한 프로젝트의 클러스터만 포함되어 있고 모두 해당 Fleet에 등록된 경우 Fleet 없이 GKE용 워크로드 아이덴티티 제휴만 사용하는 것과 동일한 결과가 나타납니다. 모든 클러스터는 프로젝트 전체 워크로드 아이덴티티 풀에 있는 ID 제공업체이며 워크로드는 GKE용 워크로드 아이덴티티 제휴에서 사용하는 것과 동일한 ID를 사용합니다. 하지만 이 Fleet이 여러 프로젝트에 구성원 클러스터가 있는 경우 Fleet 워크로드 아이덴티티 제휴는 프로젝트별 ID 풀을 Fleet 호스트 프로젝트에서 호스팅되는 단일 Fleet 전체 ID 풀에 결합합니다.
다음 예에서 볼 수 있듯이 프로젝트의 클러스터 집합과 해당 프로젝트의 Fleet 구성원인 클러스터 집합이 부분적으로만 겹치는 경우 약간의 복잡성이 발생할 수 있습니다.
시나리오 1: 모든 클러스터가 등록된 단일 프로젝트 Fleet
이 시나리오에서 Fleet의 모든 구성원 클러스터는 Fleet 호스트 프로젝트에 있고 해당 프로젝트의 모든 클러스터는 Fleet의 구성원입니다.
이전 섹션에서 설명한 대로 이 시나리오에서 Fleet 전체 워크로드 아이덴티티 제휴를 사용하는 것은 GKE용 일반 워크로드 아이덴티티 제휴를 사용하는 것과 동일하며 추가적인 위험이 없습니다.
시나리오 2: 일부 클러스터가 등록된 단일 프로젝트 Fleet
이 시나리오에서는 Fleet에 Fleet 호스트 프로젝트인 프로젝트 1에 있는 2개의 클러스터가 포함됩니다. Fleet 호스트 프로젝트에는 Fleet 구성원이 아닌 세 번째 클러스터도 포함되어 있으며, 이 클러스터에는 GKE용 워크로드 아이덴티티 제휴가 사용 설정되어 있습니다.
다시 말하면 다음과 같습니다.
- 클러스터 1, 2, 3이 GKE에 의해 프로젝트 워크로드 아이덴티티 풀
project-1.svc.goog.id에 추가됩니다. - 클러스터 1과 2는 Fleet에 의해 Fleet 워크로드 아이덴티티 풀에 추가됩니다. (Fleet 호스트 프로젝트이므로) 이는 프로젝트 워크로드 아이덴티티 풀
project-1.svc.goog.id이기도 합니다.
관리자가 Fleet의 모든 클러스터에 있는 네임스페이스에서 실행되는 워크로드에 권한을 부여하려고 합니다. serviceAccount:project-1.svc.goog.id[namespace/ksa]를 ID로 사용하여 액세스 권한을 부여합니다. 하지만 Fleet에 속하지 않는 클러스터 3의 해당 네임스페이스에 있는 워크로드가 이제 동일한 액세스 권한을 공유합니다. 이는 클러스터 3이 프로젝트 워크로드 아이덴티티 풀에 있고 이 풀이 (Fleet 호스트 프로젝트이므로) Fleet 워크로드 아이덴티티 풀과 동일하기 때문입니다. 즉, 관리자가 Fleet의 클러스터에만 권한을 부여하려고 할 수 있지만 Fleet 워크로드 아이덴티티 제휴가 구현되어 있으므로 Fleet 외부 클러스터도 액세스 권한을 얻을 수 있습니다.
가능한 완화 조치
여기서 가능한 한 가지 해결 방법은 클러스터가 없는 Fleet을 호스팅하는 전용 프로젝트를 만들고 컨테이너 API의 커스텀 조직 정책으로 시행하는 것입니다. 이렇게 하면 Fleet 워크로드 아이덴티티 풀 트러스트 도메인을 GKE 프로젝트 수준 트러스트 도메인과 명확하게 구분할 수 있습니다.
그러면 관리자가 워크로드에 권한을 부여할 때 적절한 트러스트 도메인을 선택할 수 있습니다. 예를 들어 serviceAccount:project-0.svc.goog.id[namespace/ksa]를 사용하여 Fleet에서 네임스페이스 범위 워크로드에 권한을 부여할 수 있습니다. Fleet 구성원이 아닌 클러스터 3은 이 설정에서 해당 워크로드 아이덴티티 풀의 일부가 아니므로 액세스 권한을 얻지 못합니다.
이 솔루션은 Google Cloud의 클러스터와 연결된 클러스터에 사용할 수 있습니다.
시나리오 3: 일부 클러스터가 등록된 다중 프로젝트 Fleet
이 시나리오에서는 Fleet에 프로젝트 1과 프로젝트 2라는 두 프로젝트의 구성원이 있습니다.
관리자가 GKE용 일반 워크로드 아이덴티티 제휴를 사용하여 프로젝트 1의 모든 클러스터에 있는 네임스페이스에서 실행되는 워크로드에 권한을 부여하려고 합니다. 하지만 클러스터 4가 Fleet에 등록되었고 프로젝트 1이 Fleet 호스트 프로젝트이므로 프로젝트 2에 있는 클러스터 4의 워크로드도 동일한 권한을 갖습니다.
가능한 완화 조치
이전 시나리오와 마찬가지로 클러스터가 없는 전용 Fleet 호스트 프로젝트를 만드는 것이 좋습니다. 이 경우에도 이렇게 하면 액세스 제어를 설정할 때 관리자가 Fleet ID 풀과 각 클러스터의 프로젝트 ID 풀의 ID를 구분할 수 있습니다.
시나리오 4: 네임스페이스 동일성 고려
워크로드 아이덴티티 제휴를 사용할 때 혼란을 야기할 수 있는 영역은 워크로드 아이덴티티 풀만이 아닙니다. Fleet 기능 계획에서 알 수 있듯이 Fleet 워크로드 아이덴티티 제휴를 비롯한 많은 Fleet 기능이 네임스페이스 동일성 가정을 사용하여 Fleet의 구성 및 관리를 간소화합니다. 즉, 이 기능은 여러 Fleet 구성원 클러스터에서 이름이 같은 네임스페이스를 동일한 네임스페이스인 것처럼 취급합니다. 이 예에서는 관리자가 Fleet 구성원 클러스터인 클러스터 1 및 클러스터 2에서 실행되는 NS1 네임스페이스의 워크로드에 권한을 부여했습니다.
하지만 사용자가 실수로 또는 악의적으로 다른 Fleet 구성원 클러스터에서 동일한 이름으로 네임스페이스를 만들었습니다. 네임스페이스 동일성을 가정하기 때문에 해당 네임스페이스의 워크로드가 클러스터 1 및 클러스터 2의 적법한 NS1 워크로드와 동일한 권한을 자동으로 얻습니다.
가능한 완화 조치
신뢰할 수 있는 소규모 역할 그룹만 클러스터에서 네임스페이스를 만들 수 있도록 권한을 설정합니다.