A security audit reveals that the Google Group `[email protected]` has been granted the `roles/compute.admin` role at a parent Folder level named `Finance-Prod`. This folder contains ten production projects, including a sensitive audit project named `payments-main`. Company security policy requires members of `[email protected]` to retain Compute Engine administrative access across nine of the projects, but they must explicitly have no administrative access to `payments-main`. How should you restructure the IAM configuration to meet this requirement following the principle of least privilege?
- Remove the `roles/compute.admin` role binding for `[email protected]` from the `Finance-Prod` folder, and grant the `roles/compute.admin` role directly on each of the nine projects that require it.Cevap
- BNavigate to the `payments-main` project IAM policy settings and remove the `roles/compute.admin` role assignment for `[email protected]`.
- CGrant the `roles/viewer` primitive role to `[email protected]` on the `payments-main` project to override the folder-level administrative privileges.
- DUnlink the `payments-main` project from the shared Billing Account and re-link it using a restricted billing account user role.
Cevap
Remove the `roles/compute.admin` role binding for `[email protected]` from the `Finance-Prod` folder, and grant `roles/compute.admin` individually on the nine projects requiring access.
In Google Cloud, IAM policy evaluation is additive down the resource hierarchy (Organization > Folder > Project > Resource). If a role is granted at the Folder level, all projects under that folder inherit those permissions. Because inherited permissions cannot be revoked or overridden at a child project level, the folder-level role grant must be removed and replaced with explicit project-level grants on only the projects that require access.
Adım Adım Çözüm
Anahtar Kavram
Resource Hierarchy IAM Policy Additive Inheritance