Identity and Access Management (IAM) is a system that grants granular access to specific Google Cloud resources and helps prevent access to other resources. Also, have security with the least privilege. IAM access control follows who (identity) has what access (role) for which resource. Google cloud’s IAM deny policies work alongside IAM allow policies as you define access to your resources. IAM deny policy override conflicting IAM Allow rules and IAM deny policies always supersede IAM Allow policies.
IAM deny policies workflow
Deny Policies and their working
With Google cloud’s IAM deny policies, you can set guardrails on access to Google Cloud resources. Deny policies made from deny rules will prevent certain principals from using permissions, regardless of the granted roles. IAM checks deny policies before checking allow policies, and if a principal denies permission, you cannot do anything which requires that permission. To apply a policy, you can attach it to a project, folder, or organization. If a deny policy is applied to a project, folder, or organization, the principals in the policy can’t use the specified permissions to access the resource. And each of them can have a maximum of 5 deny policies.
AMI deny policy evaluation flow
Use cases where IAM Deny policies used to strengthen your security posture are:
- Establish a default security baseline for an organization, folder, and project to deny access to resources.
- To prevent ‘backdoors’ as IAM Deny rules override any IAM Allow rules.
- To prevent exfiltration by controlling access to data.
- IAM Deny policies demonstrate least-privilege access to sensitive resources.
Deny policies can use only some of the google cloud’s IAM permissions. You can use IAM v2 permission format, which is SERVICE_FQDN/RESOURCE.ACTION. Here the value of SERVICE_FQDN is typically that of SERVICE_ID from the v1 API, followed by .googleapis.com. An example of this is the permission to delete a role is iam.googleapis.com/roles.delete.
The structure of deny policy consist of a collection of metadata and deny rules. Each deny rule specifies a condition that determines when the permission is denied. And denial conditions specify the conditions that must be met for a deny rule to apply. The example given below blocks all principals from deleting projects unless the principal is a member of the project-admins@example.com security group or the project has a tag with the value of test:
Here name, uid, kind, displayName, etag, createTime, updateTime are metadata. And deniedPrincipals, exceptionPrincipals, deniedPermissions are fields of deny rule.
Conclusion
Google cloud’s IAM deny policies help you easily create access guardrails for Google Cloud resources. Also, you can create rules that broadly restrict resource access. IAM deny policies provide powerful, coarse-grained access control to help implement security policies at scale.
Metclouds Technologies helps you to create access guardrails for Google Cloud resources with IAM deny policies.