GCP – Just say no: Build defense in depth with IAM Deny and Org Policies

In today’s cloud landscape, safeguarding your cloud environment requires bolstering your Identity and Access Management (IAM) approach with more than allow policies and the principle of least privilege. To bolster your defenses, we offer a powerful tool: IAM Deny Policies.

Relying only on IAM Allow policies leaves room for potential over-permissioning, and can make it challenging for security teams to consistently enforce permission-level restrictions at scale. This is where IAM Deny comes in.

IAM Deny provides a vital, scalable layer of security that allows you to explicitly define which actions principals can not take, regardless of the roles they have been assigned. This proactive approach can help prevent unauthorized access, and strengthens your overall security posture, providing admin teams overriding guardrail policies throughout their environment.

Understanding IAM Deny

The foundation of IAM Deny is built on IAM Allow policies. Allow policies define who can do what and where in a Google Cloud organization, binding principals (users, groups, service accounts) to roles that grant access to resources at various levels (organization, folder, project, resource).

IAM Deny, conversely, defines restrictions. While it also targets principals, the binding occurs at the organization, folder, or project level — not at the resource level.

Key differences between Allow and Deny Policies:

• IAM Allow: Focuses on granting permissions through role bindings to principals.

• IAM Deny: Focuses on restricting permissions by overriding role bindings given by IAM Allow, at a hierarchical level.

IAM Deny acts as a guardrail for your Google Cloud environment, helping to centralize the management of administrative privileges, reduce the need for numerous custom roles, and ultimately enhance the security of your organization.

How IAM Deny works

IAM Deny policies use several key components to build restrictions.

• Denied Principals (Who): The users, groups, or service accounts you want to restrict. This can even be “everyone”  in your organization, or even any principal regardless of organization (noted by the allUsers identifier).

• Denied Permissions (What): The specific actions or permissions that the denied principals cannot use. Most Google Cloud services support IAM Deny, but it’s important to verify support for new services.

• Attachment Points (Where): The organization, folder, or project where the deny policy is applied. Deny policies can not be attached directly to individual resources.

• Conditions (How): While optional, these allow for more granular control over when a deny policy is enforced. Conditions are set with Resource Tags using Common Expression Language (CEL) expressions, enabling you to apply deny policies conditionally (such as only in specific environments or unless a certain tag is present).

Start with IAM Deny

A crucial aspect of IAM Deny is its evaluation order. Deny policies are evaluated first, before any Allow policies. If a Deny policy applies to a principal’s action, the request is explicitly denied, regardless of any roles the principal might have. Only if no Deny policy applies does the system then evaluate Allow policies to determine if the action is permitted.

There are built-in ways you can configure exceptions to this rule, however. Deny policies can specify principals who are exempt from certain restrictions. This can provide flexibility to allow necessary actions for specific administrative or break-glass accounts.

When you can use IAM Deny

IAM Deny policies can be used to implement common security guardrails. These include:

• Restricting high-privilege permissions: Prevent developers from creating or managing IAM roles, modifying organization policies, or accessing sensitive billing information in development environments.

• Enforcing organizational standards: By limiting a set of permissions no roles can use, you can do things like prevent the misuse of overly-permissive Basic Roles, or restrict the ability to enable Google Cloud services in certain folders.

• Implementing security profiles: Define sets of denied permissions for different teams (including billing, networking, and security) to enforce separation of duties.

• Securing tagged resources: Apply organization-level deny policies to resources with specific tags (such as iam_deny=enabled).

• Creating folder-level restrictions: Deny broad categories of permissions (including billing, networking, and security) on resources within a specific folder, unless they have any tag applied.

Complementary security layers

IAM Deny is most effective when used in conjunction with other security controls. Google Cloud provides several tools that complement IAM Deny:

• Organization Policies: Allow you to centrally configure and manage organizational constraints across your Google Cloud hierarchy, such as restricting which APIs are available in your organization with Resource Usage Restriction policies. You can even define IAM Custom Constraints to limit which roles can be granted.

• Policy troubleshooter: Can help you understand why a principal has access or has been denied access to a resource. It allows you to analyze both Allow and Deny policies to pinpoint the exact reason for an access outcome.

• Policy Simulator: Enables you to simulate the impact of changes to your deny policies before applying them in your live environment. It can help you identify potential disruptions and refine your policies. Our Deny Simulator is now available in preview.

• IAM Recommender: Uses machine learning to analyze how you’ve applied IAM permissions, and provide recommendations for reducing overly permissive role assignments. It can help you move towards true least privilege.

• Privileged Access Management (PAM): Can manage temporary, just-in-time elevated access for principals who might need exceptions to deny policies. PAM solutions provide auditing and control over break-glass accounts and other privileged access scenarios.

• Principal Access Boundaries: Lets you define the resources that principals in your organization can access. For example, you can use these to prevent your principals from accessing resources in other organizations, which can help prevent phishing attacks or data exfiltration. 

Implementing IAM Deny with Terraform

The provided GitHub repository offers a Terraform configuration to help you get started with implementing IAM Deny and Organization Policies. This configuration includes:

• An organization-level IAM Deny Policy targeting specific administrative permissions on tagged resources.

• A folder-level IAM Deny Policy restricting Billing, Networking, and Security permissions on untagged resources.

• A Custom Organization Policy Constraint to prevent the use of the roles/owner role.

• An Organization Policy restricting the usage of specific Google Cloud services within a designated folder.

Key steps for using the Terraform configuration:

1. Clone the repository:

2. Navigate to the examples/iam-deny folder, then switch to the Terraform directory:

3. Prepare terraform.tfvars: Copy terraform.tfvars.example to terraform.tfvars and edit it to include your Organization ID, Target Folder ID, and principal group emails for exceptions.

4. Create a tag key and tag value in your organization to enable these policies

1. 1. You can name these whatever you want, but for our example you can use tag key (iamdeny) and tag value (enabled). 

5. Update `main.tf` Tag IDs: Replace placeholder tag key and value IDs with your actual tag IDs in the denial_condition section for each policy.

a. NOTE: This is optional, you can also use this expression to deny all resources when the policy is applied

Remember to review the predefined denied permissions in files like `billing.json`, `networking.json`, and `securitycenter.json` (located in the `/terraform/profiles/` directory) and the `denied_perms.tf` file to align them with your organization’s security requirements. 

6. Initialize, review and apply Terraform:

Always consult with your security team before deploying these policies.

Embrace the power of no

IAM is a critical component for enhancing security and its strategic implementation is key to a comprehensive defense-in-depth strategy. (Please see our IAM guides — I hate IAM but I need it desperately and Scaling the IAM mountain, an in-depth guide — for more information on getting started with IAM.)

Implementing IAM Deny policies is a crucial step in enhancing your Google Cloud security posture. By explicitly defining what principals cannot do, you add a powerful layer of defense against both accidental misconfigurations and malicious actors. 

When combined with Organization Policies, Policy Troubleshooter, Policy Simulator, and IAM Recommender, IAM Deny empowers you to enforce least privilege more effectively and build a more secure cloud environment. Start exploring the provided Terraform example and discover the Power of No in your Google Cloud security strategy.

This content was created from learnings gathered from work by Google Cloud Consulting with enterprise Google Cloud Customers. If you would like to accelerate your Google Cloud journey with our best experts and innovators, contact us at Google Cloud Consulting to get started.