Maintaining a robust security posture is paramount when using Cloud, while Aviato deploy org policies by default as part of our Cloud Foundations it is good to understand how they can be used to improve meet your compliance needs, and maintain a high level of security.
Org Policies control what can be done with resources, IAM controls which define who can access a resource. Together these 2 things lock down your Google Cloud secruity.
What Are Google Cloud Organization Policies?
Organization Policies are a set of constraints that you can apply across your entire GCP organization, folders, or projects. They enable you to:
- Enforce Security Best Practices: Restrict public access to resources such as Cloud Storage Buckets, or ensure your cloud resources are only in allowed specified regions (
australia-southeast1for example) - Maintain Compliance: Ensure adherence to industry regulations like HIPAA, PCI DSS, and GDPR for those with a presense in the US or EU
- Streamline Governance: Centralize control over resource configurations and reduce the risk of misconfigurations.
Why Organization Policies Matter for Your Security:
Org policies let your engineers and developers deploy new services but maintain a compliant and secure environment by ensuring:
- Consistent Security Controls: Apply standardized policies across your entire cloud environment, minimizing the risk of oversights.
- Proactive Risk Mitigation: Prevent unauthorized actions or configurations that could compromise your data.
- Improved Compliance: Demonstrate adherence to regulatory requirements through auditable policy enforcement.
- Simplified Management: Manage policies at a high level, reducing the need for manual interventions on individual resources.
Key Organization Policy Use Cases:
The full list of Org Policies is avaiable on the Google Cloud site but a few examples are:
- Domain Restricted Sharing: Limit sharing of cloud resources only to users with an @aviato.consulting user account for example
- Restricting Public Access: Prevent public exposure of Cloud Storage buckets
- Soft Delete: Ensuring items deleted from a Cloud Storage Bucket are retained for a period of time
- Managing Service Accounts: Restrict the creation or modification of service account keys
- Limiting Resource Locations: Ensure resources are deployed only in approved regions or zones (australia-southeast1 for example)
- Allowing Ingress Options: Ensure that only traffic inside your VPC can access your resources
From early 2024, any new users will find certain policies already enforced. Examples include:
- iam.disableServiceAccountKeyCreation (blocking long-lived service account keys)
- storage.uniformBucketLevelAccess (forcing uniform access on buckets)
- iam.automaticIamGrantsForDefaultServiceAccounts (preventing default service accounts from automatically getting the powerful Editor role).
Implementing Organization Policies: Step-by-Step Guide
- Identify Your Objectives: Determine the security and compliance goals you need
- Map Policies to Objectives: Choose the relevant policies from the extensive list provided by Google Cloud.
- Define Policy Values: Specify the allowed or restricted configurations for each policy.
- Apply Policies
- Hierarchically: Apply policies at the organization level, with exceptions only where needed. For example public storage buckets might be needed for the project hosting your external web site.
- With Tags: You can apply tags to projects and ensure policies only apply to some resources with that tage (e.g. environment=production)
- Monitor and Adjust:
- Dry-Run Mode. Admins can deploy an Org Policy in dry-run mode where it simply logs violations to Cloud Logging without actually blocking the developer’s action, great to “try before you buy” (these are free don’t worry)
- Regularly review: Periodically review and update your policies to align with evolving security requirements.
Custom Org Policies:
With Custom Constraints. Administrators can now use Common Expression Language (CEL) to create highly granular, bespoke rules tailored to their exact business needs.
A few examples of these are as follows:
| Name | Example | Resource | CEL Conditions |
| Restricting Compute Engine Machine Types | In a dev environment only small sized VM’s can be created | compute.googleapis.com/Instance | resource.machineType.contains(‘e2-micro’) |
| Enforcing Naming Conventions for Cloud Storage | You want to ensure that all Cloud Storage buckets created in a production folder begin with the prefix prod-corp- | storage.googleapis.com/Bucket | resource.name.startsWith(‘prod-corp-‘) |
| Enforcing Labels on Creation | Ensure every new Compute Engine disk has a cost-center label attached to it at the time of creation. | compute.googleapis.com/Disk | has(resource.labels[‘cost-center’]) |
Best Practices for Organization Policies:
- Start with Essential Policies: Prioritize policies that address critical security risks, such as public access and encryption.
- Test in a Sandbox Environment: Experiment with policies in a non-production environment and roll them out with Infrastructure as Code
- Document Your Policies: Maintain clear documentation of your policy choices and rationale.
- Leverage Policy Inheritance: Utilize the hierarchical nature of policies to streamline management.
In summary Google Cloud Organization Policies empower you to elevate your cloud security posture through proactive, centralized controls. If you are worried about your Google Cloud security Aviato offer Google Cloud Security Assesments and can help with the implementation of Org Policies.
