Organization Policy Service

Introduction to Organization Policy Service

For a Professional Cloud Security Engineer (PSE), the Organization Policy Service is the ultimate tool for centralized governance. While IAM defines who can do what, Organization Policies define what can be done with specific resources. It provides "guardrails" that prevent developers and administrators from making insecure configurations, regardless of their IAM permissions.

In an enterprise environment, managing security project-by-project is impossible. The Organization Policy Service allows you to enforce security standards at the Organization or Folder level, ensuring that every project under that node inherits the same security posture.

白話文解釋（Plain English Explanation）

1. The Building Code (Org Policy) vs. The Key Holder (IAM)

IAM is like giving someone a key to a room (Project). They have the permission to enter. However, the Building Code (Org Policy) dictates that the room must have a fire extinguisher and cannot have open wiring. Even if the key holder wants to remove the fire extinguisher, the Building Code prevents them from doing so.

2. The Parental Controls (Inheritance)

Imagine a parent setting rules for their house (Organization). One rule is "No TV after 9 PM." This rule automatically applies to all children's rooms (Folders) and their individual desks (Projects). If the parent wants to allow one child to study late, they can create an Exception (Override) for that specific room, or "Reset to Parent" to bring them back in line.

3. The Quality Control Scanner (Dry-run Mode)

Think of a factory line. Before you implement a new rule that might stop the whole line, you run a "Scanner" (Dry-run) that flags which items would have been rejected without actually stopping the conveyor belt. This allows you to fix issues before they cause downtime.

Managing Security Constraints at Org/Folder Levels

The Organization Policy Service works through Constraints. A constraint is a blueprint for a security rule.

Boolean vs. List Constraints

• Boolean Constraints: These are "On/Off" switches. (e.g., constraints/compute.disableSerialPortAccess). It's either enforced or not.
• List Constraints: These allow or deny a list of values. (e.g., constraints/compute.trustedImageProjects). You can specify which projects are allowed to provide disk images.

Essential Security Constraints for PSE

A PSE should be familiar with these "must-have" constraints:

1. Disable Serial Port Access: (constraints/compute.disableSerialPortAccess) Prevents interactive access to VM serial consoles, which bypasses SSH/IAM controls.
2. Restrict Public IP Creation: (constraints/compute.vmExternalIpAccess) Prevents VMs from having external IP addresses, forcing the use of Cloud NAT or IAP.
3. Enforce Shielded VM: (constraints/compute.requireShieldedVm) Ensures all new VMs have Secure Boot and vTPM enabled.
4. Resource Location Restriction: (constraints/gcp.resourceLocations) Restricts where resources (like GCS buckets or GKE clusters) can be created, critical for data sovereignty (GDPR/CCPA).

Custom Organization Policies

Google provides hundreds of "Predefined Constraints," but sometimes you need more granularity. Custom Organization Policies allow you to write your own rules using Common Expression Language (CEL).

Why use Custom Constraints?

• Granular Control: Instead of "No external IPs," you might say "No external IPs for VMs with the 'production' tag."
• Niche Requirements: Enforce specific configurations not covered by predefined constraints (e.g., specific bucket encryption types).

Dry-run Mode for Org Policies

Changing an Org Policy in a production environment can be dangerous. It might suddenly break existing deployment scripts or auto-scaling groups.

Dry-run mode allows you to:

1. Apply a policy in "Audit Only" mode.
2. Observe violations in the Logs (Cloud Logging).
3. Verify the impact before moving to "Enforced" mode.

Policy Inheritance and "Reset to Parent"

Understanding how policies flow down the hierarchy is a common PSE exam topic.

• Inheritance: By default, children inherit parent policies.
• Override: A Project can set its own policy that replaces the parent's policy.
• Merge (List Constraints): You can choose to append your list to the parent's list or replace it entirely.
• Reset to Parent: If a Project has an override that is no longer needed, you can "Reset" it to inherit the parent's policy again.

Enforcing Shielded VM and Resource Location

Shielded VM Enforcement

For high-security environments, you must ensure that no "naked" VMs are created. The constraints/compute.requireShieldedVm constraint ensures that every VM has a root of trust, preventing boot-level malware.

Resource Location Restriction

The constraints/gcp.resourceLocations list constraint is vital for compliance.

• Allowed: groups/us-locations
• Result: Any attempt to create a resource in europe-west1 will be denied with a 403 Forbidden error.

Auditing Org Policy Violations

How do you know if a policy is being bypassed (if allowed) or where violations are occurring?

• Cloud Logging: Every time an Org Policy blocks an action, it generates an AuditLog entry.
• Security Command Center (SCC): SCC provides a dedicated "Compliance" dashboard that highlights Org Policy violations across the entire organization.
• Inventory Search: Use Cloud Asset Inventory to find existing resources that violate a newly created policy.

Tags and Conditional Org Policies

You can use Tags to apply Organization Policies conditionally.

• Scenario: You want to restrict external IPs for all projects except those tagged as environment: sandbox.
• Implementation: Create an Org Policy with a condition: resource.matchTag('123/environment', 'sandbox').

CLI Commands for Org Policy

Describing a Policy

gcloud resource-manager org-policies describe \
    constraints/compute.disableSerialPortAccess \
    --organization=123456789

Setting a Boolean Policy

gcloud resource-manager org-policies enable \
    constraints/compute.disableSerialPortAccess \
    --project=my-security-project

Creating a Custom Constraint (YAML)

name: organizations/123/customConstraints/custom.disableExternalIP
resourceTypes:
- compute.googleapis.com/Instance
methodTypes:
- CREATE
condition: "resource.networkInterfaces.exists(ni, ni.accessConfigs.exists(ac, true))"
actionType: DENY

Security Best Practices for PSE

1. Start at the Top: Apply broad security constraints at the Org level (e.g., disableSerialPortAccess).
2. Use Folders for Exceptions: Group projects that need similar exceptions into a Folder and apply the override there, rather than project-by-project.
3. Strictly Control orgpolicy.policyAdmin: This role is as powerful as a Super Admin in terms of infrastructure security.
4. Audit Regularly: Use SCC to monitor for "Shadow IT" attempting to bypass guardrails.

Troubleshooting Scenarios

Scenario: Developer cannot create a VM in 'us-central1'

Diagnosis: Check constraints/gcp.resourceLocations at the Org, Folder, and Project levels. The developer might be hitting a restriction. Fix: If the business case is valid, add us-central1 to the allowed list or move the project to a folder with a more relaxed policy.

Scenario: A Project override is not working

Diagnosis: Ensure the constraint allows overrides. Some policies are "Hard-coded" at the Org level with inheritFromParent: false. Fix: Check if the parent policy has "Is enforced" set to true and if the child policy is correctly structured as an "Override".

PSE Exam Scenarios

Scenario 1: Preventing Data Exfiltration

"An organization wants to ensure that no data is stored outside of the European Union due to GDPR. What is the most effective way to enforce this?" Answer: Apply the constraints/gcp.resourceLocations constraint at the Organization level, allowing only EU regions.

Scenario 2: Transitioning to Shielded VMs

"You want to enforce Shielded VMs, but you have 500 existing legacy VMs that are not Shielded. How do you proceed?" Answer: Use Dry-run mode for the constraints/compute.requireShieldedVm policy to identify all 500 VMs without breaking them, then migrate them before switching to "Enforced" mode.

Summary Checklist

• Differentiate between Boolean and List constraints.
• Explain how policy inheritance and overrides work.
• Identify key constraints for disabling external IPs and serial ports.
• Understand the role of Tags in conditional policies.
• Describe the purpose and workflow of Dry-run mode.