Google Cloud has moved IAM Deny policies into full general availability. IAM Deny policies work alongside the IAM Allow policies to provide more options for controlling which principals have access to which resources. IAM Deny policies are available with Google Cloud IAM for most permissions.
Ravi Shah, head of product for Google cloud, describes IAM Deny policies as providing "a powerful, coarse-grained access control to help implement security policies at scale." This is meant to complement the more granular control provided by IAM Allow policies. IAM Deny policies are evaluated first and always supersede IAM Allow policies.
Deny policies are made up of deny rules. Deny rules specify a set of principals that are denied permissions, the permissions that the principals are denied, and optionally, a condition that must be true for the permission to be denied. Deny policies are applied at the project, folder, or organization level. Each project, folder, or organization can have up to five deny policies, which are evaluated independently. Once attached to a project, folder, or organization, the Deny policy will apply to all resources within that grouping.
The IAM Deny policies cannot be used with all permissions within Google Cloud. Deny policies require the IAM v2 permission format. These are in the form SERVICE_FQDN/RESOURCE.ACTION where SERVICE_FQDN is the value of SERVICE_ID from the v1 API with .googleapis.com appended to it. For example, the permission to delete a role in the v2 permission format is iam.googleapis.com/roles.delete. A complete list of supported permissions is available within the Google Cloud documentation.
IAM Deny policies support an optional condition. The deny rule will only take effect if the condition evaluates to true or cannot be evaluated. If the condition evaluates to false, then the principal is not denied access to the permission by that policy.
The following example 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:
{
"name": "policies/cloudresourcemanager.googleapis.com%2Fprojects%2F253519172624/denypolicies/limit-project-deletion",
"uid": "06ccd2eb-d2a5-5dd1-a746-eaf4c6g3f816",
"kind": "DenyPolicy",
"displayName": "Only project admins can delete projects.",
"etag": "MTc1MTkzMjY0MjUyMTExODMxMDQ=",
"createTime": "2021-09-07T23:15:35.258319Z",
"updateTime": "2021-09-07T23:15:35.258319Z",
"rules": [
{
"denyRule": {
"deniedPrincipals": [
"principalSet://goog/public:all"
],
"exceptionPrincipals": [
"principalSet://goog/group/project-admins@example.com"
],
"deniedPermissions": [
"cloudresourcemanager.googleapis.com/projects.delete"
],
"denialCondition": {
"title": "Only for non-test projects",
"expression": "!resource.matchTag('12345678/env', 'test')"
}
}
}
]
}
The introduction of IAM Deny policies more closely aligns Google Cloud's implementation of IAM with AWS's. Both IAM tools are structured around an implicit deny approach implying that all requests are denied unless specifically allowed. The explicit deny is evaluated first in both cloud solutions and overrides any subsequent allow privileges.
Google Cloud IAM Deny policies are available now within the IAM tool for a subset of permissions. More details about IAM Deny can be found in the release blog post and within the Google Cloud documentation.