<div id="readability-page-1" class="page"><div>#1) Tag 와 IAM Condition 이란 ?Tag 는 지난 이야기에서도 설명했지만 key-value 쌍으로 이루어졌고 특정 tag 가 있는지 여부에 따라 IAM Condition 이나 Organization policy 와 같은 정책을 조건부로 허용하거나 거부하는 방법을 제공할 수 있다고 말씀드렸습니다. 이렇듯 Tag 는 기 언급한 것처럼 정책을 지정하는 기능과 연동되어서 조건으로 활용되는데 이러한 정책 관련 기능중의 대표적인 것이 IAM Condition 입니다.IAM Condition 이란 이름 그대로 IAM(Identity and Access Management) 을 통해서 역할이나 권한을 부여할 때 특정 조건을 줄 수 있는 기능입니다. (AWS 사용자는 IAM Policy 와 유사한 형태로 이해하면 도움이 될듯 합니다.) IAM 은 이미 잘 아시겠지만 해당 프로젝트에 사용자를 초대하거나 필요한 역할, 권한을 부여하는 기능을 의미하며 Google cloud 의 IAM 의 특징은 리소스 계층구조에 따라 조직 &gt; 폴더 &gt; 프로젝트로 사용자와 권한의 상속 기능이 지원된다는 점입니다. 즉, 해당 사용자를 폴더에 추가하고 권한을 준다면 해당 폴더와 그 하위의 모든 프로젝트들에 해당 사용자는 상속을 통해서 동일한 권한을 가진채 추가되며 해당 사용자는 해당 프로젝트들에 대해서 지정된 권한을 수행할 수 있습니다.<a href="https://cloud.google.com/iam/docs/overview" rel="noopener ugc nofollow" target="_blank">https://cloud.google.com/iam/docs/overview</a><figure></figure>다만, 이번 이야기에서 IAM 을 자세히 다룰것은 아니라서 IAM 은 어느 정도 이해하고 있다고 가정하고 IAM Condition 에 대해서 좀 더 이야기를 진행하도록 하겠습니다. IAM Condition 은 예를 들면 ‘영희’ 라는 사용자에게 GCE 를 생성, 삭제 등을 할 수 있는 Compute Admin 이라는 역할을 부여할 때 env 라는 tag 의 값이 test 일 경우에만 권한을 부여하도록 하거나, 오전 9시에서 6시까지만 권한을 주는등 특정 조건을 추가하는 것 입니다. 이렇게 IAM Condition 을 사용해서 권한을 부여하게 되면 ‘영희’ 라는 사용자는 ‘env:test’ 라는 tag 와 값을 가진 프로젝트에서만 GCE 를 생성, 삭제 등을 할 수 있는 권한을 가지게 됩니다.(또는, 특정 시간에만) 이와 같이 IAM 을 설정할때 필요한 조건을 설정할 수 있는 기능을 IAM Condition 이라고하며 tag 이외에 리소스나 시간같은 더 다양한 조건을 추가적으로 활용할 수도 있습니다.Overview of IAM Conditions <a href="https://cloud.google.com/iam/docs/conditions-overview" rel="noopener ugc nofollow" target="_blank">https://cloud.google.com/iam/docs/conditions-overview</a><a href="https://cloud.google.com/blog/topics/developers-practitioners/cloud-iam-google-cloud" rel="noopener ugc nofollow" target="_blank">https://cloud.google.com/blog/topics/developers-practitioners/cloud-iam-google-cloud</a><figure></figure></div><div>#2) Deny policy 란 ?IAM Condition 은 일반적으로 많이 이해하고 있는 것처럼 역할이나 권한을 부여해서 그 역할을 허용하는 형태의 Allow policy 뿐만 아니라 반대형태로 동작하여 그 역할이나 권한을 사용하지 못하게 하는 형태의 Deny policy 라는 기능도 같이 제공할 수 있습니다. 그리고, 이때도 tag 를 그 조건으로 같이 활용할 수 있습니다.Deny policy 는 이름 그대로 지정한 특정 조건에 맞다면 해당 역할을 거꾸로 사용하지 못하게 방지하는 형태로 동작하는 정책을 의미합니다. 이 부분을 조금만 더 자세하게 살펴보면 Deny policy 는 IAM 에 추가하는 것이 아니라 조직이나 폴더, 프로젝트 리소스 단위로 추가(attach) 가능하며 Deny rule 을 작성하여 해당 사용자가 심지어 관리자 권한이 있더라도 특정 조건을 설정하여 그 조건에 맞다면 그 권한을 사용하지 못하게 합니다. 이를 통해서 결국은 특정 권한에 대한 접근을 제어하여 마치 조직이나 프로젝트에 가드레일을 설정하는 것처럼 활용할 수 있습니다.<a href="https://cloud.google.com/iam/docs/deny-overview#use-cases" rel="noopener ugc nofollow" target="_blank">https://cloud.google.com/iam/docs/deny-overview#use-cases</a><figure></figure>상단의 공식 링크에 있는 예제를 참고해서 예를 하나 들어보겠습니다. 조직 구조 안에서 모든 프로젝트 관리자가 custom role 을 만들 수 있는 기능을 가지고 있어서 저마다 custom role 을 만들어서 활용하다보니 조직 관리 측면에서 원하지 않는 다양한 custom role 이 만들어지고 관리가 안되다보니 잘못된 권한 부여 등으로 권한관리에 이슈가 있는 상황이라면 Deny policy 를 활용하여 이를 간단하게 방지할 수 있습니다. Deny policy 를 상단의 예제와 같이 설정하면 특정 사용자 그룹에게만 custom role 을 만들 수 있는 권한을 주고 프로젝트 관리자를 포함하여 다른 모든 사용자에게는 해당 권한을 주지 않는 형태로 권한을 제어하는 가드레일을 설정 할 수 있습니다. (참고로 IAM 의 Best practices 중의 하나로 이러한 권한 부여의 경우는 사용자 보다는 그룹을 사용하는 것을 추천합니다.)즉, Deny policy 를 적용하면 예외 주체(principals)로 정의된 <a href="mailto:custom-role-admins@example.com" rel="noopener ugc nofollow" target="_blank">custom-role-admins@example.com</a> 이라는 그룹만 custom role 을 만들 수 있는 권한을 가질수 있고 다른 모든 사용자는 해당 권한을 가질 수 없습니다.하단의 예제를 추가하여 좀 더 상세하게 설명 드리면, Yuri@ 와 Tai@ 라는 사용자 둘다 Organization Role Administrator 역할을 가지고 있어서 custom role 을 만들수 있을거 같지만 Yuri@ 만 custom-role-admins@ 그룹의 멤버이기 때문에 Deny policy 에 의해서 Tai@ 는 결국 custom role 을 만들 수 있는 권한이 제공되지 않습니다.<figure></figure>이를 다시 실제 운영환경의 시나리오로 엮어서 생각해보면 Deny policy 를 정의하여 프로젝트 관리자라고 해도 custom role 을 생성 못하게 조직내의 가드레일을 세우고 운영하다가 반드시 custom role 을 생성해야 하는 경우가 발생한다면, 해당 사용자만 잠시 custom-role-admins@ 그룹의 멤버로 추가해서 custom role 을 만들수 있도록 허용한 후에 작업을 진행합니다. 그 후 작업이 완료되면 다시 해당 사용자를 custom-role-admins@ 그룹의 멤버에서 빼면 Deny policy 에 의해서 다시 해당 권한을 사용하지 못하므로 민감한 권한에 대한 관리를 쉽게 제어할 수 있습니다.</div><div>#3) Tag 와 IAM Condition 테스트우선 Tag 와 IAM Condition 을 어떻게 같이 활용할 수 있는지 실제 살펴보기 위해서 조직에 폴더를 구성하고 tag 를 하단과 같이 지정합니다. (tag key 로 environment 를 사용했고 tag value 로 production, development 를 사용했습니다.)<figure></figure>꼭, 제 환경과 동일하게 작업할 필요는 없고 조직에 폴더 구조만 있으면 동일하게 테스트 가능합니다. 간단하게 테스트를 위한 조직 구조를 설명드리면 Depart001 라는 부서에 Team01 과 Team02 가 있는데 Team01 은 운영환경의 프로젝트들을 관리하고 Team02 는 개발환경의 프로젝트를 관리한다는 가정으로 조직과 폴더 구조를 만들었습니다. 그리고 여기다가 Depart001 폴더 레벨에서 ‘environment:production’ tag 를 추가하고 전체가 다 상속 받게 한 후에 Team02 폴더만 해당 폴더 레벨에서 tag value 만 ‘development’ 로 오버라이드 하였습니다.이렇게 환경이 준비되었다면 이제 Depart001 의 Team02 에 iamtest01@ 라는 새로운 개발자가 왔다고 가정을 해보도록 하겠습니다. 그리고 해당 개발자에게 Team01이 관리하는(폴더 Team01 아래 위치한) 운영환경과, Team02이 관리하는(폴더 Team02 아래 위치한) 개발 환경을 볼 수 있는 Viewer 라는 기본 역할을 주어야 하며 추가적으로 개발 환경에만 GCE(VM) 를 생성, 삭제할 수 있는 Compute Admin 권한을 주어야 한다고 가정해보겠습니다.Google cloud 관리콘솔 IAM 메뉴에서 ‘+Grant Access’ 버튼을 클릭하여 iamtest01@ 사용자를 추가하고 Viewer 와 Compute Admin 역할을 할당합니다. 이때 바로 Save 를 누르지 말고 Compute Admin 역할 우측에 있는 ‘+Add IAM Condition’ 버튼을 클릭합니다.<figure></figure>IAM Condition 에 원하는 이름을 넣고 Condition Builder 에서 필요한 조건을 선택해서 지정할 수 있습니다. 하단에 보시면 아시겠지만 다양한 리소스를 조건으로 사용할 수도 있고 당연히 tag 도 조건으로 사용할 수 있습니다.<figure></figure>여기서는 tag 를 선택하고 Operator 로는 ‘has value’(해당 값을 가지고 있으면) 를 선택합니다. 그리고 마지막으로 원하는 tag value 의 value path 를 넣어주면 됩니다. (제가 사용한 예제 값 : ‘environment:development’ — <a href="http://jungwoonlee.altostrat.com/environment/development" rel="noopener ugc nofollow" target="_blank">jungwoonlee.altostrat.com/environment/development</a>)<figure></figure>첨부 #2.1) 손쉽게 클릭해서 선택하는 Condition Builder 말고도 직접 CEL 형태로 정의할 수 있는 Condition Editor 를 사용할 수도 있습니다. (또는, Builder 로 설정하고 Editor 를 클릭하면 자동으로 CEL 로 변경된 결과를 확인할 수 있습니다.)<figure></figure>CEL 사용 방법 및 좀 더 다양한 예제들은 하단의 공식 메뉴얼을 참고하시기 바라겠습니다 .<a href="https://cloud.google.com/iam/docs/conditions-overview#cel" rel="noopener ugc nofollow" target="_blank">https://cloud.google.com/iam/docs/conditions-overview#cel</a>이렇게 설정 후 저장 하면 하단과 같이 iamtest01@ 사용자에게 할당되는 Compute Admin 역할에 IAM condition 이 추가된 것을 확인할 수 있습니다.<figure></figure>이제 실제로 해당 역할을 부여하기 위해서 저장하면 IAM 메뉴에서 부여된 역할 이외에 IAM condition 이 추가 지정된 것을 확인할 수 있습니다.<figure></figure>그럼 이제 설정이 완료되었으니 iamtest01@ 사용자로 로그인 해서 관리콘솔로 들어옵니다. 관리콘솔 좌측 상단의 프로젝트 픽커를 클릭해서 설정한데로 Team01 이 관리하는 운영환경과 Team02 가 관리하는 개발환경이 다 보이는지 확인합니다.<figure></figure>Team01 이 관리하는 운영환경 중에 하나의 프로젝트로 접근해서 Compute Engine 메뉴를 확인해 봅니다. 운영환경의 프로젝트에는 ‘environment:production’ tag 가 붙어있으므로 Viewer 권한만 동작하며 GCE 를 생성하거나 실행, 삭제하는 등의 권한이 없는 것을 확인할 수 있습니다. (하단의 스크린 캡춰에서 확인할 수 있는 것처럼 GCE 에 대한 Start/Resume, Stop 등의 기능이 disable 된것을 보실 수 있습니다.)<figure></figure>이제 Team02 가 관리하는 개발환경 중에 하나의 프로젝트로 접근해서 Compute Engine 메뉴를 확인해 봅니다. 개발환경의 프로젝트에는 ‘environment:development’ tag 가 지정되어 있으므로 IAM Condition 조건에 충족되고 정의된대로 Viewer 권한 이외에 Compute Admin 권한이 같이 적용됩니다. 즉, 같은 iamtest01@ 사용자 이지만 ‘environment:development’ tag 가 지정되어 있는 개발환경 프로젝트에서는 GCE 의 생성과 실행, 삭제도 가능한 것을 관리 콘솔에서 확인 가능합니다.<figure></figure>보시는 것처럼 Tag 와 IAM Condition 의 조합을 통해서(또는, Deny policy 로) 조직 환경에서 다수의 프로젝트가 있을때 효율적으로 tag 를 활용하여 IAM 권한 관리 및 제어를 수행 가능합니다.첨부 #2.2) 본 이야기에서는 실제 실습은 간단하게 IAM Condition 과 tag 만 봤지만 기언급한 것처럼 Deny policy 도 tag 를 활용하여 좀 더 상세하게 제어 가능합니다.<a href="https://cloud.google.com/iam/docs/deny-overview#blocking-tags" rel="noopener ugc nofollow" target="_blank">https://cloud.google.com/iam/docs/deny-overview#blocking-tags</a><figure></figure>Deny policy 를 작성하려면 Google cloud 관리콘솔 IAM 메뉴에서 Deny 탭에서 생성 가능합니다. (Deny policy 는 IAM 의 사용자 레벨로 적용되는게 아니라 조직/폴더/프로젝트 레벨로 적용됩니다.)<figure></figure>그리고, ‘+Add denial condition’ 버튼을 클릭하여 이전에 IAM Condition 에서 작성한 것과 동일한 Condition Builder 나 Condition Editor 를 사용하여 tag 를 이용한 조건을 추가할 수 있습니다.<figure></figure></div></div>

Stories by 이정운 (Jungwoon Lee) on Medium

[GCP]Google cloud 를 좀 더 효과적이고 체계적으로 관리하기 위한 방안 알아보기 2부 — Tag 와 IAM Condition & Deny policy
안녕하세요 이정운 입니다.
Google cloud 에서 조직을 사용하면서 대규모로 프로젝트들을 사용하고 있는 경우 이러한 대규모 환경에서 효과적이고 체계적인 관리를 위해서 도움이 될만한 기능들이 뭐가 있을지 하나씩 살펴보는 시리즈를 하단과 같이 진행하고 있습니다.
[GCP]Google cloud 의 효과적이고 체계적으로 관리하기 위한 방안 알아보기 1부 — Label 과 Tag
지난 시간에는 첫번째 시간으로 key-value 형태로 구성되어 리소스를 식별 및 분류하는데 사용하거나 비용 분석을 세분화할 수 있는 label 과 이와 유사하면서도 리소스 계층의 상속 구조로 정의 가능하기도 하고 IAM Condition 이나 Organization Policy 등과 같은 다른 제어 기능과 함께 좀 더 세분화된 제어를 수행할 수 있는 tag 에 대해서 간단하게 살펴봤었습니다.
이번 이야기에서는 첫번째 시간에서 간단하게 살펴본 tag 에 대한 시나리오를 좀 더 정확하게 이해하는 시간을 갖기위해서 실제로 tag 가 IAM Condition 과 같은 정책 엔진에 조건으로 어떻게 활용될 수 있고 이를 통해서 어떻게 효과적이고 체계적인 관리를 수행할 수 있는지 예제를 통해서 살펴보도로록 하겠습니다.
#1) Tag 와 IAM Condition 이란 ?
Tag 는 지난 이야기에서도 설명했지만 key-value 쌍으로 이루어졌고 특정 tag 가 있는지 여부에 따라 IAM Condition 이나 Organization policy 와 같은 정책을 조건부로 허용하거나 거부하는 방법을 제공할 수 있다고 말씀드렸습니다. 이렇듯 Tag 는 기 언급한 것처럼 정책을 지정하는 기능과 연동되어서 조건으로 활용되는데 이러한 정책 관련 기능중의 대표적인 것이 IAM Condition 입니다.
IAM Condition 이란 이름 그대로 IAM(Identity and Access Management) 을 통해서 역할이나 권한을 부여할 때 특정 조건을 줄 수 있는 기능입니다. (AWS 사용자는 IAM Policy 와 유사한 형태로 이해하면 도움이 될듯 합니다.) IAM 은 이미 잘 아시겠지만 해당 프로젝트에 사용자를 초대하거나 필요한 역할, 권한을 부여하는 기능을 의미하며 Google cloud 의 IAM 의 특징은 리소스 계층구조에 따라 조직 > 폴더 > 프로젝트로 사용자와 권한의 상속 기능이 지원된다는 점입니다. 즉, 해당 사용자를 폴더에 추가하고 권한을 준다면 해당 폴더와 그 하위의 모든 프로젝트들에 해당 사용자는 상속을 통해서 동일한 권한을 가진채 추가되며 해당 사용자는 해당 프로젝트들에 대해서 지정된 권한을 수행할 수 있습니다.
https://cloud.google.com/iam/docs/overview
다만, 이번 이야기에서 IAM 을 자세히 다룰것은 아니라서 IAM 은 어느 정도 이해하고 있다고 가정하고 IAM Condition 에 대해서 좀 더 이야기를 진행하도록 하겠습니다. IAM Condition 은 예를 들면 ‘영희’ 라는 사용자에게 GCE 를 생성, 삭제 등을 할 수 있는 Compute Admin 이라는 역할을 부여할 때 env 라는 tag 의 값이 test 일 경우에만 권한을 부여하도록 하거나, 오전 9시에서 6시까지만 권한을 주는등 특정 조건을 추가하는 것 입니다. 이렇게 IAM Condition 을 사용해서 권한을 부여하게 되면 ‘영희’ 라는 사용자는 ‘env:test’ 라는 tag 와 값을 가진 프로젝트에서만 GCE 를 생성, 삭제 등을 할 수 있는 권한을 가지게 됩니다.(또는, 특정 시간에만) 이와 같이 IAM 을 설정할때 필요한 조건을 설정할 수 있는 기능을 IAM Condition 이라고하며 tag 이외에 리소스나 시간같은 더 다양한 조건을 추가적으로 활용할 수도 있습니다.
Overview of IAM Conditions
https://cloud.google.com/iam/docs/conditions-overview
https://cloud.google.com/blog/topics/developers-practitioners/cloud-iam-google-cloud
#2) Deny policy 란 ?
IAM Condition 은 일반적으로 많이 이해하고 있는 것처럼 역할이나 권한을 부여해서 그 역할을 허용하는 형태의 Allow policy 뿐만 아니라 반대형태로 동작하여 그 역할이나 권한을 사용하지 못하게 하는 형태의 Deny policy 라는 기능도 같이 제공할 수 있습니다. 그리고, 이때도 tag 를 그 조건으로 같이 활용할 수 있습니다.
Deny policy 는 이름 그대로 지정한 특정 조건에 맞다면 해당 역할을 거꾸로 사용하지 못하게 방지하는 형태로 동작하는 정책을 의미합니다. 이 부분을 조금만 더 자세하게 살펴보면 Deny policy 는 IAM 에 추가하는 것이 아니라 조직이나 폴더, 프로젝트 리소스 단위로 추가(attach) 가능하며 Deny rule 을 작성하여 해당 사용자가 심지어 관리자 권한이 있더라도 특정 조건을 설정하여 그 조건에 맞다면 그 권한을 사용하지 못하게 합니다. 이를 통해서 결국은 특정 권한에 대한 접근을 제어하여 마치 조직이나 프로젝트에 가드레일을 설정하는 것처럼 활용할 수 있습니다.
https://cloud.google.com/iam/docs/deny-overview#use-cases
상단의 공식 링크에 있는 예제를 참고해서 예를 하나 들어보겠습니다. 조직 구조 안에서 모든 프로젝트 관리자가 custom role 을 만들 수 있는 기능을 가지고 있어서 저마다 custom role 을 만들어서 활용하다보니 조직 관리 측면에서 원하지 않는 다양한 custom role 이 만들어지고 관리가 안되다보니 잘못된 권한 부여 등으로 권한관리에 이슈가 있는 상황이라면 Deny policy 를 활용하여 이를 간단하게 방지할 수 있습니다. Deny policy 를 상단의 예제와 같이 설정하면 특정 사용자 그룹에게만 custom role 을 만들 수 있는 권한을 주고 프로젝트 관리자를 포함하여 다른 모든 사용자에게는 해당 권한을 주지 않는 형태로 권한을 제어하는 가드레일을 설정 할 수 있습니다. (참고로 IAM 의 Best practices 중의 하나로 이러한 권한 부여의 경우는 사용자 보다는 그룹을 사용하는 것을 추천합니다.)
즉, Deny policy 를 적용하면 예외 주체(principals)로 정의된 custom-role-admins@example.com 이라는 그룹만 custom role 을 만들 수 있는 권한을 가질수 있고 다른 모든 사용자는 해당 권한을 가질 수 없습니다.
하단의 예제를 추가하여 좀 더 상세하게 설명 드리면, Yuri@ 와 Tai@ 라는 사용자 둘다 Organization Role Administrator 역할을 가지고 있어서 custom role 을 만들수 있을거 같지만 Yuri@ 만 custom-role-admins@ 그룹의 멤버이기 때문에 Deny policy 에 의해서 Tai@ 는 결국 custom role 을 만들 수 있는 권한이 제공되지 않습니다.
이를 다시 실제 운영환경의 시나리오로 엮어서 생각해보면 Deny policy 를 정의하여 프로젝트 관리자라고 해도 custom role 을 생성 못하게 조직내의 가드레일을 세우고 운영하다가 반드시 custom role 을 생성해야 하는 경우가 발생한다면, 해당 사용자만 잠시 custom-role-admins@ 그룹의 멤버로 추가해서 custom role 을 만들수 있도록 허용한 후에 작업을 진행합니다. 그 후 작업이 완료되면 다시 해당 사용자를 custom-role-admins@ 그룹의 멤버에서 빼면 Deny policy 에 의해서 다시 해당 권한을 사용하지 못하므로 민감한 권한에 대한 관리를 쉽게 제어할 수 있습니다.
#3) Tag 와 IAM Condition 테스트
우선 Tag 와 IAM Condition 을 어떻게 같이 활용할 수 있는지 실제 살펴보기 위해서 조직에 폴더를 구성하고 tag 를 하단과 같이 지정합니다. (tag key 로 environment 를 사용했고 tag value 로 production, development 를 사용했습니다.)
꼭, 제 환경과 동일하게 작업할 필요는 없고 조직에 폴더 구조만 있으면 동일하게 테스트 가능합니다. 간단하게 테스트를 위한 조직 구조를 설명드리면 Depart001 라는 부서에 Team01 과 Team02 가 있는데 Team01 은 운영환경의 프로젝트들을 관리하고 Team02 는 개발환경의 프로젝트를 관리한다는 가정으로 조직과 폴더 구조를 만들었습니다. 그리고 여기다가 Depart001 폴더 레벨에서 ‘environment:production’ tag 를 추가하고 전체가 다 상속 받게 한 후에 Team02 폴더만 해당 폴더 레벨에서 tag value 만 ‘development’ 로 오버라이드 하였습니다.
이렇게 환경이 준비되었다면 이제 Depart001 의 Team02 에 iamtest01@ 라는 새로운 개발자가 왔다고 가정을 해보도록 하겠습니다. 그리고 해당 개발자에게 Team01이 관리하는(폴더 Team01 아래 위치한) 운영환경과, Team02이 관리하는(폴더 Team02 아래 위치한) 개발 환경을 볼 수 있는 Viewer 라는 기본 역할을 주어야 하며 추가적으로 개발 환경에만 GCE(VM) 를 생성, 삭제할 수 있는 Compute Admin 권한을 주어야 한다고 가정해보겠습니다.
Google cloud 관리콘솔 IAM 메뉴에서 ‘+Grant Access’ 버튼을 클릭하여 iamtest01@ 사용자를 추가하고 Viewer 와 Compute Admin 역할을 할당합니다. 이때 바로 Save 를 누르지 말고 Compute Admin 역할 우측에 있는 ‘+Add IAM Condition’ 버튼을 클릭합니다.
IAM Condition 에 원하는 이름을 넣고 Condition Builder 에서 필요한 조건을 선택해서 지정할 수 있습니다. 하단에 보시면 아시겠지만 다양한 리소스를 조건으로 사용할 수도 있고 당연히 tag 도 조건으로 사용할 수 있습니다.
여기서는 tag 를 선택하고 Operator 로는 ‘has value’(해당 값을 가지고 있으면) 를 선택합니다. 그리고 마지막으로 원하는 tag value 의 value path 를 넣어주면 됩니다. (제가 사용한 예제 값 : ‘environment:development’ — jungwoonlee.altostrat.com/environment/development)
첨부 #2.1) 손쉽게 클릭해서 선택하는 Condition Builder 말고도 직접 CEL 형태로 정의할 수 있는 Condition Editor 를 사용할 수도 있습니다. (또는, Builder 로 설정하고 Editor 를 클릭하면 자동으로 CEL 로 변경된 결과를 확인할 수 있습니다.)
CEL 사용 방법 및 좀 더 다양한 예제들은 하단의 공식 메뉴얼을 참고하시기 바라겠습니다 .
https://cloud.google.com/iam/docs/conditions-overview#cel
이렇게 설정 후 저장 하면 하단과 같이 iamtest01@ 사용자에게 할당되는 Compute Admin 역할에 IAM condition 이 추가된 것을 확인할 수 있습니다.
이제 실제로 해당 역할을 부여하기 위해서 저장하면 IAM 메뉴에서 부여된 역할 이외에 IAM condition 이 추가 지정된 것을 확인할 수 있습니다.
그럼 이제 설정이 완료되었으니 iamtest01@ 사용자로 로그인 해서 관리콘솔로 들어옵니다. 관리콘솔 좌측 상단의 프로젝트 픽커를 클릭해서 설정한데로 Team01 이 관리하는 운영환경과 Team02 가 관리하는 개발환경이 다 보이는지 확인합니다.
Team01 이 관리하는 운영환경 중에 하나의 프로젝트로 접근해서 Compute Engine 메뉴를 확인해 봅니다. 운영환경의 프로젝트에는 ‘environment:production’ tag 가 붙어있으므로 Viewer 권한만 동작하며 GCE 를 생성하거나 실행, 삭제하는 등의 권한이 없는 것을 확인할 수 있습니다. (하단의 스크린 캡춰에서 확인할 수 있는 것처럼 GCE 에 대한 Start/Resume, Stop 등의 기능이 disable 된것을 보실 수 있습니다.)
이제 Team02 가 관리하는 개발환경 중에 하나의 프로젝트로 접근해서 Compute Engine 메뉴를 확인해 봅니다. 개발환경의 프로젝트에는 ‘environment:development’ tag 가 지정되어 있으므로 IAM Condition 조건에 충족되고 정의된대로 Viewer 권한 이외에 Compute Admin 권한이 같이 적용됩니다. 즉, 같은 iamtest01@ 사용자 이지만 ‘environment:development’ tag 가 지정되어 있는 개발환경 프로젝트에서는 GCE 의 생성과 실행, 삭제도 가능한 것을 관리 콘솔에서 확인 가능합니다.
보시는 것처럼 Tag 와 IAM Condition 의 조합을 통해서(또는, Deny policy 로) 조직 환경에서 다수의 프로젝트가 있을때 효율적으로 tag 를 활용하여 IAM 권한 관리 및 제어를 수행 가능합니다.
첨부 #2.2) 본 이야기에서는 실제 실습은 간단하게 IAM Condition 과 tag 만 봤지만 기언급한 것처럼 Deny policy 도 tag 를 활용하여 좀 더 상세하게 제어 가능합니다.
https://cloud.google.com/iam/docs/deny-overview#blocking-tags
Deny policy 를 작성하려면 Google cloud 관리콘솔 IAM 메뉴에서 Deny 탭에서 생성 가능합니다. (Deny policy 는 IAM 의 사용자 레벨로 적용되는게 아니라 조직/폴더/프로젝트 레벨로 적용됩니다.)
그리고, ‘+Add denial condition’ 버튼을 클릭하여 이전에 IAM Condition 에서 작성한 것과 동일한 Condition Builder 나 Condition Editor 를 사용하여 tag 를 이용한 조건을 추가할 수 있습니다.
이번 이야기에서는 Google cloud 의 조직으로 다수의 프로젝트를 운영할때 효과적이고 체계적으로 관리하기 위한 방안의 두번째로 Tag 와 IAM Condition & Deny policy 에 대한 이야기를 했습니다. 특히, 초반부에서는 IAM Condition 이 무엇인지, Deny policy 가 무엇인지를 살짝 살펴보고 운영환경에서 어떻게 이를 활용해서 가드레일을 세울지에 대해서 간단한 예제를 가지고 논의해보기도 했습니다. 다음으로 IAM Condition 에서 어떻게 tag 를 가지고 조건을 만들 수 있는지와 이 부분이 실제로 어떻게 동작하는 지를 직접 실습을 통해서 확인해보는 시간을 가졌었습니다.
이번 이야기를 통해서 Tag 와 IAM Condition/Deny policy 에 대해서 조금 더 이해할 수 있는 시간이 되었기를 바랍니다. 그럼 이번 이야기는 여기서 마무리 하도록 하겠으며 다음에 더 좋은 이야기로 다시 돌아오도록 하겠습니다. ;)
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
IAM overview
https://cloud.google.com/iam/docs/overview
Cloud IAM Google Cloud
https://cloud.google.com/blog/topics/developers-practitioners/cloud-iam-google-cloud
Common use cases
https://cloud.google.com/iam/docs/deny-overview#use-cases
CEL for conditions
https://cloud.google.com/iam/docs/conditions-overview#cel
Blocking access based on tags
https://cloud.google.com/iam/docs/deny-overview#blocking-tags
[GCP]Google cloud 를 좀 더 효과적이고 체계적으로 관리하기 위한 방안 알아보기 2부 — Tag 와 IAM Condition & Deny policy 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 를 좀 더 효과적이고 체계적으로 관리하기 위한 방안 알아보기 2부 — Tag 와 IAM Condition & Deny policy

댓글