The Google Cloud Organization Policy Service provides centralized governance across the resource hierarchy by restricting how cloud resources are configured. While predefined constraints handle common security baselines, custom constraints allow security teams to define granular guardrails tailored to their specific standards. Administrators define these custom rules in YAML configuration files using the Common Expression Language (CEL) to inspect resource attributes during API calls. The constraint specifies the target resource type, restricts CREATE or UPDATE operations, and defines an ALLOW or DENY action based on how the CEL expression evaluates.
Managing custom constraints requires the Organization Policy Administrator role. Policies follow the resource hierarchy, flowing down from the organization node through folders to individual projects via inheritance. Administrators can override parent policies at child nodes or use Resource Manager tags to enforce policies conditionally, such as applying stricter settings to production environments. When building tag-based conditional policies, administrators must always include at least one unconditional rule for the policy configuration to save successfully.
Before enforcing a policy live, administrators should evaluate its potential impact using Policy Simulator and dry-run mode. Testing is critical because custom organization policies are preventive rather than retroactive; they block future non-compliant operations but do not modify or delete existing non-compliant infrastructure. Once verified, the administrator applies the policy across the hierarchy, and the enforcement takes up to 15 minutes to fully propagate.
Custom modules in Security Health Analytics (SHA) extend the built-in vulnerability detection capabilities of Security Command Center (SCC). These modules act as specialized detectors that continuously inspect Cloud Asset Inventory metadata for misconfigurations or compliance violations that standard rules might miss. When a resource definition matches the module's CEL condition, the detector triggers a security finding. Each module definition includes a assigned severity level, such as HIGH or MEDIUM, along with descriptive properties that explain the detected risk to security analysts.
Developing custom modules allows security teams to build nuanced detection logic that matches organizational policies. For example, a custom module can evaluate multiple resource properties simultaneously, use wildcards to match network subnets, or ignore virtual machines that are currently in a MAINTENANCE state. Creating and managing these detectors requires the roles/securitycentermanagement.shaCustomModulesEditor IAM role. Once deployed, custom modules automatically evaluate resources during both real-time configuration changes and scheduled daily batch scans, operating within standard organization-level quota limits.
Custom modules provide flexible detection, but they have distinct operational tradeoffs compared to built-in detectors. Findings generated by custom modules do not integrate into SCC attack path simulations, meaning they do not generate attack exposure scores or appear in visualized attack graphs. As a result, custom modules are best suited for monitoring organization-specific compliance rules and detecting unique configuration drift. Deploying them at the organization, folder, or project level ensures that specialized detection scales across the entire cloud footprint.
The security posture service in Security Command Center enables teams to define, monitor, and maintain standardized security baselines across Google Cloud environments. A posture combines both preventive controls, such as organization policies, and detective controls, such as SHA modules, into unified policy sets. Administrators deploy these postures across organizations, folders, or projects to establish a consistent security baseline that child resources inherit automatically. To catch misconfigurations before deployment, teams can also integrate preventive rules into CI/CD deployment pipelines using tools like Open Policy Agent (OPA) alongside Infrastructure-as-Code templates.
When unauthorized changes cause resources to drift from the defined baseline, an automated event-driven architecture can identify and correct the misconfiguration in real time. SCC and Cloud Asset Inventory publish configuration changes and finding notifications directly to Pub/Sub. Event-driven compute services, such as Cloud Functions or Cloud Run, subscribe to these Pub/Sub topics, parse the finding details, and trigger targeted API calls to revert the unauthorized changes. In addition to triggering immediate automated remediation, this pipeline can stream security findings to BigQuery or external security information and event management (SIEM) systems for long-term auditing and forensic analysis.
Professional Cloud Security Engineer
Prepare and test your skills
Prepare and test your skills
Custom organization policies are preventive rather than retroactive, meaning they block future non-compliant operations but do not modify or delete existing non-compliant infrastructure. Because of this behavior, administrators should evaluate a policy's potential impact using Policy Simulator and dry-run mode prior to enforcement. Once verified and applied, the policy takes up to 15 minutes to fully propagate across the resource hierarchy.
Findings generated by custom modules do not integrate into Security Command Center (SCC) attack path simulations, meaning they do not produce attack exposure scores or appear in visualized attack graphs. Consequently, custom modules are primarily suited for monitoring organization-specific compliance rules and detecting unique configuration drift rather than attack path modeling. They run within standard organization-level quotas and evaluate resources during both real-time configuration changes and daily batch scans.
Security Command Center and Cloud Asset Inventory publish configuration changes and finding notifications directly to Pub/Sub when resources drift from a defined baseline. Event-driven compute services, such as Cloud Functions or Cloud Run, subscribe to these Pub/Sub topics, parse the finding details, and issue targeted API calls to revert the unauthorized changes. The pipeline can also stream security findings to BigQuery or external security information and event management systems for long-term auditing.
Set the resource selector to compute.googleapis.com/Firewall, set the severity to CRITICAL, and define a CEL expression that evaluates to true when an enabled ingress rule includes 0.0.0.0/0 in sourceRanges and allows TCP port 22.
Create a custom Organization Policy boolean constraint using CEL on compute.googleapis.com/Firewall with enforcement set to audit to generate findings in Security Command Center.
Set the resource selector to compute.googleapis.com/Firewall, set the severity to CRITICAL, and define a CEL expression that evaluates to false when an ingress rule contains 0.0.0.0/0 and allows TCP port 22.
Set the resource selector to compute.googleapis.com/Instance, set the severity to CRITICAL, and define a CEL expression checking resource.data.tags.items.exists(tag, tag == 'allow-ssh').
A financial enterprise is implementing continuous configuration drift detection across its Google Cloud organization using Security Command Center. To mitigate risks highlighted in recent security bulletins concerning OpenSSH vulnerabilities, the security team needs to deploy a custom Security Health Analytics (SHA) detection module.
The module must evaluate all Compute Engine firewall rules across projects and automatically generate a CRITICAL finding whenever an active ingress rule allows unrestricted traffic from the public internet (0.0.0.0/0) to TCP port 22.
How should the custom SHA module and its Common Expression Language (CEL) expression be configured?