Hierarchical security policies are a category of security policies that extend the reach of Google Cloud Armor web application firewall (WAF) and DDoS protection beyond individual projects. They are attached at the organization, folder, or project level. These differ from service-level security policies, which are attached directly to backend services or backend buckets.
When you configure a hierarchical security policy at the organization or folder level, projects at lower levels of the hierarchy inherit that security policy. This inheritance lets you set up security policy rules that you want to apply to all or several projects within your organization. This allows for centralized and consistent security enforcement across your Google Cloud environment.
This page explains how hierarchical security policies differ from service-level security policies. Before you proceed, read the security policy overview to make sure that you understand how security policies work. In addition, we recommend that you familiarize yourself with the resource hierarchy.
Use cases
In large organizations, managing security policies across numerous projects can be complex and time consuming. Hierarchical security policies offer the following advantages to help you address these challenges:
- Centralized control: provide organization and folder-level administrators with the ability to define and enforce security policies across multiple projects.
- Consistency: provide uniform security posture across the organization, reducing the risk of misconfigurations and security gaps.
- Efficiency: streamline the deployment of security updates and mitigations, such as blocking specific IP address ranges or addressing critical vulnerabilities, across a large number of resources simultaneously.
- Delegation: enable delegation of security responsibilities to different teams or departments by applying policies at appropriate levels of the hierarchy.
You can apply and combine these general principles to fit your organization's needs. Consider the following example use cases:
- Organization-wide IP address blocking: you can block traffic from known malicious IP address ranges across all projects in your organization.
- Geography-based restrictions: you can restrict traffic from specific geographic regions at the organization or folder level.
- CVE mitigation: you can quickly deploy WAF rules to mitigate critical vulnerabilities across multiple projects.
- Compliance enforcement: you can enforce adherence to regulatory requirements by applying consistent security policies across your organization.
- Granular access control: you can grant specific IP address ranges or geographic regions access to all of the resources within a specific folder.
Features
Hierarchical security policies support a subset of the features that service-level security policies support. The following table compares the Google Cloud Armor features that you can use with hierarchical security policies and service-level security policies:
| Frontend type |
|
|
| Attachment point (protected resource) | Backend service | Resource hierarchy nodes |
| Rule actions |
|
|
| Source IP address | ||
| Source geography | ||
| Source ASN | ||
| Bot management | (only
EXTERNAL_302 and request decoration) |
|
| Layer 7 filtering | ||
| WAF | ||
| Google Threat Intelligence | ||
| reCAPTCHA | ||
| Adaptive Protection | ||
| Address Groups | ||
| Org-level Address Groups | ||
| Security Command Center | ||
| Cloud Monitoring | ||
| Request logging |
How hierarchical security policies work
When you create a hierarchical security policy, you create it at the organization or folder level, and that resource has ownership over the hierarchical security policy. After you create a hierarchical security policy, your security policy rules aren't applied to any of your resources.
Next, you associate the hierarchical security policy with an organization, folder, or project, which can be the same as the resource that owns the policy. After you have associated a hierarchical security policy with a resource, it applies the security policy rules to the protected resources at and under that node in the resource hierarchy. To help you decide which resource to attach your hierarchical security policies to, see the following list of basic use cases for each resource:
- Organization: consider organization-level
hierarchical security policies as the default type of hierarchical security policy.
These policies have broad Identity and Access Management (IAM)
permissions, and they apply to all nodes under the organization. Specify
these resources by using the
--organizationflag during association. - Folder: use these hierarchical security policies when you want to apply the
same security policy rules across multiple projects but not across your
entire organization. Specify these resources by using the
--folderflag during association. - Project: use this type of hierarchical security policy when you need
to apply the same security policy rules across all resources in a
project, like applying an IP address denylist across several backend services.
Specify these resources by using the
--projectflag during association. - Service-level: use service-level security policies when you need unique
security policy rules that differ among each of your services. Each
service-level security policy only applies its rules to the backend policy
that it's attached to. Specify these resources by using the
--project-numberflag.
You can only use one of these flags per hierarchical security policy. You
specify the rest of the flags, like --name or --type, just like you do when
you configure a service-level security policy. See the following list for more
information about how hierarchical security policies work:
- When a hierarchical security policy is associated with a resource hierarchy node, all protected resources lower than that node in the hierarchy inherit the policy.
- You can view the security policies that apply to each protected resource in a project, across all hierarchical security policies and service-level security policies. For more information, see View all effective Google Cloud Armor rules for a protected resource.
- You can move hierarchical security policies from one resource hierarchy node to another. You might do this when you plan to reorganize your folder structure.
- When you delete a resource hierarchy node, like a folder or a project, the
hierarchical security policy attached to that node is only deleted if you
created it under that resource hierarchy node.
- If you created the security policy elsewhere and then moved it under the node, it isn't deleted.
- To avoid accidental deletion of your hierarchical security policies, we recommend that you move any hierarchical security policies that you intend to keep to another resource hierarchy node before you delete the existing node.
Rule evaluation order
Google Cloud Armor evaluates security policies in the following order:
- Organization-level hierarchical security policies
- Folder-level hierarchical security policies (beginning with the parent folder, then proceeding to each subfolder)
- Project-level hierarchical security policies
- Service-level security policies
This rule evaluation order means that you might have a hierarchical security policy with a low priority that is evaluated before a service-level security policy with a high priority. Think carefully about your existing high-priority service-level security policy rules, and consider what happens if Google Cloud Armor doesn't evaluate a request that is allowed or denied by a hierarchical security policy against them.
The goto_next action
Google Cloud Armor has a rule action that is exclusive to
hierarchical security policies: the goto_next action. When Google Cloud Armor applies
this action, it stops evaluating rules within the current security policy and
begins evaluating rules in the next security policy.
Consider an example in which you have a
hierarchical security policy at the organization-level with many rules that you
want to use to restrict requests across your entire organization. You want to
let requests that come from a certain IP address range skip evaluating these
organization-wide rules. Therefore, you create a top-priority rule that matches
on that IP address range with the action goto_next. The requests from that IP
address range are evaluated against this rule first, and because they meet the
match condition, they aren't evaluated against any other rules in this
organization-level hierarchical security policy.
In the same example, if you used an allow or deny action instead of the
goto_next action, the request is allowed or denied as soon as the match
condition is met. This hierarchical evaluation means that no additional security
policies are evaluated against that request.
Google Cloud Armor Enterprise enrollment and billing behavior
When you attach a hierarchical security policy, each of the projects that inherit the hierarchical security policy must be enrolled in Cloud Armor Enterprise. This includes all of the projects in an organization or folder with a hierarchical security policy that aren't explicitly excluded, and all projects with a hierarchical security policy attached directly to the project.
- Projects that are linked to a Cloud Billing account with a subscription to Cloud Armor Enterprise Annual are automatically enrolled in Cloud Armor Enterprise Annual if they aren't already enrolled.
- Without a Cloud Armor Enterprise Annual subscription, projects are automatically enrolled in Cloud Armor Enterprise Paygo when they inherit a hierarchical security policy. If you subscribe the billing account to Cloud Armor Enterprise Annual after your project was automatically enrolled in Cloud Armor Enterprise Paygo, the project isn't automatically enrolled to Annual. For more information about Cloud Armor Enterprise Paygo, see Google Cloud Armor Standard versus Cloud Armor Enterprise.
- If you update a hierarchical security policy to exclude a project after the project has been automatically enrolled in Cloud Armor Enterprise, the project isn't automatically unenrolled. To manually unenroll your project, see Remove a project from Cloud Armor Enterprise.
- You can't remove a project from Cloud Armor Enterprise while it has any inherited hierarchical security policies.
Limitations
Hierarchical security policies have the following limitations:
- Hierarchical security policies aren't available for projects that aren't within an organization.
- For new or recently restored projects, it might take a few hours for any inherited security policies on the project to propagate.
- For a project that has recently enabled the Compute Engine API, it might take a few hours for any inherited security policies on this project to propagate.
- You can tune preconfigured WAF rules in hierarchical security policies that you own, but the owners of services that inherit a hierarchical security policy can't perform rule tuning.