<div id="readability-page-1" class="page"><div>#1) 조직 정책(Organization policy) 이란 ?조직을 구성하고 운영하는 기업에서는 기본적이기도 하고 이미 많이 사용하고 있는 조직 정책(Organization policy) 이란 Google cloud 에서 리소스를 중앙에서 프로그래매틱 방식으로 제어하면서 규정을 준수할 수 있도록 가드레일을 정의할 수 있는 기능을 의미합니다.예를 들어서 “리소스 위치 제약조건을 사용하여 새 리소스(예를 들어 VM)의 물리적 위치를 서울리전(asia-northeast3) 으로만 제한”, “리소스 공유를 특정 조직의 리소스에 속하는 도메인 ID 로 제한” 등 사전 정의된 제약 정책을 조직 전체적으로 적용하거나 폴더/프로젝트에 적용합니다. 그리하여 그 하위 수백개의 프로젝트들이 존재한다고 해도 원하는 프로젝트들 대상으로 동일하게 제어 정책을 적용 가능하게 할 수 있습니다. 이를 통하여 조직 전반적으로 제어와 보안성을 높이는 목적으로 다양한 조직 정책을 활용할 수 있습니다. 즉, 조직 정책을 설정함으로써 조직에서 필요한 정책적 or 보안적 가드레일을 만들어서 조직내에 정의 및 활용 할 수 있다는 의미입니다.Introduction to the Organization Policy Service <a href="https://cloud.google.com/resource-manager/docs/organization-policy/overview" rel="noopener ugc nofollow" target="_blank">https://cloud.google.com/resource-manager/docs/organization-policy/overview</a><figure></figure>실제 다양한 조직 정책 중에 하나를 직접 살펴보시면 아마도 이해가 더 빠르실 것 같아 간단하게 공유드리면, 하단의 스크린샷은 ‘균일한 버킷 수준 액세스 권한 적용(Enforce uniform bucket-level access)’ 에 대한 조직 정책 입니다. 적용 대상, 제약 조건 설명등을 보시면 대략 어떤 기능과 역할을 하는지 이해하실 듯 합니다. (다른 조직 정책들도 이와 유사하게 콘솔에 상세한 설명이 잘 나와있습니다.)<figure></figure>제약조건 설명에도 잘 나와있지만 GCS(Google Cloud Storage) 에서 각 오브젝트 별이 아니라 버킷레벨로 접근 권한 제어를 하도록하고 이를 통해서 균일한 보안레벨을 제공하면서 보안성을 더 높이기 위한 권장사항이라고 보시면 됩니다.(오브젝트 별로 권한 제어를 하게되면 유연하게 사용할 수는 있겠지만 권한관리가 복잡해지는 단점이 있으므로…) 이와같은 조직 정책을 조직레벨에서 적용하게 되면 리소스 계층구조에 따라 그 하단의 폴더, 프로젝트까지 모두 해당 정책이 적용되어 GCS 에서 버킷을 생성할때 uniform bucket-level access 를 설정하지 않으면 버킷을 생성하지 못하도록 제어할 수 있습니다. 다시말해서 조직 레벨에서 한번의 설정을 통해서 조직 전체의 모든 프로젝트들에 대해서 해당 조건을 만족해야만 버킷을 만들 수 있도록 제어할 수 있습니다.이때, 조직 구조가 가진 특징인 리소스 계층구조를 활용할 수 있으므로 조직 정책이 조직이나 폴더등의 특정 위치에 설정되면 해당 리소스의 모든 하위 항목은 해당 정책을 기본적으로 상속 받는 구조로 동작합니다. 조직 리소스 레벨에서 조직 정책을 설정하면 해당 정책에 의해 정의된 제한사항 구성이 모든 하위 폴더, 프로젝트로 전달됩니다. 리소스 계층구조로 동작하기 때문에 다른 한편으로는 필요한 경우 상속을 받은 하위 리소스에서도 조직 정책 상속을 예외로 하고나 덮어쓸 수 있어서 조직 전반에서 조직 정책이 적용되는 방식과 예외를 적용할 위치를 유연하고 정밀하게 제어할 수 있습니다.<a href="https://cloud.google.com/resource-manager/docs/organization-policy/understanding-hierarchy" rel="noopener ugc nofollow" target="_blank">https://cloud.google.com/resource-manager/docs/organization-policy/understanding-hierarchy</a><figure></figure>또한, 조직 정책은 이전 이야기에서 여러번 이야기 했던 Tag 와 조합하여 조직 정책의 적용 조건으로 tag 를 활용하여 해당 tag 가 지정된 프로젝트나 리소스에만 제약조건을 적용하거나 작동하지 않게 할 수 있는등 tag 를 활용하여 더 세밀한 제어도 가능합니다.<a href="https://cloud.google.com/resource-manager/docs/organization-policy/tags-organization-policy" rel="noopener ugc nofollow" target="_blank">https://cloud.google.com/resource-manager/docs/organization-policy/tags-organization-policy</a><figure></figure></div><div>#3) 조직 정책과 tag 테스트그럼 이제부터 조직 정책이 어떻게 동작하는지 실제적으로 적용해서 살펴보는 시간을 가지도록 하겠습니다. 가장 기본적으로 Google cloud 관리콘솔의 조직 레벨에서 IAM &amp; Admin &gt; Organization policies 메뉴로 들어가서 조직 정책을 확인합니다.(아마 아시겠지만, 관리콘솔 좌측 상단의 Project picker 에서 조직을 선택하실 수 있습니다.)<figure></figure>이번 파트에서 테스트 삼아 적용할 조직 정책은 ‘Domain restricted sharing(도메인별 ID 제한)’ 로 상세사항은 공식 링크를 통해서 확인해 보실 수 있지만 ‘조직 리소스를 기반으로 리소스 공유를 제한하는데 사용할 수 있는 도메인 제한 제약조건을 제공’ 합니다. 좀 더 상세하게 설명하면 조직과 다른 도메인 id 기반의 사용자(결국은 다른 Google cloud 조직의 사용자)에게 리소스를 공유하는 것을 방지하기 위한 기능이며 결국, 도메인 id 가 다른 사용자는 IAM &amp; Admin 에서 권한 추가를 못하도록 하는 정책입니다. (예를 들어 @<a href="http://aaa.com/" rel="noopener ugc nofollow" target="_blank">aaa.com</a> 이라는 조직의 프로젝트에서 <a href="mailto:userA@bbb.com" rel="noopener ugc nofollow" target="_blank">userA@bbb.com</a> 이라는 다른 Google cloud 조직의 사용자에 대한 권한 추가를 방지)<a href="https://cloud.google.com/resource-manager/docs/organization-policy/restricting-domains" rel="noopener ugc nofollow" target="_blank">https://cloud.google.com/resource-manager/docs/organization-policy/restricting-domains</a><figure></figure>해당 조직 정책을 적용하기 위해서 필터에서 ‘Domain restricted sharing’ 을 선택하고 상세 내용을 확인합니다. 이전 파트에서 언급한 것처럼 ‘Domain restricted sharing’ 은 조직 생성시에 자동으로 설정되어 사용되는 조직 정책이기 때문에 이미 ‘active’ 상태인 것을 확인 가능하며 허용 상세 조건과 설명등을 확인할 수 있습니다. (또는 ‘active’ 가 아니라면 하단과 같이 수정을 통해서 ‘active’ 시킬 수 있습니다.)<figure></figure>조직 레벨에서 해당 조직 정책이 사용되고 있으므로 조직 하위의 프로젝트 레벨에서 조직 정책을 확인해봐도 기본 설정이 ‘Inherit parent’s policy’ 이며 동일하게 설정이 되어있는 것을 확인할 수 있습니다.<figure></figure>조직 정책이 걸려있는 하위의 프로젝트에서 ‘IAM &amp; Admin’ 메뉴로 ‘Grant Access’ 를 클릭하여 다른 도메인의 사용자에게 권한을 추가하려는 경우(예: ‘<a href="mailto:aaa@gmail.com" rel="noopener ugc nofollow" target="_blank">aaa@gmail.com</a>’) 해당 작업이 에러와 함께 실패되는 것을 확인할 수 있습니다.<figure></figure><figure></figure>만약 별도의 요구사항이 있어서 특정 프로젝트에서만 조직 정책을 수정하여 다른 도메인 id 를 가진 사용자에 대한 추가를 가능하게 하려면 프로젝트 레벨에서 조직 정책을 오버라이드 할 수 있습니다. (해당 프로젝트에서만 예외를 주려는 경우) 조직 정책을 프로젝트 레벨에서 수정하기 위해서는 조직 정책 수정을 위한 필요 권한이 있다면 프로젝트 레벨에서 해당 조직 정책을 수정할 수 있습니다. ‘Override parent’s policy’, ‘Replace’ 로 조직 정책의 설정을 수정하고 Rules 는 ‘Allow All’ 로 변경하여 다 허용하도록 설정합니다. (또는 특정 조직에 대해서만 허용하려면 해당 조직의 id 를 확인 후에 추가하면 됩니다. — <a href="https://cloud.google.com/resource-manager/docs/organization-policy/domain-restricted-sharing#org-id-vs-customer-id" rel="noopener ugc nofollow" target="_blank">link</a>)<figure></figure>이렇게 설정을 하면 해당 프로젝트 레벨에서는 ‘Domain restricted sharing’ 조직 정책이 ‘Allow All’ 이라 실제로 적용되지 않기 때문에 상태가 ‘Inactive’ 로 변경된 것을 확인할 수 있습니다.<figure></figure>조직 정책의 반영에 시간이 좀 걸리므로 일정 시간 이후에(약 3~5분 정도 소요) 이전과 동일하게 ‘<a href="mailto:aaa@gmail.com" rel="noopener ugc nofollow" target="_blank">aaa@gmail.com</a>’ 사용자에게 권한 할당 및 추가작업을 하면 이번에는 에러없이 사용자가 해당 프로젝트에 권한을 가지고 추가되는 것을 확인 가능합니다.<figure></figure>즉, 조직 정책을 조직 레벨로 정의를 한 경우에도 요건상 필요한 경우 특정 프로젝트 레벨에서 해당 설정을 오버라이드하여 유연하게 조직 정책 적용/해제 여부를 설정할 수 있습니다. 다만, 이렇게 설정을 각 프로젝트 별로 오버라이드 하는 경우에는 매번 프로젝트 별로 설정을 해야 하기도 하고, 수작업으로 각각 진행해야 하는거라 대규모 프로젝트들이 존재하는 경우에는 향후 어떤 프로젝트가 오버라이드 되었는지 확인하거나 관리하는것이 좀 어려울 수 있습니다.이럴때 좀 더 효율적으로 활용될 수 있는것이 이전 이야기들에서도 몇 차례 이야기 했던 Tag 입니다. 예를 들어 이전 이야기에서와 같은 구성으로 조직 내에 다양한 폴더, 프로젝트에 ‘environment’ tag 가 하단과 같이 ‘production’, ‘development’ value 로 설정되어 있다고 가정해보도록 하겠습니다. (지난 이야기에서도 언급했지만 tag 는 폴더에서 설정하게 되면 프로젝트들이 리소스 계층 구조에 의해서 그 value 를 상속받는 형태로 동작합니다.)<figure></figure>그리고 ‘Domain restricted sharing’ 조직 정책을 적용하는데 ‘environment:development’ tag 를 가진 개발환경을 대상으로는 좀 더 유연하게 다른 조직의 사용자도 초대하거나 권한을 주는 것을 풀어주고, ‘environment:production’ tag 를 가진 운영환경에서만 보안을 강화해서 다른 조직의 사용자를 초대하거나 권한을 주는 것을 방지해야 한다고 가정해보도록 하겠습니다.조직 레벨의 해당 조직 정책이 적용된 부분을 수정하기 위하여 Edit 를 눌러보면 가장 하단에 조건을 추가할 수 있는 ‘Add Condition’ 버튼을 확인할 수 있습니다. Tag 관련된 조건을 추가하기 위해서 해당 버튼을 클릭합니다.<figure></figure>조건 에디터 화면에서는 이전에 Tag 에서 이야기했던 것과 동일하게 조건을 지정된 Tag value 일때만으로 설정을 합니다. 즉, ‘environment’ tag 의 value 가 ‘production’ 인 경우를 조건으로 넣습니다. (당연히 CEL 로도 입력 가능합니다. — resource.matchTag(“55454119248/environment”, “production”)<figure></figure>이렇게 설정을 하고 저장을 하면 하단과 같이 조직 정책의 허용에 조건이 추가된 것을 확인할 수 있습니다. (‘environment:production’ 이라는 tag 가 매칭되는지에 대한 조건이 추가)<figure></figure>설정 변경이 완료되었다면 이제 리소스 계층에서 ‘environment’ tag 의 value 가 ‘production’ 이 아닌 프로젝트 레벨로 가서 조직 정책을 확인해봅니다. 그러면 이전과 다르게 ‘Domain restricted sharing’ 조직 정책이 ‘Active’ 이지만 조건은 ‘Allowed All’ 로 변경된 것을 확인할 수 있습니다. 다시 말씀드려서, ‘environment’ tag 의 value 가 ‘development’ 인 프로젝트의 경우에는 별도의 작업 없이도 ‘Domain restricted sharing’ 조직 정책이 풀려있는 것을 확인할 수 있습니다.<figure></figure>예상하시겠지만, 조직 정책이 ‘Allowed All’ 로 풀려있기 때문에 이전에 수행했던 IAM 에서 새로운 사용자를 추가해보면 해당 프로젝트에 대해서는 ‘<a href="mailto:aaa@gmail.com" rel="noopener ugc nofollow" target="_blank">aaa@gmail.com</a>’ 와 같은 다른 도메인 id 의 사용자도 추가가 가능한 것을 확인할 수 있습니다.<figure></figure>이전에 각각의 프로젝트에서 직접 조직 정책을 오버라이드 하는 경우에는 작업자를 제외하고 해당 정잭의 적용여부를 확인하기가 어렵고 시간이 지난후에 기억이 나지 않아서 어떤 프로젝트에 해당 조직 정책이 적용되었는지 or 적용되지 않았는지 찾기위해서 일일이 다 뒤져봐야하는 단점이 있습니다. 그러나, 지금 이야기에서 언급된 것처럼 Tag 와 적절하게 조합해서 조직정책을 활용하게 된다면 규정을 준수할 수 있도록 가드레일을 정의하는 조직 정책 작업에 대해서 좀 더 효과적이고 체계적으로 수행 할 수 있을 뿐만 아니라 향후 관리관점에서도 다양한 이점을 얻을 수 있습니다.</div></div>

Stories by 이정운 (Jungwoon Lee) on Medium

[GCP]Google cloud 를 좀 더 효과적이고 체계적으로 관리하기 위한 방안 알아보기 3부 — 조직 정책과 Tag
안녕하세요 이정운 입니다.
Google cloud 에서 조직을 사용하면서 대규모로 프로젝트들을 사용하고 있는 경우 이러한 대규모 환경에서 효과적이고 체계적인 관리를 위해서 도움이 될만한 기능들이 뭐가 있을지 하나씩 살펴보는 시리즈를 하단과 같이 진행하고 있습니다.
[GCP]Google cloud 를 좀 더 효과적이고 체계적으로 관리하기 위한 방안 알아보기 1부 — Label 과 Tag
[GCP]Google cloud 를 좀 더 효과적이고 체계적으로 관리하기 위한 방안 알아보기 2부 — Tag 와 IAM Condition & Deny policy
지난 시간에는 Tag 와 IAM Condition 에 대한 이야기로 주로 IAM Condition 과 Deny policy 를 살펴보고 운영환경에서 어떻게 이를 활용해서 가드레일을 세울지에 대해서 살짝 예제를 가지고 논의 및 살펴봤습니다. 다음으로 IAM Condition 에서 어떻게 Tag 를 가지고 조건을 만들 수 있는지와 그러한 조건이 어떻게 동작하는 지를 직접 실습을 해보면서 확인하는 시간을 가졌었습니다.
이번에는 Google cloud 를 좀 더 효과적이고 체계적으로 관리하기 위한 방안으로서 조직(Organization) 을 사용하는 경우 리소스를 중앙에서 프로그래매틱 방식으로 제어할 수 있는 조직 정책(Organization policy) 을 살펴보고 해당 조직 정책을 유연하게 활용하기 위한 조건으로 사용될 수 있는 Tag 에 대한 부분도 같이 살펴보고 테스트 해보는 시간을 가져보도록 하겠습니다.
백문이 불여일타! 그럼 지금 바로 시작하도록 하겠습니다.
#1) 조직 정책(Organization policy) 이란 ?
조직을 구성하고 운영하는 기업에서는 기본적이기도 하고 이미 많이 사용하고 있는 조직 정책(Organization policy) 이란 Google cloud 에서 리소스를 중앙에서 프로그래매틱 방식으로 제어하면서 규정을 준수할 수 있도록 가드레일을 정의할 수 있는 기능을 의미합니다.
예를 들어서 “리소스 위치 제약조건을 사용하여 새 리소스(예를 들어 VM)의 물리적 위치를 서울리전(asia-northeast3) 으로만 제한”, “리소스 공유를 특정 조직의 리소스에 속하는 도메인 ID 로 제한” 등 사전 정의된 제약 정책을 조직 전체적으로 적용하거나 폴더/프로젝트에 적용합니다. 그리하여 그 하위 수백개의 프로젝트들이 존재한다고 해도 원하는 프로젝트들 대상으로 동일하게 제어 정책을 적용 가능하게 할 수 있습니다. 이를 통하여 조직 전반적으로 제어와 보안성을 높이는 목적으로 다양한 조직 정책을 활용할 수 있습니다. 즉, 조직 정책을 설정함으로써 조직에서 필요한 정책적 or 보안적 가드레일을 만들어서 조직내에 정의 및 활용 할 수 있다는 의미입니다.
Introduction to the Organization Policy Service
https://cloud.google.com/resource-manager/docs/organization-policy/overview
실제 다양한 조직 정책 중에 하나를 직접 살펴보시면 아마도 이해가 더 빠르실 것 같아 간단하게 공유드리면, 하단의 스크린샷은 ‘균일한 버킷 수준 액세스 권한 적용(Enforce uniform bucket-level access)’ 에 대한 조직 정책 입니다. 적용 대상, 제약 조건 설명등을 보시면 대략 어떤 기능과 역할을 하는지 이해하실 듯 합니다. (다른 조직 정책들도 이와 유사하게 콘솔에 상세한 설명이 잘 나와있습니다.)
제약조건 설명에도 잘 나와있지만 GCS(Google Cloud Storage) 에서 각 오브젝트 별이 아니라 버킷레벨로 접근 권한 제어를 하도록하고 이를 통해서 균일한 보안레벨을 제공하면서 보안성을 더 높이기 위한 권장사항이라고 보시면 됩니다.(오브젝트 별로 권한 제어를 하게되면 유연하게 사용할 수는 있겠지만 권한관리가 복잡해지는 단점이 있으므로…) 이와같은 조직 정책을 조직레벨에서 적용하게 되면 리소스 계층구조에 따라 그 하단의 폴더, 프로젝트까지 모두 해당 정책이 적용되어 GCS 에서 버킷을 생성할때 uniform bucket-level access 를 설정하지 않으면 버킷을 생성하지 못하도록 제어할 수 있습니다. 다시말해서 조직 레벨에서 한번의 설정을 통해서 조직 전체의 모든 프로젝트들에 대해서 해당 조건을 만족해야만 버킷을 만들 수 있도록 제어할 수 있습니다.
이때, 조직 구조가 가진 특징인 리소스 계층구조를 활용할 수 있으므로 조직 정책이 조직이나 폴더등의 특정 위치에 설정되면 해당 리소스의 모든 하위 항목은 해당 정책을 기본적으로 상속 받는 구조로 동작합니다. 조직 리소스 레벨에서 조직 정책을 설정하면 해당 정책에 의해 정의된 제한사항 구성이 모든 하위 폴더, 프로젝트로 전달됩니다. 리소스 계층구조로 동작하기 때문에 다른 한편으로는 필요한 경우 상속을 받은 하위 리소스에서도 조직 정책 상속을 예외로 하고나 덮어쓸 수 있어서 조직 전반에서 조직 정책이 적용되는 방식과 예외를 적용할 위치를 유연하고 정밀하게 제어할 수 있습니다.
https://cloud.google.com/resource-manager/docs/organization-policy/understanding-hierarchy
또한, 조직 정책은 이전 이야기에서 여러번 이야기 했던 Tag 와 조합하여 조직 정책의 적용 조건으로 tag 를 활용하여 해당 tag 가 지정된 프로젝트나 리소스에만 제약조건을 적용하거나 작동하지 않게 할 수 있는등 tag 를 활용하여 더 세밀한 제어도 가능합니다.
https://cloud.google.com/resource-manager/docs/organization-policy/tags-organization-policy
#2) 조직 정책 권장 사항
다시 처음으로 돌아와서 Google cloud 관리콘솔 > IAM & Admin > Organization Policies 메뉴를 클릭하면 바로 다양한 조직 정책들을 확인할 수 있고 어떤 조직 정책이 적용중인지도 콘솔에서 확인 가능합니다.
일반적으로 이 기능에 대한 소개를 하게 되면 어떤 조직 정책을 기본적으로 적용하는게 Best Practices 인지 궁금해 하실 수 있는데, 보안상 권장되는 기본 조직 정책은 조직 생성시 자동 적용하게 되어있으며 하단의 링크에서 어떤 정책이 기본적으로 적용되는지 그 내용을 확인할 수 있습니다. (단, 조직 생성 시점에 따라 조금 상이할 수 있으나 현재 기준 조직 생성시 자동 적용되는 하위 정책은 기본적으로 사용하시는 것을 권장드립니다.)
https://cloud.google.com/resource-manager/docs/secure-by-default-organizations#organization_policies_enforced_on_organization_resources
즉, Google cloud 가 생각했을때 조직 운영시 꼭 적용되면 좋겠다라고 권장하는 기본적인 조직 정책은 조직 생성시 자동 적용되고 있으며 상단의 공식링크를 통해서 자세한 설명을 같이 제공합니다.
그 이외에도 다수의 조직 정책들을 다양하게 Google cloud 에서 직접 만들어서 제공해드리고 있습니다. 해당 정책 항목들은 조직 운영관점에서 필요할 가능성이 높은 것들이기 때문에 살펴보시고 운영 시점에 필요하다고 생각되면 바로 적용하거나 쉽게 활용할 수 있습니다.
https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints
첨부 #2.1) 조직 정책의 경우에는 적용하게 되면 해당 리소스가 생성/업데이트 되는 것을 기본적으로 강제로 막게(enforce) 되는데 운영환경에서 바로 적용하는 케이스라 리스크가 있다면 dry run 모드도 사용 가능합니다. dry run 모드라는 것은 이름 그대로 정책 위반시 log 를 생성하긴 하지만 실제로 리소스 생성을 막지는 않고 사용자의 오퍼레이션이 그대로 동작하게 합니다. 즉, 테스트 목적으로 활용을 하거나 리소스 생성 방지는 하지 않지만 로그를 남겨서 audit 목적으로도 활용할 수 있습니다.
https://cloud.google.com/resource-manager/docs/organization-policy/dry-run-policy
#3) 조직 정책과 tag 테스트
그럼 이제부터 조직 정책이 어떻게 동작하는지 실제적으로 적용해서 살펴보는 시간을 가지도록 하겠습니다. 가장 기본적으로 Google cloud 관리콘솔의 조직 레벨에서 IAM & Admin > Organization policies 메뉴로 들어가서 조직 정책을 확인합니다.(아마 아시겠지만, 관리콘솔 좌측 상단의 Project picker 에서 조직을 선택하실 수 있습니다.)
이번 파트에서 테스트 삼아 적용할 조직 정책은 ‘Domain restricted sharing(도메인별 ID 제한)’ 로 상세사항은 공식 링크를 통해서 확인해 보실 수 있지만 ‘조직 리소스를 기반으로 리소스 공유를 제한하는데 사용할 수 있는 도메인 제한 제약조건을 제공’ 합니다. 좀 더 상세하게 설명하면 조직과 다른 도메인 id 기반의 사용자(결국은 다른 Google cloud 조직의 사용자)에게 리소스를 공유하는 것을 방지하기 위한 기능이며 결국, 도메인 id 가 다른 사용자는 IAM & Admin 에서 권한 추가를 못하도록 하는 정책입니다. (예를 들어 @aaa.com 이라는 조직의 프로젝트에서 userA@bbb.com 이라는 다른 Google cloud 조직의 사용자에 대한 권한 추가를 방지)
https://cloud.google.com/resource-manager/docs/organization-policy/restricting-domains
해당 조직 정책을 적용하기 위해서 필터에서 ‘Domain restricted sharing’ 을 선택하고 상세 내용을 확인합니다. 이전 파트에서 언급한 것처럼 ‘Domain restricted sharing’ 은 조직 생성시에 자동으로 설정되어 사용되는 조직 정책이기 때문에 이미 ‘active’ 상태인 것을 확인 가능하며 허용 상세 조건과 설명등을 확인할 수 있습니다. (또는 ‘active’ 가 아니라면 하단과 같이 수정을 통해서 ‘active’ 시킬 수 있습니다.)
조직 레벨에서 해당 조직 정책이 사용되고 있으므로 조직 하위의 프로젝트 레벨에서 조직 정책을 확인해봐도 기본 설정이 ‘Inherit parent’s policy’ 이며 동일하게 설정이 되어있는 것을 확인할 수 있습니다.
조직 정책이 걸려있는 하위의 프로젝트에서 ‘IAM & Admin’ 메뉴로 ‘Grant Access’ 를 클릭하여 다른 도메인의 사용자에게 권한을 추가하려는 경우(예: ‘aaa@gmail.com’) 해당 작업이 에러와 함께 실패되는 것을 확인할 수 있습니다.
만약 별도의 요구사항이 있어서 특정 프로젝트에서만 조직 정책을 수정하여 다른 도메인 id 를 가진 사용자에 대한 추가를 가능하게 하려면 프로젝트 레벨에서 조직 정책을 오버라이드 할 수 있습니다. (해당 프로젝트에서만 예외를 주려는 경우) 조직 정책을 프로젝트 레벨에서 수정하기 위해서는 조직 정책 수정을 위한 필요 권한이 있다면 프로젝트 레벨에서 해당 조직 정책을 수정할 수 있습니다. ‘Override parent’s policy’, ‘Replace’ 로 조직 정책의 설정을 수정하고 Rules 는 ‘Allow All’ 로 변경하여 다 허용하도록 설정합니다. (또는 특정 조직에 대해서만 허용하려면 해당 조직의 id 를 확인 후에 추가하면 됩니다. — link)
이렇게 설정을 하면 해당 프로젝트 레벨에서는 ‘Domain restricted sharing’ 조직 정책이 ‘Allow All’ 이라 실제로 적용되지 않기 때문에 상태가 ‘Inactive’ 로 변경된 것을 확인할 수 있습니다.
조직 정책의 반영에 시간이 좀 걸리므로 일정 시간 이후에(약 3~5분 정도 소요) 이전과 동일하게 ‘aaa@gmail.com’ 사용자에게 권한 할당 및 추가작업을 하면 이번에는 에러없이 사용자가 해당 프로젝트에 권한을 가지고 추가되는 것을 확인 가능합니다.
즉, 조직 정책을 조직 레벨로 정의를 한 경우에도 요건상 필요한 경우 특정 프로젝트 레벨에서 해당 설정을 오버라이드하여 유연하게 조직 정책 적용/해제 여부를 설정할 수 있습니다. 다만, 이렇게 설정을 각 프로젝트 별로 오버라이드 하는 경우에는 매번 프로젝트 별로 설정을 해야 하기도 하고, 수작업으로 각각 진행해야 하는거라 대규모 프로젝트들이 존재하는 경우에는 향후 어떤 프로젝트가 오버라이드 되었는지 확인하거나 관리하는것이 좀 어려울 수 있습니다.
이럴때 좀 더 효율적으로 활용될 수 있는것이 이전 이야기들에서도 몇 차례 이야기 했던 Tag 입니다. 예를 들어 이전 이야기에서와 같은 구성으로 조직 내에 다양한 폴더, 프로젝트에 ‘environment’ tag 가 하단과 같이 ‘production’, ‘development’ value 로 설정되어 있다고 가정해보도록 하겠습니다. (지난 이야기에서도 언급했지만 tag 는 폴더에서 설정하게 되면 프로젝트들이 리소스 계층 구조에 의해서 그 value 를 상속받는 형태로 동작합니다.)
그리고 ‘Domain restricted sharing’ 조직 정책을 적용하는데 ‘environment:development’ tag 를 가진 개발환경을 대상으로는 좀 더 유연하게 다른 조직의 사용자도 초대하거나 권한을 주는 것을 풀어주고, ‘environment:production’ tag 를 가진 운영환경에서만 보안을 강화해서 다른 조직의 사용자를 초대하거나 권한을 주는 것을 방지해야 한다고 가정해보도록 하겠습니다.
조직 레벨의 해당 조직 정책이 적용된 부분을 수정하기 위하여 Edit 를 눌러보면 가장 하단에 조건을 추가할 수 있는 ‘Add Condition’ 버튼을 확인할 수 있습니다. Tag 관련된 조건을 추가하기 위해서 해당 버튼을 클릭합니다.
조건 에디터 화면에서는 이전에 Tag 에서 이야기했던 것과 동일하게 조건을 지정된 Tag value 일때만으로 설정을 합니다. 즉, ‘environment’ tag 의 value 가 ‘production’ 인 경우를 조건으로 넣습니다. (당연히 CEL 로도 입력 가능합니다. — resource.matchTag(“55454119248/environment”, “production”)
이렇게 설정을 하고 저장을 하면 하단과 같이 조직 정책의 허용에 조건이 추가된 것을 확인할 수 있습니다. (‘environment:production’ 이라는 tag 가 매칭되는지에 대한 조건이 추가)
설정 변경이 완료되었다면 이제 리소스 계층에서 ‘environment’ tag 의 value 가 ‘production’ 이 아닌 프로젝트 레벨로 가서 조직 정책을 확인해봅니다. 그러면 이전과 다르게 ‘Domain restricted sharing’ 조직 정책이 ‘Active’ 이지만 조건은 ‘Allowed All’ 로 변경된 것을 확인할 수 있습니다. 다시 말씀드려서, ‘environment’ tag 의 value 가 ‘development’ 인 프로젝트의 경우에는 별도의 작업 없이도 ‘Domain restricted sharing’ 조직 정책이 풀려있는 것을 확인할 수 있습니다.
예상하시겠지만, 조직 정책이 ‘Allowed All’ 로 풀려있기 때문에 이전에 수행했던 IAM 에서 새로운 사용자를 추가해보면 해당 프로젝트에 대해서는 ‘aaa@gmail.com’ 와 같은 다른 도메인 id 의 사용자도 추가가 가능한 것을 확인할 수 있습니다.
이전에 각각의 프로젝트에서 직접 조직 정책을 오버라이드 하는 경우에는 작업자를 제외하고 해당 정잭의 적용여부를 확인하기가 어렵고 시간이 지난후에 기억이 나지 않아서 어떤 프로젝트에 해당 조직 정책이 적용되었는지 or 적용되지 않았는지 찾기위해서 일일이 다 뒤져봐야하는 단점이 있습니다. 그러나, 지금 이야기에서 언급된 것처럼 Tag 와 적절하게 조합해서 조직정책을 활용하게 된다면 규정을 준수할 수 있도록 가드레일을 정의하는 조직 정책 작업에 대해서 좀 더 효과적이고 체계적으로 수행 할 수 있을 뿐만 아니라 향후 관리관점에서도 다양한 이점을 얻을 수 있습니다.
이번 이야기에서는 Google cloud 의 조직 구조에서 다수의 프로젝트를 운영할때 효과적이고 체계적으로 관리하기 위한 방안의 세번째로 Tag 와 조직 정책에 대한 이야기를 진행했습니다. 조직 정책이 무엇인지 간단하게 살펴봤고 조직 정책을 통해서 리소스를 중앙에서 프로그래매틱 방식으로 제어할 수 있는 기능의 의미를 실제 하나의 조직정책을 통해서 살펴봤습니다. 마지막으로 Tag 를 활용해서 해당 제어를 좀 더 유연하게 중앙집중식으로 제어하고 관리적인 측면에서도 좀 더 쉽게 관리할 수 있는 방안을 같이 테스트해봤습니다.
해당 이야기가 도움이 되었기를 바라며, 그럼 이번 이야기는 여기서 마무리 하도록 하겠습니다. 다음에 더 좋은 이야기로 다시 돌아오도록 하겠습니다. ;)
Disclaimer: 본 글의 작성자는 Google 소속이지만, 본 글에 작성자 개인적 견해가 반영된 것으로서, 본 글은 Google 을 대변하지 않으며, Google의 공식적 입장이 아님을 밝힙니다.
[GCP]Google cloud 의 효과적이고 체계적으로 관리하기 위한 방안 알아보기 1부 — Label 과 Tag
[GCP]Google cloud 를 좀 더 효과적이고 체계적으로 관리하기 위한 방안 알아보기 2부 — Tag 와 IAM Condition & Deny policy
[GCP]Google cloud 를 좀 더 효과적이고 체계적으로 관리하기 위한 방안 알아보기 3부 — 조직 정책과 Tag
참고 자료 #1
Introduction to the Organization Policy Service
https://cloud.google.com/resource-manager/docs/organization-policy/overview
Understanding hierarchy evaluation
https://cloud.google.com/resource-manager/docs/organization-policy/understanding-hierarchy
Setting an organization policy with tags
https://cloud.google.com/resource-manager/docs/organization-policy/tags-organization-policy
Organization policies enforced on organization resources
https://cloud.google.com/resource-manager/docs/secure-by-default-organizations#organization_policies_enforced_on_organization_resources
Organization policy constraints
https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints
Create an organization policy in dry-run mode
https://cloud.google.com/resource-manager/docs/organization-policy/dry-run-policy
Restricting identities by domain
https://cloud.google.com/resource-manager/docs/organization-policy/restricting-domains
Organization resource ID versus Google Workspace customer ID
https://cloud.google.com/resource-manager/docs/organization-policy/domain-restricted-sharing#org-id-vs-customer-id
[GCP]Google cloud 를 좀 더 효과적이고 체계적으로 관리하기 위한 방안 알아보기 3부 — 조직 정책과 Tag was originally published in google-cloud-apac on Medium, where people are continuing the conversation by highlighting and responding to this story.

[GCP]Google cloud 를 좀 더 효과적이고 체계적으로 관리하기 위한 방안 알아보기 3부 — 조직 정책과 Tag

댓글