특수 사례 처리

이 주제에서는 프로젝트 마이그레이션과 관련된 특수 사례를 처리하는 방법을 설명합니다.

조직 리소스가 없는 프로젝트 마이그레이션

조직 리소스와 연결되지 않은 프로젝트를 조직 리소스로 마이그레이션할 수 있습니다. 하지만 이 프로세스를 사용해서 이를 다시 조직 없음으로 변경할 수는 없습니다. 조직 리소스와 연관된 프로젝트가 있고 이를 다시 조직 없음으로 되돌리려면 해당 지원 담당자에게 연락하여 도움을 요청하세요.

프로젝트의 상위 조직 리소스에 대한 resourcemanager.organizations.get 권한이 없으면 프로젝트가 실제 조직에 예상대로 반영되지 않을 수 있습니다. 자세한 내용은 사용자를 위한 프로젝트 공개 상태 제한을 참조하세요.

조직 리소스와 연관되지 않은 프로젝트를 마이그레이션하는 프로세스는 조직 리소스 간에 프로젝트를 마이그레이션하는 프로세스와 비슷하지만, 마이그레이션 계획에 포함된 모든 단계가 필요하지 않습니다. 프로젝트를 조직 리소스로 마이그레이션하려면 다음 단계를 따라야 합니다.

상속할 정책의 이 프로젝트에 미칠 영향을 확인합니다.
필요에 따라 대상 조직 리소스에 전용 가져오기 폴더를 만듭니다.
권한 할당에 설명된 대로 프로젝트 및 대상 상위 항목의 Identity and Access Management 권한을 할당합니다.
결제 계정을 변경해야 하는지 확인합니다.

그런 다음 마이그레이션을 수행할 수 있습니다.

콘솔

프로젝트를 조직 리소스로 마이그레이션하는 방법은 다음과 같습니다.

Google Cloud 콘솔에서 IAM 및 관리자 > 설정 페이지를 엽니다.
설정 페이지 열기
페이지 상단의 프로젝트 선택기를 선택합니다.
조직 선택기에서 조직 없음을 선택합니다. 연결된 조직 리소스가 없으면 조직 선택기가 나타나지 않으며 이 단계를 건너뛸 수 있습니다.
마이그레이션할 프로젝트를 선택합니다.
페이지 상단에서 이전을 클릭합니다.
조직 드롭다운 목록에서 프로젝트를 마이그레이션할 대상 조직 리소스를 선택합니다.

gcloud

프로젝트를 조직 리소스로 마이그레이션하려면 다음 명령어를 실행합니다.

gcloud beta projects move PROJECT_ID \
    --organization ORGANIZATION_ID

각 항목의 의미는 다음과 같습니다.

PROJECT_ID는 조직 리소스로 마이그레이션할 프로젝트의 ID입니다.
ORGANIZATION_ID는 프로젝트를 마이그레이션할 조직 리소스의 ID입니다.

API

Resource Manager API를 사용하면 parent 필드를 조직 리소스의 ID로 설정하여 프로젝트를 조직 리소스로 마이그레이션할 수 있습니다.

프로젝트를 조직 리소스로 마이그레이션하는 방법은 다음과 같습니다.

projects.get() 메서드를 사용하여 project 객체를 가져옵니다.
parent 필드를 조직 리소스의 ID로 설정합니다.
projects.update() 메서드를 사용하여 project 객체를 업데이트합니다.

parent 필드는 설정 후 변경할 수 없습니다.

다음은 위 단계를 보여주는 코드 스니펫입니다.

    project = crm.projects().get(projectId=flags.projectId).execute()
    project['parent'] = {
        'type': 'organization',
        'id': flags.organizationId
    }

소스 프로젝트에 OS 로그인이 사용 설정된 경우 해당 프로젝트에 대한 액세스 권한이 있는 모든 주 구성원에게 roles/compute.osLoginExternalUser 역할을 할당해야 합니다.

공유 VPC

공유 VPC 프로젝트는 다음 특정 조건에 따라 마이그레이션될 수 있습니다. 먼저 소스 조직 리소스에서 roles/orgpolicy.policyAdmin 역할이 있는 사용자가 내보낼 프로젝트의 상위 항목에서 constraints/resourcemanager.allowEnabledServicesForExport 제약조건을 포함하는 조직 정책을 설정해야 합니다. 이 제약조건에는 SHARED_VPC가 allowed_value로 나열됩니다.

마이그레이션 전에 공유 VPC를 사용 중지할 필요는 없습니다. 하지만 공유 VPC 호스트 프로젝트를 먼저 마이그레이션하고, 해당 서비스 프로젝트를 모두 마이그레이션해야 합니다. 소스 및 대상 위치에서 조직 리소스 간에 일치하는 방화벽 규칙을 선택하여, 잠재적인 문제를 최소화하고, 마이그레이션 중 프로젝트 및 네트워크의 모든 다운타임을 방지하는 것이 좋습니다. 다른 항목을 마이그레이션하는 동안 소스 조직 리소스에 일부 서비스 프로젝트를 무기한 남겨둘 경우 네트워크의 정상 상태가 보장되지 않습니다.

호스트 프로젝트를 마이그레이션하는 경우 이를 다시 소스 조직 리소스로 이동할 수 있습니다. 각 조직에서 호스트 프로젝트 및 서비스 프로젝트를 완료하도록 정확하게 지정된 마감 시한은 없습니다. 하지만 서비스 프로젝트 마이그레이션을 시작할 때는 이를 모두 마이그레이션해야 호스트 프로젝트를 다시 마이그레이션할 수 있습니다.

커스텀 Identity and Access Management 역할

커스텀 Identity and Access Management 역할을 조직 리소스 수준에서 만들어 리소스에 대한 액세스 권한을 세부적으로 제어할 수 있지만, 이는 생성된 조직 리소스에서만 유효합니다. 사용자의 IAM 정책 바인딩이 포함된 프로젝트를 조직 리소스 수준의 커스텀 IAM 역할로 마이그레이션하려고 하면 해당 역할이 대상 조직 리소스에 존재하지 않는다는 실패한 전제조건 오류와 함께 이동이 실패하게 됩니다.

조직 리소스 수준의 커스텀 IAM 역할을 모두 나열하려면 다음 Google Cloud CLI 명령어를 실행하세요.

gcloud iam roles list --organization ORGANIZATION_ID

ORGANIZATION_ID는 역할을 나열하려는 조직 리소스 ID입니다. 조직 리소스 ID를 찾는 방법은 조직 리소스 만들기 및 관리를 참조하세요.

조직 리소스의 커스텀 Identity and Access Management 역할에 대한 정보를 가져오려면 다음 Google Cloud CLI 명령어를 실행합니다.

gcloud iam roles describe --organization ORGANIZATION_ID \
    ROLE_ID

각 항목의 의미는 다음과 같습니다.

ORGANIZATION_ID는 역할의 상위 조직 리소스의 ID입니다.
ROLE_ID는 설명하려는 역할의 이름입니다.

실패한 전제조건 오류를 해결하려면 프로젝트에서 상속받는 각 조직 수준의 커스텀 역할에 해당하는 프로젝트 수준의 커스텀 역할을 만들어야 합니다. 그런 다음 조직 수준의 커스텀 역할을 참조하는 IAM 역할 바인딩을 삭제합니다.

프로젝트가 마이그레이션된 후 대상 조직 리소스에서 조직 수준의 커스텀 역할을 사용하도록 IAM 정책을 업데이트할 수 있습니다.

커스텀 역할에 대한 자세한 내용은 커스텀 역할 만들기 및 관리를 참조하세요.

버킷 잠금

Cloud Storage 버킷 잠금을 사용하면 버킷의 객체를 보존해야 하는 기간을 제어하는 데이터 보관 정책을 Cloud Storage 버킷에 구성할 수 있습니다. 프로젝트가 실수로 삭제되지 않도록 선취권을 사용하여 버킷 잠금이 보호됩니다.

보존 정책 및 선취권은 마이그레이션 중에 프로젝트와 함께 보관되지만 버킷 잠금이 적용된 프로젝트를 마이그레이션하는 경우 실수로 인한 이동을 방지해야 합니다.

VPC 서비스 제어 보안 경계

VPC 서비스 제어를 사용하면 Google Cloud 서비스 주위에 프로젝트 기반 보안 경계를 설정하여 데이터 무단 반출 위험을 완화할 수 있습니다. VPC 서비스 제어 보안 경계로 보호되는 프로젝트는 마이그레이션할 수 없습니다.

보안 경계에서 프로젝트를 삭제하려면 서비스 경계 관리를 참조하세요. VPC 서비스 제어 경계의 프로젝트는 조직 리소스 간에 마이그레이션되지 못하도록 차단할 수 없습니다. 이 가이드라인은 경계가 생성되거나 업데이트된 후 최대 하루 동안 적용됩니다. 서비스 경계에서 프로젝트가 삭제된 후 프로젝트를 마이그레이션할 수 있기까지 몇 시간이 걸릴 수 있습니다.

Dedicated Interconnect

Dedicated Interconnect 객체가 있는 프로젝트 및 VLAN 연결이 있는 프로젝트를 함께 마이그레이션하는 것이 좋습니다. Dedicated Interconnect 객체 또는 이러한 객체에 연결된 VLAN 연결이 있는 프로젝트는 조직 리소스 간 마이그레이션 후에도 계속 작동합니다. 유일한 제한사항은 조직 리소스 분할 간에 새 VLAN 연결을 만들 수 없다는 것입니다.

Dedicated Interconnect 객체가 연결되거나 이 객체에 대한 VLAN 연결이 있는 조직 리소스의 프로젝트에 대한 구성 변경사항은 다른 조직 리소스에 전파되지 않을 수 있습니다. 가능하면 조직 리소스 간에 이러한 프로젝트를 분할을 오래 유지하지 않는 것이 좋습니다.

Partner Interconnect

Partner Interconnect로 프로젝트를 마이그레이션할 때는 특별히 고려해야 할 항목이 없습니다.

프로젝트 간 서비스 계정

프로젝트 간 서비스 계정의 마이그레이션 시 다음 사항이 적용됩니다.

프로젝트 간 서비스 계정이 연결된 프로젝트를 마이그레이션하면 서비스 계정이 대상 조직 리소스에서 계속 작동합니다. 해당 프로젝트의 도메인을 제한하는 조직 정책이 있더라도 프로젝트가 연결된 서비스 계정으로 계속 작동합니다.
소스 조직 리소스의 다른 프로젝트에 연결된 프로젝트 간 서비스 계정을 소유하는 프로젝트를 마이그레이션하면 서비스 계정은 대상 조직 리소스에서 계속 작동합니다. 그러나 소스 조직 리소스의 도메인으로 제한하는 도메인 제한 조직 정책이 적용되는 리소스에는 해당 서비스 계정을 사용할 수 없습니다.

예를 들어 organizations/12345678901에 project-A가 있다고 가정하겠습니다. 이 프로젝트에는 프로젝트 간 서비스 계정으로 설정된 serviceAccount-1이 연결되어 있습니다. organizations/12345678901의 project-B 및 project-C도 serviceAccount-1을 사용합니다.

organizations/12345678901.의 도메인에만 액세스하도록 허용하는 도메인 제한 제약조건이 포함된 조직 정책을 project-C에 적용했습니다.

project-C의 IAM 바인딩에 serviceAccount-1을 추가한 후 project-A를 organizations/45678901234로 마이그레이션하면 서비스 계정이 작동합니다.

project-A를 organizations/45678901234로 마이그레이션한 후 project-C의 IAM 바인딩에 serviceAccount-1을 추가하려고 하면 바인딩이 도메인 제한 제약조건을 위반하므로 실패합니다.

지원 기록

진행 중인 지원 기록이 있는 프로젝트를 마이그레이션하는 경우 Google 지원 담당자에게 연락하여 마이그레이션이 진행되었음을 알려야 합니다. Google에 진행 중인 지원 기록이 있는 프로젝트는 Google 지원팀에서 새 조직 리소스를 가리키도록 사례 메타데이터를 업데이트할 때까지 해당 지원 기록을 볼 수 없습니다.

OAuth 동의 화면

프로젝트가 내부 OAuth 동의 화면을 사용하도록 구성되었고 이를 다른 조직 리소스로 마이그레이션할 경우 대상 조직 리소스의 구성원만 요청을 승인할 수 있습니다. 이 동작이 수행되려면 최대 24시간까지 걸릴 수 있습니다. 그 때까지는 소스 조직 리소스의 구성원이 요청을 승인할 수 있습니다.

아래 단계에서는 마이그레이션 중 소스 조직 리소스의 구성원의 액세스 권한이 손실되지 않도록 하는 방법을 설명합니다. OAuth 동의 화면 구성을 변경할 필요가 없도록 대상 조직 리소스에서 조직 리소스 구성원에 대해 새 사용자를 만들 수 있습니다.

소스 조직 리소스에서 구성원의 액세스 권한 손실을 방지하려면 다음 안내를 따르세요.

OAuth 동의 화면을 내부 대신 외부로 업데이트합니다.
내부로 표시되었고 민감한 정보를 사용하는 앱은 앱 확인을 신청할 필요가 없습니다. 앱에 민감한 정보가 사용되는 경우, 동의 화면이 외부로 업데이트될 때 승인 화면 전 소스 조직 리소스의 사용자에게 확인되지 않은 앱 화면이 표시됩니다. 이를 방지하기 위해서는 민감한 또는 제한된 범위의 사용을 위해 앱 확인을 신청합니다.

OS 로그인

소스 프로젝트에 OS 로그인이 사용 설정된 경우 해당 프로젝트에 대한 액세스 권한이 있는 모든 주 구성원에게 roles/compute.osLoginExternalUser 역할을 할당해야 합니다. 이렇게 하면 이러한 대상 조직 리소스에 대한 주 구성원의 액세스가 손실되지 않습니다.

가상 머신(VM) 인스턴스의 공유 예약

공유 예약에서 예약을 만든 프로젝트(소유자 프로젝트) 또는 예약이 공유되는 프로젝트(소비자 프로젝트)는 VM 인스턴스를 만들어서 예약을 소비할 수 있습니다. 소유자 프로젝트의 동일 조직 내에서만 프로젝트와 예약을 공유할 수 있습니다.

소유자 또는 소비자 프로젝트를 다른 조직으로 마이그레이션할 때는 다음 결과가 발생합니다.

소유자 프로젝트를 다른 조직으로 마이그레이션할 경우 Compute Engine이 소유자 프로젝트로 생성된 예약을 삭제합니다. 실행 중인 VM 인스턴스는 영향을 받지 않습니다.
소비자 프로젝트를 다른 조직으로 마이그레이션하는 경우 소비자 프로젝트는 이전 조직의 공유 예약에서 리소스 소비를 중지합니다.

자세한 내용은 공유 예약 작동 방법을 참조하세요.

리소스에 서비스 계정 연결

대부분의 Google Cloud 서비스의 경우 사용자에게 서비스 계정을 리소스에 연결하기 위해 서비스 계정에 대해 iam.serviceAccounts.actAs 권한이 필요합니다. 하지만 이전에는 사용자에게 서비스 계정을 가장할 수 있는 권한이 없더라도 온보딩을 쉽게 하기 위해 사용자가 특정 서비스를 사용하여 서비스 계정을 리소스에 연결할 수 있었습니다. 이에 대해서는 리소스에 서비스 계정을 연결할 수 있는 권한 필요에서 설명합니다.

고객의 소스 조직 리소스에 레거시 동작(일반 역할 권한 부여 없이 서비스 계정 연결 가능)이 있고 대상 조직 리소스에는 없는 경우 이러한 서비스 계정을 리소스에 연결하는 사용자에게 서비스 계정 사용자 역할(roles/iam.serviceAccountUser)을 부여합니다. 리소스에 서비스 계정을 연결하는 데 필요한 권한에 대한 자세한 내용은 서비스 계정 인증을 위한 역할을 참조하세요.

조직 리소스에 기존 동작이 있는지 확인하려면 다음을 수행하세요.

Google Cloud 콘솔에서 조직 정책 페이지로 이동합니다.

조직 정책 페이지로 이동
페이지 상단의 프로젝트 선택기에서 기존 상태를 확인할 조직 리소스를 선택합니다.
조직 정책 목록 위에 있는 필터 상자에 constraints/appengine.enforceServiceAccountActAsCheck를 입력합니다.
appengine.enforceServiceAccountActAsCheck 조직 정책이 목록에 표시되면 조직 리소스에 기존 동작이 있습니다.
다음 각 조직 정책 제약조건에 대해 3단계 및 4단계를 반복합니다.
- appengine.enforceServiceAccountActAsCheck
- dataflow.enforceComputeDefaultServiceAccountCheck
- dataproc.enforceComputeDefaultServiceAccountCheck
- composer.enforceServiceAccountActAsCheck
이러한 조직 정책 제약조건이 표시되면 조직 리소스에 기존 동작이 사용됩니다.

소스 조직 리소스에 기존 동작이 있고 대상 조직에 없으면 위에 설명된 대로 역할을 부여합니다. 소스 및 대상 조직 리소스 모두 기존 동작이 있으면 작업을 수행할 필요가 없지만, 의도치 않은 가장을 방지하도록 정책을 적용하는 것이 좋습니다.

Analytics Hub를 사용하여 프로젝트 마이그레이션

Analytics Hub를 사용하는 프로젝트를 다른 조직 리소스로 마이그레이션하는 경우 오류가 발생할 수 있습니다. 오류를 해결하려면 지원팀에 문의하세요.

백업 및 DR 서비스로 프로젝트 마이그레이션

프로젝트를 다른 조직 리소스로 마이그레이션하기 전에 백업 및 DR 서비스를 사용 중지해야 합니다. 현재는 서비스가 사용 중지될 때 서비스 중단 위험을 감수해야 합니다. 새 조직 리소스로 마이그레이션이 완료된 후 백업 및 DR 서비스를 다시 사용 설정해야 합니다.

다음 단계

마이그레이션 수행 방법은 마이그레이션 수행을 참조하세요.