Custom Policies and Posture Drift Detection

Authoring and enforcing custom organization policy constraints is the preventive way to block misconfigured Google Cloud resources before they are created. Google Cloud Organization Policy Service (opens in a new tab) is the centralized control plane that evaluates constraints when resources are created or updated. Custom constraints extend built-in controls with field-level rules so teams prevent drift instead of detecting it afterward.

1.1Custom Constraints and Managed Constraints

Custom constraints are user-defined rules that govern specific fields of supported Google Cloud resources, while managed constraints are predefined rules supplied by Google. A managed constraint such as constraints/storage.publicAccessPrevention, constraints/iam.allowedPolicyMemberDomains, or constraints/compute.skipDefaultNetworkCreation enforces one fixed behavior across the hierarchy. A custom constraint targets a service-specific resource type, such as compute.googleapis.com/BackendService, certificatemanager.googleapis.com/Certificate, or clouddeploy.googleapis.com/DeliveryPipeline, and uses a Common Expression Language (CEL) expression to allow or deny the request based on values in the creation payload.

The request flows from the user or automation to the service API and then to the policy engine for an allow or deny decision. Choose a managed constraint when a predefined control covers the requirement, and choose a custom constraint when governance needs field-level precision such as approved VM machine families, disk size limits, allowed health-check protocols, or required firewall tag configurations. The following comparison summarizes when to use each option:

Custom constraints depend on the supporting service exposing its resource fields to Organization Policy, so not every field is governable. Legacy global HTTP and HTTPS health checks, for example, are not supported for custom constraints.

1.2Hierarchical Inheritance and Enforcement Scope

Hierarchical inheritance is the rule that determines where an organization policy applies in the Google Cloud resource hierarchy. The hierarchy flows from organization to folder to project to service resource, and the effective policy at a project is the combination of policies inherited from its ancestors plus any policy attached directly to the project. By default, descendants inherit the parent policy, and evaluation rules can alter that behavior for an exception subtree.

The organization policy administrator owns constraints and policies at the level where they are attached, while project owners inherit those guardrails without the ability to weaken a higher-level deny. Place broad preventive baselines high in the hierarchy for consistent posture, and place narrower custom constraints lower when only one folder or project needs the restriction.

1.3Conditional Tag-Based Enforcement

Conditional tag-based enforcement is the mechanism for scoping an organization policy to a subset of resources using tags and conditions rather than moving resources in the hierarchy. The policy still attaches at the organization, folder, or project level, but its rule includes a condition that checks tags bound to the target resource or its ancestry. Creation traffic flows to the policy engine, the engine resolves the tags on the resource, and only requests matching the tag condition are subject to the deny or allow logic.

This model separates placement from intent, so one folder can host both restricted and exempt workloads distinguished by tags such as environment:prod or data-classification:restricted. Use tag conditions when a single control must apply selectively without creating extra folders, and use separate hierarchy attachments when the boundary should follow team or billing ownership. Because the policy depends on correct tag bindings, tag administration and tag inheritance must be governed as tightly as the constraint itself.

1.4Author, Simulate, and Enforce Workflow

The author-to-enforcement workflow is the ordered lifecycle for rolling out a custom constraint safely at scale. The constraint definition, the policy attachment, and the enforcement mode are separate objects, which allows simulation before blocking production changes. The ordered rollout operates as follows:

1. Define the custom constraint: Create the constraint in the organization resource, specifying the target service resource, the governed fields, and the CEL condition that returns true for a violation.
2. Attach the organization policy: Bind the custom constraint to an organization, folder, or project node, configuring inheritance behavior and any tag-based conditions for scope or exemption.
3. Simulate impact in dry-run mode: Deploy the policy in dry-run first so the policy engine logs what would have been denied without blocking the request, then review logs to identify existing workloads that would drift.
4. Enforce and validate: Switch the policy from dry-run to enforced mode, attempt compliant and noncompliant operations, and confirm that compliant requests succeed while violating requests are denied with a constraint violation.

Dry-run simulation depends on representative traffic and existing inventory, so run it long enough to observe automation, CI/CD pipelines, and manual workflows. Only after dry-run shows no unintended denials should enforcement be enabled on production folders.

1.5Common Preventive Patterns at Scale

Common preventive patterns use custom and managed constraints together to maintain baseline posture and stop drift across many projects. The Organization Policy Service evaluates these controls at request time, which prevents the misconfigured resource from existing rather than flagging it after creation. Representative patterns drawn from supported services include:

• Restrict Compute Engine VM creation to approved machine families and limit persistent disk provisioning sizes to control cost and attack surface.
• Mandate specific network firewall tag configurations and require forwarding rules to use approved Network Service Tiers.
• Require backend buckets to have Cloud CDN enabled and disallow certain backend traffic protocols or health-check probe configurations.
• Enforce constraints/iam.disableServiceAccountKeyCreation and constraints/iam.automaticIamGrantsForDefaultServiceAccounts to block long-lived keys and automatic Editor grants to default service accounts.
• Enforce constraints/compute.skipDefaultNetworkCreation and constraints/compute.trustedImageProjects so new projects do not receive a default network and VMs launch only from trusted image projects.

Automated drift detection and posture remediation is the continuous comparison of live Google Cloud configuration against an Infrastructure-as-Code baseline, with programmatic correction when they diverge. Security Command Center (SCC) (opens in a new tab) posture service defines the baseline as a posture, detects drift as findings, and exports those findings for action. Cloud Asset Inventory feeds, Pub/Sub, and event-driven compute such as Cloud Functions or Cloud Run close the loop by carrying change events to custom logic that creates findings and executes remediation.

2.1Security Posture as the Enforceable Baseline

A security posture in Security Command Center is one or more policy sets that enforce the preventive and detective controls required to meet a security standard. A policy set groups the policies for one standard or regulation, a policy is a single constraint or detector, and a posture deployment applies the posture to an organization, folder, or project. Supported policies in a posture are Organization Policy Service constraints, including custom constraints, for prevention and Security Health Analytics detectors, including custom modules, for detection.

The posture service is automatically enabled when Security Command Center is activated at the organization level on the Premium tier. This activation creates the management plane where baselines are defined once and then deployed to many hierarchy nodes for consistent enforcement.

2.2Preventive Controls That Define the Known Good State

Preventive controls in Organization Policy Service set centralized restrictions on how resources can be configured across the resource hierarchy. Declarative Infrastructure-as-Code provides the known good state, so the same Terraform and Cloud Build configuration can be redeployed, rolled back, audited, and checked automatically before deployment. Policy as code extends that check into the CI/CD pipeline, where Policy Controller and Open Policy Agent validate IaC for acceptable configuration before it is applied.

The preventive toolkit divides responsibility across four peer capabilities:

• Organization Policy Service constraints: configure predefined and custom constraints with centralized control, such as limiting domain sharing, limiting service account use, and restricting physical locations of new resources.
• VPC Service Controls: create service perimeters around Google Cloud services and enforce strict egress controls to limit data exfiltration as defense in depth.
• Identity and Access Management (IAM), Privileged Access Manager, and principal access boundary policies: authorize who can act on specific resources, with tags and IAM Conditions providing attribute-based access without per-resource rules.
• Policy Controller and Open Policy Agent (OPA): enforce IaC constraints in the pipeline and block cloud misconfigurations before deployment.

Traffic from developers flows first through OPA and Policy Controller checks, then through Organization Policy Service enforcement at deploy time, then through IAM and VPC Service Controls enforcement at access time.

2.3Detective Controls That Surface Drift From the Baseline

Detective controls in Security Health Analytics continuously scan running Google Cloud assets for vulnerabilities, misconfigurations, and leaked secrets without requiring OS agents. Security Command Center aggregates signals from multiple security sources, runs attack path simulations that show how minor issues chain from the internet to high-value compute or billing permissions, and monitors active workloads with Container Threat Detection and Cloud Run Threat Detection. Compliance Manager frameworks map those findings to obligations and alert on posture drift from the defined benchmark.

The baseline controls library is designed to be extended as requirements mature:

• Security Health Analytics: define custom modules for Security Health Analytics and custom modules for Event Threat Detection to add organization-specific detectors.
• Organization Policy Service: enforce additional premade constraints or create custom constraints for new governance requirements.
• Open Policy Agent: develop additional constraints from the shared policy library to validate foundation pipeline code.
• Logging and asset telemetry: design additional log-based metrics, alerting policies, and Security Command Center findings queries for events that should not occur.

2.4Real-Time Drift Detection and Automated Remediation Flow

Real-time drift remediation connects Cloud Asset Inventory, Security Command Center, Pub/Sub, and Cloud Run functions into an event-driven loop that compares live state to the IaC baseline. After a posture is deployed, Security Command Center reports drift as findings that can be reviewed, filtered, resolved, and exported like any other finding. A custom asset-change solution creates Security Command Center findings from inventory changes and can trigger automated remediation, while log-based alerts notify on errors from the Security Command Center service agent.

The ordered remediation loop operates as follows:

1. Posture deployment establishes the baseline: the posture applies Organization Policy constraints and Security Health Analytics detectors to the target organization, folder, or project.
2. Change telemetry enters the pipeline: Cloud Asset Inventory feeds emit asset change events for monitored asset types, and Security Health Analytics emits drift findings when live configuration violates the posture.
3. Events flow through Pub/Sub to automation: findings and feed messages flow from Security Command Center and Cloud Asset Inventory to Pub/Sub subscriptions that invoke Cloud Functions or Cloud Run functions.
4. Custom logic decides and remediates: the Cloud Run function evaluates the event against the IaC baseline, executes programmatic remediation such as reverting configuration or re-applying Terraform, and writes a new Security Command Center finding for audit.
5. Posture monitoring verifies return to baseline: Security Command Center rescans the resource, clears the drift finding when the resource matches the posture again, and Compliance Manager confirms the framework returns to compliant status.

The automation depends on least-privilege service identities, so the remediation function depends on IAM permissions that allow it to read findings and inventory while limiting its power to modify only the intended resource types.

2.5Deploying Postures at Scale With Predictable Inheritance

Posture deployment at scale relies on hierarchy inheritance where postures deployed at higher levels flow down to child folders and projects. If postures exist at both the organization level and the project level, all policies in both postures apply to resources in that project, and only direct conflicts are resolved in favor of the lower-level posture. The recommended pattern deploys a broad posture at the organization level for business-wide controls, then deploys more stringent postures to folders or projects that need them.

A common example enforces constraints/gcp.restrictCmekCryptoKeyProjects on common and environment folders so projects use keys only from designated key projects. Scale is bounded by explicit service limits that shape how postures are partitioned: the security posture service allows a maximum of 100 postures in an organization, a maximum of 400 policies in a posture, and a maximum of 1000 posture deployments in an organization. Predefined templates for secure defaults, BigQuery, Cloud Storage, VPC, CIS Benchmark v2.0.0, NIST SP 800-53, ISO 27001, PCI DSS, and secure AI reduce design work because essentials templates deploy without changes while extended templates must be customized to the environment.

Building and deploying custom modules for Security Health Analytics extends detection beyond built-in detectors to organization-specific misconfigurations. Security Health Analytics (SHA) (opens in a new tab) custom modules are custom detectors that continuously evaluate Cloud Asset Inventory metadata to generate findings at scale. Custom modules run in Security Command Center Premium and Enterprise tiers and let teams encode internal baselines that standard benchmarks miss.

3.1Purpose and Scope of Custom Modules

Custom modules expand SHA posture management to business-specific drift that standard benchmarks miss. A custom module applies only to Google Cloud resources and is not supported for other cloud platforms such as Amazon Web Services or Microsoft Azure. Built-in detectors cover Google Cloud plus, in Enterprise, AWS and Azure after onboarding, but custom logic evaluates only Google Cloud asset data.

This boundary makes custom modules the tool for enforcing internal baselines across an organization, folder, or project hierarchy in Google Cloud. Built-in findings are grouped into high-level resource categories that illustrate the breadth of SHA coverage:

• IAM, multi-factor authentication, and API key findings
• Compute instance, compute image, container, and dataset findings
• Firewall, network, subnetwork, DNS, and organization policy findings
• Storage, SQL, Pub/Sub, KMS, logging, and monitoring findings

Custom modules complement these categories rather than replace them, pinpointing misconfigurations on supported Google Cloud resources where no built-in detector exists.

3.2Detection Logic With CEL and Cloud Asset Inventory

Detection logic with CEL and Cloud Asset Inventory is a Common Expression Language expression that tests normalized asset metadata for a violation. Cloud Asset Inventory supplies a normalized snapshot of each supported resource and its configuration, and SHA loads that asset data as input to the expression. The CEL expression tests fields such as network settings, encryption state, labels, or IAM bindings and returns true only when the resource violates the intended state.

This design creates a continuous drift-detection loop where data flows from the Google Cloud resource to Cloud Asset Inventory and then to the SHA evaluation engine. When the expression matches, SHA creates a finding bound to that specific asset; when it does not match, no finding is produced. Because evaluation depends on Cloud Asset Inventory coverage, a custom module can only pinpoint misconfigurations on resource types that Cloud Asset Inventory supports.

3.3Finding Definition: Severity, Category, and Target

Finding definition is the set of properties that determines how a custom module finding is triaged and scoped. The definition names a finding category, such as DEFAULT_NETWORK or DEFAULT_ENCRYPTION_NOT_VERIFIED, assigns a severity level such as MEDIUM, and carries a revision number that tracks logic changes over time. The definition also declares an enforcement mode, such as Detective or Audit, and lists supported target resources, which include organization, folder, and project.

The finding inherits the severity and category from its parent module, so all assets that violate the same CEL rule share the same triage priority. Severity controls operational response, while category determines how the finding groups with related posture issues in Security Command Center. Defining these properties up front ensures that continuous evaluation produces findings that are actionable, scoped to the correct hierarchy level, and comparable across environments.

3.4Build and Deployment Workflow

The build and deployment workflow creates a module definition owned at an organization, folder, or project that SHA then schedules for continuous scanning. A custom module can be built through the guided workflow in the Google Cloud console or as code for automation at scale. The console path suits one-off rules, while the as-code path supports version control, review, and rollout across many folders and projects.

Deployment as code follows an ordered workflow:

1. Author the definition: Create the YAML file with the CEL expression, target asset types, severity, finding category, and enablement scope.
2. Upload to Security Command Center: Import the YAML using Google Cloud CLI commands or the Security Command Center API to the parent organization, folder, or project.
3. Enable and validate: Enable the module at its parent scope so evaluation flows from Cloud Asset Inventory to Security Health Analytics, then verify that test-compliant resources stay clean and test-violating resources generate the expected finding.

Once enabled, the module depends on Cloud Asset Inventory freshness and SHA scheduling to detect drift. Changes to infrastructure that alter asset metadata re-trigger evaluation, and remediation that makes the CEL expression evaluate to false allows the finding to move to inactive.

Key Facts

• Custom organization policy constraints use Common Expression Language (CEL) to govern specific resource fields, while managed constraints enforce fixed predefined behaviors.
• Organization policy inheritance flows from organization to folder to project, and dry-run mode logs what would be denied before enforcement blocks requests.
• A Security Command Center posture combines Organization Policy constraints for prevention with Security Health Analytics detectors for detection, with limits of 100 postures per organization, 400 policies per posture, and 1000 deployments per organization.
• Real-time drift remediation flows from Cloud Asset Inventory and Security Command Center findings through Pub/Sub to Cloud Functions or Cloud Run for programmatic remediation.
• Security Health Analytics custom modules require Premium or Enterprise tiers, evaluate only Google Cloud asset metadata from Cloud Asset Inventory, and generate findings that move to inactive when remediated.