문제 설명
Terraform 코드와 충돌하는 "소유자"에 의한 GCP 콘솔/클라우드 셸 변경을 어떻게 방지할 수 있습니까? (How can you prevent GCP console/cloud shell changes by "Owners" conflicting with the terraform code?)
나는 인프라를 코드로 배포하는 목적을 이해하고 있으며 코드 피어 리뷰 사전 배포를 시행할 수 있는 이점을 높이 평가합니다. 보안 관점에서 이 기술 제어는 환경에 대한 변경 사항이 동료 검토를 받는다는 것을 보장합니다.
그러나 관련 권한이 있는 사람(예: 소유자 역할 ) 콘솔/클라우드 셸에서 직접 변경하려면? 그러면 이 변경 사항은 동료 검토를 거치지 않을 것입니다.
이를 방지하기 위해 어떤 컨트롤이 있는지 확인하고 싶으신가요? 물론,
참조 솔루션
방법 1:
Nothing will stop a user to create/update/delete a resource manually (by manually I mean here : via Console or Cloud shell) if he has the IAM permissions to do so.
In the case of a manual resource update : if the resource is managed by Terraform, running terraform plan will alert you that a modification has been made. Indeed, Terraform will see a difference between the resource description in your .tf file and the reality. If you apply these changes, it will revert modifications made manually by the user.
Running periodic checks to verify if some modifications have been made out of Terraform (on resources managed by Terraform) could be a good idea to alert you that someone did something manually.
But in case of newly created resources (out of Terraform), unless the resource is imported in Terraform after creation (terraform import), you'll never know that this resource have been created, and you could not track any modifications on that resource. The only way to prevent resource creation is by restricting IAM permissions. For example, if nobody (unless Terraform service account) have the permission storage.buckets.create, then nobody (excepted Terraform service account) will be able to create a bucket. The same applies to resources update.
If you want all your resources to be managed by Terraform, remove the create/update IAM permissions to all users except Terraform service account. But be aware that :
- you can't create/update all GCP resources with Terraform. Even if Terraform providers grows fast, there will always be some delay between a new GCP product and its implementation in Terraform GCP provider. Some time ago, I remember myself waiting for Cloud Composer resource in Terraform, which appears in 1.18.0 version on 2018/09/17, though Cloud Composer was available since the 2018/05/01. If I have chosen to create resources with only Terraform, then I should have wait 4 months before starting to use Cloud Composer (this is an example amongst other)
- you may sometimes want to create resources outside of Terraform, for testing purpose for example. If Terraform is enforced to create/update all resources across your organization, this will not be possible. Think about non‑technical users who want to create temporarily some resources to make some tests : they probably won't learn how to use Terraform, so they'll either give up or ask someone to create resources for them. As your number of users increase, this should become cumbersome
- reasoning by the absurd : do you want to manage all resources available using Terraform? If so, then you may want to manage also Storage objects with Terraform, because there is a Terraform resource google_storage_bucket_object. Except some very specific cases, you don't want to manage these kind of resources with Terraform (in Storage objects case, think of huge files)
In conclusion, managing all your resources across your organization using Terraform and restrict only Terraform service account to create/update/delete resources is definitively a goal to aim for, and should be done as much as you can, but in reality, it is not always completely possible. Critical resources must be protected, and so IAM for updating/deleting them must be restricted. Also, owner role is not the only one that allows creating/updating/deleting resources. You will have to be very careful about roles you give to your users to ensure that they won't have such permission, and will probably rely on custom roles because predefined roles are often too broad.