IAM deny policies in GCP - Commands & Configuration

Introduction

Sometimes you want to block certain actions for users even if other permissions allow them. IAM deny policies let you explicitly stop users from doing specific things, adding an extra layer of control.

When you want to prevent a user from deleting storage buckets even if they have broad permissions.

When you need to block access to sensitive resources for a group temporarily without changing their roles.

When you want to deny a specific API action for all users in a project.

When you want to enforce security rules that override granted permissions.

When you want to quickly stop access to a resource without removing existing permissions.

Config File - deny-policy.yaml

deny-policy.yaml

bindings:
- role: roles/iam.denyAll
  members:
  - user:[e-mail]
  deny_rules:
  - denied_permissions:
    - storage.buckets.delete
    - storage.objects.delete
    denial_condition:
      expression: "resource.name.startsWith('projects/_/buckets/my-sensitive-bucket')"
      title: "Deny delete on sensitive bucket"
      description: "Prevent deleting buckets and objects in my-sensitive-bucket"

This YAML file defines a deny policy that blocks the user [e-mail] from deleting storage buckets and objects in the bucket named 'my-sensitive-bucket'.

bindings: Lists who the policy applies to and what is denied.

role: Uses the special deny role roles/iam.denyAll to specify deny rules.

deny_rules: Lists the permissions to deny and the condition when to deny them.

denial_condition: Limits the deny to resources starting with the bucket name.

Commands

This command applies the deny policy defined in deny-policy.yaml to the project 'my-project'. It sets the deny rules to block specified actions.

Terminal

gcloud iam policies set-deny deny-policy.yaml --project=my-project

Expected Output

Updated deny policy for project [my-project].

→

--project - Specifies the GCP project where the deny policy is applied.

This command shows the current IAM policies including deny policies for the project to verify the deny rules are set.

Terminal

gcloud iam policies describe --project=my-project

Expected Output

bindings:

- members:

  - user:[e-mail]

  role: roles/iam.denyAll

  denyRules:

  - deniedPermissions:

    - storage.buckets.delete

    - storage.objects.delete

    denialCondition:

      expression: resource.name.startsWith('projects/_/buckets/my-sensitive-bucket')

      title: Deny delete on sensitive bucket

      description: Prevent deleting buckets and objects in my-sensitive-bucket

→

--project - Specifies the project to show policies for.

Key Concept

If you remember nothing else from this pattern, remember: deny policies explicitly block actions even if other permissions allow them.

Common Mistakes

Not specifying the denial_condition, causing the deny to apply everywhere.

This blocks the denied permissions on all resources, which can break unrelated workflows.

Always use denial_condition to limit the deny to specific resources or situations.

Applying deny policies without testing, causing unexpected access issues.

Deny policies override allow permissions and can lock out users unintentionally.

Test deny policies in a safe environment or with limited users before wide deployment.

Summary

Create a deny policy YAML file specifying who and what to deny with optional conditions.

Apply the deny policy to your GCP project using gcloud iam policies set-deny.

Verify the deny policy is active by describing the IAM policies with gcloud.

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