IAM deny policies in GCP - Step-by-Step Execution

Process Flow - IAM deny policies

User Request

↓

Check IAM Allow Policies

↓

Check IAM Deny Policies

↓

Allow Access

↓

Deny Access

↓

End

When a user makes a request, GCP first checks allow policies, then deny policies. If any deny policy matches, access is denied immediately.

Execution Sample

GCP

resource: projects/my-project
policy:
  rules:
    - deniedPermissions: ["storage.buckets.delete"]
      deniedPrincipals: ["*"]

This deny policy blocks deletion of storage buckets in the project.

Process Table

Step	Action	Permission Checked	Deny Policy Match	Access Decision
1	User requests to delete a storage bucket	storage.buckets.delete	Yes	Denied
2	User requests to read a storage bucket	storage.buckets.get	No	Allowed
3	User requests to create a storage bucket	storage.buckets.create	No	Allowed
4	User requests to delete a VM instance	compute.instances.delete	No	Allowed
5	User requests to delete a storage bucket again	storage.buckets.delete	Yes	Denied

💡 Access denied immediately when deny policy matches; otherwise allowed if no deny matches.

Status Tracker

Variable	Start	After 1	After 2	After 3	After 4	After 5
Permission Requested	-	storage.buckets.delete	storage.buckets.get	storage.buckets.create	compute.instances.delete	storage.buckets.delete
Deny Policy Match	-	Yes	No	No	No	Yes
Access Decision	-	Denied	Allowed	Allowed	Allowed	Denied

Key Moments - 2 Insights

Why is access denied even if the allow policy permits the action?

Because deny policies have higher priority. As shown in execution_table step 1, even if allow exists, deny match causes immediate denial.

What happens if no deny policy matches the requested permission?

Access is allowed if allow policies permit it, as seen in steps 2, 3, and 4 of the execution_table.

Visual Quiz - 3 Questions

Look at the execution_table at step 3. What is the access decision for creating a storage bucket?

A Denied

B Pending

C Allowed

D Unknown

💡 Hint

Check the 'Access Decision' column for step 3 in the execution_table.

At which step does the deny policy cause access to be denied?

A Step 4

B Step 1

C Step 2

D Step 3

💡 Hint

Look for 'Yes' in 'Deny Policy Match' column in the execution_table.

If the deny policy is removed, what would happen at step 1?

A Access would be allowed

B Access would still be denied

C Access decision would be unknown

D Access would be delayed

💡 Hint

Refer to variable_tracker and execution_table to see deny policy effect on access.

Concept Snapshot

IAM Deny Policies in GCP:
- Deny policies explicitly block permissions.
- Evaluated after allow policies.
- If deny matches, access is denied immediately.
- Useful to enforce strict security rules.
- Deny policies override allow policies.

Full Transcript

When a user requests access to a resource, GCP first checks if the allow policies permit the action. Then it checks deny policies. If any deny policy matches the requested permission, access is denied immediately, regardless of allow policies. For example, a deny policy blocking 'storage.buckets.delete' will prevent users from deleting storage buckets even if they have allow permissions. If no deny policy matches, access is granted if allowed. This ensures strict control over sensitive actions.

Practice

1. What is the main purpose of an IAM deny policy in Google Cloud?

easy

A. To monitor user activities without changing permissions

B. To grant additional permissions to users or groups

C. To explicitly block certain permissions even if other policies allow them

D. To automatically delete unused resources

Solution

1. Step 1: Understand IAM deny policy function and compare with other policy types

   An IAM deny policy explicitly blocks permissions, overriding any allow policies. Unlike allow policies that grant access, deny policies prevent actions even if allowed elsewhere.

2. Final Answer:

   To explicitly block certain permissions even if other policies allow them -> Option C

3. Quick Check:

   IAM deny policy blocks permissions [OK]

Hint: Deny policies block permissions regardless of other allows [OK]

Common Mistakes:

• Confusing deny policies with allow policies
• Thinking deny policies grant permissions
• Assuming deny policies only monitor actions

2. Which of the following is the correct way to specify a deny rule in an IAM policy JSON snippet?

easy

A. "denyRules": [{"deniedPermissions": ["storage.buckets.delete"]}]

B. "allowRules": [{"allowedPermissions": ["storage.buckets.delete"]}]

C. "denyRules": [{"allowedPermissions": ["storage.buckets.delete"]}]

D. "denyRules": [{"deniedPermissions": "storage.buckets.delete"}]

Solution

1. Step 1: Identify correct deny rule syntax and check each option

   Deny rules use "denyRules" with "deniedPermissions" as a list of strings. "denyRules": [{"deniedPermissions": ["storage.buckets.delete"]}] correctly uses a list for "deniedPermissions". "allowRules": [{"allowedPermissions": ["storage.buckets.delete"]}] uses allowRules, which is incorrect. "denyRules": [{"allowedPermissions": ["storage.buckets.delete"]}] mixes denyRules with allowedPermissions, which is invalid. "denyRules": [{"deniedPermissions": "storage.buckets.delete"}] uses a string instead of a list, which is invalid.

2. Final Answer:

   "denyRules": [{"deniedPermissions": ["storage.buckets.delete"]}] -> Option A

3. Quick Check:

   Deny rules need deniedPermissions as list [OK]

Hint: Deny permissions must be in a list under deniedPermissions [OK]

Common Mistakes:

• Using allowRules instead of denyRules
• Providing deniedPermissions as a string instead of list
• Mixing allowedPermissions inside denyRules

3. Given this deny policy snippet:

{"denyRules": [{"deniedPermissions": ["compute.instances.start"]}]}

What happens if a user has an allow policy for compute.instances.start but this deny policy is applied?

medium

A. The user can start instances because allow policies override deny policies

B. The deny policy has no effect unless combined with a condition

C. The user can start instances only during business hours

D. The user cannot start instances because deny policies block the permission

Solution

1. Step 1: Understand deny policy precedence and apply to the example

   Deny policies always override allow policies for the specified permissions. Even if the user has an allow for starting instances, the deny rule blocks it.

2. Final Answer:

   The user cannot start instances because deny policies block the permission -> Option D

3. Quick Check:

   Deny overrides allow for blocked permissions [OK]

Hint: Deny always beats allow for the same permission [OK]

Common Mistakes:

• Thinking allow policies override deny policies
• Assuming deny policies need conditions to work
• Believing deny policies only log actions

4. You wrote this deny policy JSON but it does not block the intended permission:

{"denyRules": [{"deniedPermissions": "storage.objects.delete"}]}

What is the error?

medium

A. denyRules should be named allowRules

B. deniedPermissions should be a list, not a string

C. storage.objects.delete is not a valid permission

D. The policy must include a condition to work

Solution

1. Step 1: Check deniedPermissions data type and identify the error in the JSON

   deniedPermissions must be a list of strings, not a single string. The policy uses a string instead of a list, so it is invalid and won't block the permission.

2. Final Answer:

   deniedPermissions should be a list, not a string -> Option B

3. Quick Check:

   deniedPermissions requires a list [OK]

Hint: Use brackets [] for deniedPermissions list [OK]

Common Mistakes:

• Using string instead of list for deniedPermissions
• Confusing denyRules with allowRules
• Thinking conditions are mandatory

5. You want to deny the permission storage.buckets.delete only for requests made after 2024-01-01T00:00:00Z. Which IAM deny policy condition should you use?

hard

A. Use a condition with request.time > '2024-01-01T00:00:00Z'

B. Use a condition with resource.name == 'storage.buckets.delete'

C. No condition is needed; deny applies to all users

D. Use a condition with request.ip != 'company-network-ip-range'

Solution

1. Step 1: Identify the condition to restrict by time and match condition syntax

   To deny only for requests after the date, use a condition checking request.time > '2024-01-01T00:00:00Z'. Use a condition with request.time > '2024-01-01T00:00:00Z' uses request.time with inequality to apply after the date, which is correct.

2. Final Answer:

   Use a condition with request.time > '2024-01-01T00:00:00Z' -> Option A

3. Quick Check:

   Condition on request.time restricts deny by time [OK]

Hint: Use request.time condition to limit deny by time [OK]

Common Mistakes:

• Using resource.name instead of request.time for time check
• Using IP condition unrelated to time
• Applying deny without condition blocks all users