Sudipta Deb
Founder of Technical Potpourri, Co-Founder of Shrey Tech, Enterprise Cloud Architect
In Google Cloud Platform (GCP), Deny Policies are a part of the Identity and Access Management (IAM) system, introduced to provide an additional layer of security by explicitly denying certain actions or access to specific resources. They help in defining more granular access controls, ensuring that certain permissions are explicitly blocked even if they are allowed by other IAM policies.
Traditionally, the "allow" concept of permissions in GCP (Google Cloud Platform) IAM (Identity and Access Management) has allowed you to define who can do what. Certain situations, nonetheless, need for the explicit denial of access to be specified. Deny policies are then applicable in the situation.
Regardless of any allow rights that might be given elsewhere, administrators can explicitly block access to specific resources using a Deny Policy in GCP IAM.
This is especially helpful when you want to make sure that specific acts are prohibited even though they might be allowed under other policies.
The form you have selected does not exist.
Watch The Video Or Read The Article (Or Do Both 
)
)Key Features of Deny Policies
Explicit Denial: Unlike traditional IAM policies that grant permissions, Deny Policies explicitly deny specified permissions. This prevents users from performing certain actions regardless of other permissions they might have.
Precedence over Allow Policies: Deny Policies take precedence over allow policies. If a deny policy prohibits an action, no other policy can override this decision to permit that action.
Granular Control: These policies can be defined at a fine-grained level, targeting specific actions, resources, or conditions under which the denial should be enforced.
Comprehensive Policy Language: Deny Policies use a comprehensive policy language that supports conditional logic, making it possible to create complex rules based on various attributes such as request time, IP address, or resource type.
Things To Note
- Each Deny Policy is lnked to a Google Cloud Organization, Folder or a Project.
- Deny Policies are inherited through resource hierarchy.
- Deny policy consits of deny rules and principals telling what is not allowed for the assigned principals.
- Deny policies always overwrite Allow Policies.
- A resource can have upto 5 deby policies.
- Here is the list of supported deny policies.
Required Roles
- Deny Reviewer (roles/iam.denyReviewer): View the deny policies.
- Deny Admin (roles/iam.denyAdmin): Create, View, Update and Delete deny policies.
Use Cases for Deny Policies
- Security Hardening: Enhancing security by explicitly denying high-risk actions such as deleting critical resources or changing security configurations.
- Compliance: Ensuring compliance with regulatory requirements by preventing access to sensitive data or operations.
- Error Prevention: Avoiding accidental changes to important resources by denying certain modification actions.
Creating and Managing Deny Policies
- Define the Policy: Write a deny policy using the JSON or YAML format, specifying the conditions and actions to be denied.
- Attach to Resources: Apply the deny policy to specific resources or hierarchically to a project, folder, or organization.
- Test and Enforce: Test the policy to ensure it behaves as expected and then enforce it across the desired scope.
Scenario
Example of a Deny Policy
{
"displayName": "Deletion of instance is not allowed",
"rules": [
{
"denyRules": [
{
"deniedPrincipals": [
"user:example-user@example.com"
],
"deniedPermissions": [
"compute.instances.delete"
],
"denialCondition": {
"title": "Prevent deletion during working hours",
"expression": "!(request.time.getHours() >= 9 && request.time.getHours() <= 17)"
}
}
]
}
]
}In this example, the policy denies the user example-user@example.com the permission to delete Compute Engine instances during working hours (9 AM to 5 PM).
Attachment Points
While creating the Deny policy, we need to provide the attachment point. There are three options for the attachment points like -
Organization: cloudresourcemanager.googleapis.com/organizations/ORG_ID
Folders: cloudresourcemanager.googleapis.com/folders/FOLDER_ID
Projects: cloudresourcemanager.googleapis.com/projects/PROJECT_ID
Create Deny Policy
gcloud iam policies create POLICY_ID \
--attachment-point=ATTACHMENT_POINT \
--kind=denypolicies \
--policy-file=POLICY_FILEPolicy ID → Give an id.
Attachment Point → Give the attachment point that you want to link this policy.
Policy File → Your JSON file.
List All Deny Policies
gcloud iam policies list \
--attachment-point=ATTACHMENT_POINT \
--kind=denypolicies \
--format=jsonView/Update Deny Policy
gcloud iam policies get POLICY_ID \
--attachment-point=ATTACHMENT_POINT \
--kind=denypolicies \
--format=jsonDelete Deny Policy
gcloud iam policies delete POLICY_ID \
--attachment-point=attachment-point
--kind=denypoliciesBest Practices
- Least Privilege Principle: Combine deny policies with allow policies to enforce the principle of least privilege, ensuring users have only the permissions necessary for their roles.
- Policy Review and Audit: Regularly review and audit deny policies to ensure they remain effective and relevant as organizational needs and security threats evolve.
- Documentation: Keep comprehensive documentation of all deny policies and the rationale behind them to aid in troubleshooting and compliance audits.
Deny Policies in GCP IAM provide a robust mechanism to enforce security and compliance requirements by explicitly restricting certain actions, complementing the traditional permission-granting model.
Disclaimer
This article is not endorsed by Salesforce, Google, or any other company in any way. I shared my knowledge on this topic in this blog post. Please always refer to Official Documentation for the latest information.
0 Comments