Skip to content

Latest commit

 

History

History
172 lines (145 loc) · 67.5 KB

README.md

File metadata and controls

172 lines (145 loc) · 67.5 KB

terraform-google-cloud-policies

A Terraform module to deploy GCP resource policies at project, folder and organization levels.

Prerequisites

  • Terraform. Tested with v1.5.2
  • A GCP resource (organization, folder or project) and an authenticated gcloud CLI

Permissions

Unfortunately, you will need the roles/orgpolicy.policyAdmin role at organization level, even though the policies are applied at the folder or project level.

Usage

Go to the examples directory to view code samples.

Architecture

Here is a quick overview of what this module will provision :

https://cloud.google.com/resource-manager/docs/organization-policy/overview

Explanations for each policy

Policy Permission Why ?
Define Access Mode for AI Notebooks Allow all Multiple users should be able to collaborate on AI Notebooks with the "service-account" mode and there are no reasons to forbid the "single-user" mode
Disable Root Access on New AI Notebooks Instances TRUE This action helps prevent data scientists from altering controls installed in the notebook instance, such as approved packages or logging.
Restrict Environment Options on New AI Notebooks Instances Allow all Restricting VM types and container images a data scientist can use will slow him down. Denying some VM types and container images which contain security risks would be preferable
Require Automatic Scheduled Upgrades on New AI Notebooks Instances TRUE To reduce exploits, we want data scientists to have automated upgrades setup for their notebooks and instances
Restrict Public IP access on Creating Notebooks instances and runtimes TRUE AI Notebooks instances and runtimes have public IPs assigned by default which can increase your attack surface and expose sensitive data. Data scientists must setup IAP to access AI notebooks : more details here
Disable Source Code Download TRUE App Engine should be accessible only from source code repositories (GitHub, Gitlab, ...) and code downloads should be monitored from these platforms only for better governance.
Enforce iam.serviceAccounts.actAs checks for service accounts that interact with AppEngine instances FALSE Enforcing this policy could force project admins to grant the permission "iam.serviceAccounts.actAs" to a lot of GCP users without specifying only the AppEngine service account on projects where other service accounts may have even more priviledges, thus allowing these users to perform privilege escalation...
Disable BigQuery Omni for Cloud AWS FALSE Except for governance and finops considerations, there is no reason to disable BigQuery Omni for Cloud AWS
Disable BigQuery Omni for Cloud Azure FALSE Except for governance and finops considerations, there is no reason to disable BigQuery Omni for Cloud Azure
Allowed Integrations (Cloud Build) Allow ["github.com"] Artefact mainly uses GitHub to host source code so we don't want users to run CI/CD pipelines on Cloud Build from other source repositories
Allowed Worker Pools (Cloud Build) Allow ["under:PARENT_ID"] If users configure worker pools for Cloud Build, they should not use worker pools outside the parent GCP resource where this policy is applied
Disable Cloud Deploy service labels FALSE Attaching automated labels from Cloud Deploy is a feature we most probably want to simplify the deployments processes
Allowed ingress settings (Cloud Functions) Allow ["ALLOW_INTERNAL_ONLY", "ALLOW_INTERNAL_AND_GCLB"] To trigger Cloud Functions securely, we want to be able to trigger them from GCP resources ou users within our internal network or from GCP users that go through a load balancer secured by IAP if possible : more details here
Allowed VPC Connector egress settings (Cloud Functions) Allow all Enforcing all egress traffic from any cloud function to go through a VPC connector may enhance security controls and audit capabilities but requires too much networking knowledge compared to its security worth
Require VPC Connector (Cloud Functions) FALSE Users who don't know how to use the VPC connector for Cloud Functions must still be able to use the service even if the VPC connector enables better network security (such as not using the Public Internet to send or receive requests between Cloud Functions and VPCs)
Allowed Cloud Functions Generations Allow ["2ndGen"] In order to reduce technical debt, only 2nd generation cloud functions are allowed
Restrict which KMS CryptoKey types may be created. Allow ["SOFTWARE", "HSM"] In order to simplify key management systems, no external key managers are allowed
Allowed target types for jobs Allow ["APPENGINE", "HTTP", "PUBSUB"] No reasons to deny a specific target could be found
Disable Public Marketplace TRUE Security admins should be able to whitelist which services can be used within the parent GCP resource where these policies are applied. Allowing the Public Marketplace may allow users to deploy SaaS products without going through an approval process
Restrict access on marketplace services Allow ["PRIVATE_MARKETPLACE", "IAAS_PROCUREMENT"] Security admins should be able to whitelist which services can be used within the parent GCP resource where these policies are applied. Private Marketplace allow admins to whitelist services and IaaS Procurement allow users to request access to services from the Public Marketplace so that they can be added to the whitelist
Allowed VLAN Attachment encryption settings Allow ["IPSEC"] Enforces encrypted VLAN attachments only
Disable All IPv6 usage FALSE IPv6 may be more complex to use but is more secure if used properly and solves many issues of IPv4. Thus, IPv6 should be encouraged instead of disabled
Disable Creation of Cloud Armor Security Policies FALSE Cloud Armor security policies add other layers of security for applications and thus should not be disabled
Disable Global Load Balancing FALSE Global Load Balancing simplifies GCP architectures in a lot of use-cases, thus, it should not be disabled
Disable Creation of global self-managed SSL Certificates TRUE Self-managed SSL Certificates are more complex to configure than Google-managed certificates and thus, should be avoided
Disable Global Access to VM Serial Ports TRUE Enforcing this constraint disables global serial port access for Compute Engine VMs, regardless of the metadata attributes. If enabled, clients can try to connect to that instance from any IP address
Disable Guest Attributes of Compute Engine metadata TRUE Guest attributes have a lot of limitations and bring value in a very short list of use-cases
Disable Hybrid Cloud IPv6 usage FALSE IPv6 may be more complex to use but is more secure if used properly and solves many issues of IPv4. Thus, IPv6 should be encouraged instead of disabled
Disable Internet Network Endpoint Groups FALSE Connections to single internet-routable endpoints that are hosted outside of Google Cloud might be useful
Disable VM nested virtualization FALSE Setting this policy to True would disable hardware-accelerated nested virtualization which would slow down instances for some machines types
Enforce FIPS-compliant machine types TRUE FIPS-compliant machine types are following a standard for cryptographic modules which enhances encryption in transit and at rest
Disable Private Service Connect for Consumers Allow all Access to VPCs from Google APIs or other service producers such as Snowflake, Databricks or other intra-organization services should be allowed to enable some use-cases
Disable VM serial port access TRUE Enforcing this constraint disables serial port access for Compute Engine VMs, regardless of the metadata attributes. If enabled, clients can try to connect to that instance from any IP address
Disable VM serial port logging to Stackdriver FALSE Some services such as GKE Autopilot rely on serial port logging, thus, it should not be disabled
Disable SSH in browser FALSE SSH in browser provides a quick, secure and simple way to connect to a VM in GCP, it is preferable to keep this feature
Disable VPC External IPv6 usage FALSE IPv6 may be more complex to use but is more secure if used properly and solves many issues of IPv4. Thus, IPv6 should be encouraged instead of disabled
Disable VPC Internal IPv6 usage FALSE IPv6 may be more complex to use but is more secure if used properly and solves many issues of IPv4. Thus, IPv6 should be encouraged instead of disabled
Require OS Login FALSE OS Login is not available on all machine types and services but is the preferred way to handle user linux accounts, authentications and authorizations on VMs
Shielded VMs TRUE Shielded VM features add verifiable integrity and exfiltration resistance to VMs
Require predefined policies for VPC flow logs Allow ["ESSENTIAL", "LIGHT", "COMPREHENSIVE"] Enforces enabling flow logs for all subnetworks in scope with a required minimum sampling rate of 10%. Comprehensive flow logs may increase logging costs, thus should not be the only available choice
Restrict Cloud NAT usage Allow ["under:PARENT_ID"] Only subnetworks within the parent GCP resource where these policies are applied should be allowed to use Cloud NAT resources defined within the parent GCP resource
Restrict Dedicated Interconnect usage Deny all In order to be able to migrate GCP projects, dedicated interconnect should be avoided
Restrict Load Balancer Creation Based on Load Balancer Types Allow all All load balancer types within the following list could be used for different types of use-cases : INTERNAL_TCP_UDP, INTERNAL_HTTP_HTTPS, EXTERNAL_NETWORK_TCP_UDP, EXTERNAL_TCP_PROXY, EXTERNAL_SSL_PROXY, EXTERNAL_HTTP_HTTPS, EXTERNAL_MANAGED_HTTP_HTTPS, REGIONAL_INTERNAL_MANAGED_TCP_PROXY, REGIONAL_EXTERNAL_MANAGED_TCP_PROXY, GLOBAL_EXTERNAL_MANAGED_HTTP_HTTP
Restrict Non-Confidential Computing Allow all Confidential computing machine types are unfortunately very limited and could block users : N2D or C2D
Restrict Partner Interconnect usage Deny all In order to be able to migrate GCP projects, partner interconnect should be avoided
Restrict allowed Private Service Connect Consumers Allow ["under:PARENT_ID"] Only consumers within the parent GCP resource where these policies are applied should be allowed to use Private Service Connect resources defined within the parent GCP resource
Restrict allowed Private Service Connect Producers Allow ["under:PARENT_ID"] Only producers within the parent GCP resource where these policies are applied should be allowed to use Private Service Connect resources defined within the parent GCP resource
Restrict Protocol Forwarding Based on type of IP Address Allow ["INTERNAL"] Forwarding rule objects should not be allowed to target external IP addresses for security/misconfiguration considerations since no GCP external IP address is allowed within these policies
Restrict Shared VPC Backend Services Allow ["under:PARENT_ID"] Only backend services within the parent GCP resource where these policies are applied should be allowed to connect to the Shared VPC defined within the parent GCP resource
Restrict Shared VPC Host Projects Allow ["under:PARENT_ID"] Host projects for Shared VPCs should be within the parent GCP resource where these policies are applied
Restrict Shared VPC Subnetworks Allow ["under:PARENT_ID"] Only subnetworks within the parent GCP resource where these policies are applied should be allowed to connect to the Shared VPC defined within the parent GCP resource
Restrict VPC peering usage Allow ["under:PARENT_ID"] Only networks within the parent GCP resource where these policies are applied should be allowed to connect to the Shared VPC defined within the parent GCP resource
Restrict VPN Peer IPs Allow all Both IP_V4_ADDRESS and IP_V6_ADDRESS should be allowed
Restrict shared VPC project lien removal TRUE Removing a Shared VPC host project lien is a risky operation, an organization admin should be informed
Sets the internal DNS setting for new projects to Zonal DNS Only TRUE Existing projects and organizations can continue to use global DNS names, but are encouraged to migrate to zonal DNS names for regional isolation and better multi-region reliability.
Shared Reservations Owner Projects Allow ["under:projects/ADMIN_PROJECT_NUMBER"] For better finops, only administrators should manage Shared Reservations for Compute Engine
Skip default network creation TRUE Default network allows SSH, RDP and ICMP by default for incoming connections which often creates security risks on GCP projects. Thus, if needed, network should be defined as code
Compute Storage resource use restrictions (Compute Engine disks, images, and snapshots) Allow ["under:PARENT_ID"] Only projects and users with IAM permissions within the parent GCP resource where these policies are applied should be allowed to create or modify Compute Engine resources defined within the parent GCP resource
Define trusted image projects Allow ["under:projects/ADMIN_PROJECT_NUMBER"] Trusted images for Compute Engine should be audited periodically and thus, be accessible easily on a single project for the security team
Restrict VM IP Forwarding Allow ["under:PARENT_ID"] For simplicity and resilience, VM IP forwarding should be avoided and the use of VPC Peering may be preferrable. But if IP forwarding is still needed, it should only be able to IP forward to VPCs within the parent GCP resource where these policies are applied
Define allowed external IPs for VM instances Deny all To mitigate security risks, external IP addresses should never be directly attached to a Compute Engine resource. If external access is required, you can still connect through IAP, a Load Balancer or OS Login
Enforce iam.serviceAccounts.actAs checks for Compute Default Service Account FALSE Enforcing this policy could force project admins to grant the permission "iam.serviceAccounts.actAs" to a lot of GCP users without specifying only the Compute Engine service account on projects where other service accounts may have even more priviledges, thus allowing these users to perform privilege escalation...
Datastream - Block Public Connectivity Methods FALSE Datastream should be able to connect to On-Premise databases to synchronise in real-time and setting up a VPN, Direct or Carrier Peering or an Interconnect would not allow the projects to be migrated easily later... Forward SSH tunnels should be preferred even though it limits bandwidth. IP allowlist is forbidden since there is no encryption in transit possible
Domain restricted contacts Allow ["allowed_domain_1", "allowed_domain_2"] Many Google Cloud services send out notifications to share important information with Google Cloud users. These contacts should be within a list of trusted domains.
Disable Project Security Contacts FALSE As long as the essential contact is an employee of one of the trusted domain, he should be allowed to receive security alerts even though he does not have permissions at the organization or folder level to reduce security mitigation latency
Require Firestore Service Agent for import/export TRUE Using another Service Account to import or export Firestore data is deprecated and will be denied in the future. In order to avoid future downtime, only the Firestore Service Agent should be used.
Google Cloud Platform - Detailed Audit Logging Mode TRUE This policy is required for US compliance SEC, CFTC and FINRA and allows a better deep-dive into the Cloud Storage activity
Disable Cloud Logging for Cloud Healthcare API TRUE Disables Cloud Logging for the Cloud Healthcare API which might include sensitive data
Google Cloud Platform - Resource Location Restriction Allow ["in:europe-low-carbon-locations"] For sustainability and regulation purposes, only low-carbon european locations are authorized. All services on GCP are available within these locations (Finland, Belgium, Switzerland, France and Spain)
Restrict which projects may supply KMS CryptoKeys for CMEK Allow ["under:PARENT_ID"] Ensures that CMEK keys from only projects within the parent GCP resource where these policies are applied can be used to protect newly created resources
Restrict which services may create resources without CMEK Allow all Google-managed encryption keys is a secured and simple way to encrypt data in Google Cloud, it should not be forbidden
Restrict Resource Service Usage Allow all All Google Cloud services are considered "safe". The usage of Interconnect and Direct / Carrier Peering could be forbidden for the ease of migration it provides, but we might constraint users too much
Restrict TLS Versions Deny ["TLS_VERSION_1", "TLS_VERSION_1_1"] RFC 8996 of category "Best Current Practice" stipulates that TLS 1.0 and 1.1 lack support for current and recommended cryptographic algorithms and mechanisms
Domain restricted sharing Allow ["allowed_customer_id_1", "allowed_customer_id_2"] Enforcing member domains removes the NON_ORG_IAM_MEMBER security risk
Allow extending lifetime of OAuth 2.0 access tokens to up to 12 hours Deny all By default, the maximum lifetime for these access tokens is 1 hour. Allowing lifetime extensions could allow credentials if leaked to be used by attackers for a longer period of time
Disable Automatic IAM Grants for Default Service Accounts FALSE To improve security and perform least priviledge principal, Google strongly recommends to disable the automatic role grant
Disable Audit Logging exemption TRUE Audit log exemptions could reduce audit capabilities : more details here
Disable service account creation FALSE Service account creation is a required feature for many use-cases and cannot be disabled except for very specific projects
Disable service account key creation TRUE User managed service accounts should not have user-managed keys. Anyone who has access to the keys will be able to access resources through the service account
Disable Service Account Key Upload TRUE User managed service accounts should not have user-managed keys. Anyone who has access to the keys will be able to access resources through the service account
Disable Workload Identity Cluster Creation FALSE Disabling Workload Identity cluster creation would only be useful to isolate GKE workloads from other Google Cloud resources which is not wanted here
Restrict removal of Cross Project Service Account liens FALSE Any user who can modify IAM permissions at the project level should be able to remove a service account that has access to its project. If the service account needs to keep its permissions on the project, it should be set at the folder level where the users who can modify IAM permissions at the project level cannot remove it
Service account key expiry duration in hours Allow ["24h"] Service account key creation is not allowed, but if it were, a maximum expiration duration of 24h would be sufficient so that no service account keys stay active for too long
Allowed AWS accounts that can be configured for workload identity federation in Cloud IAM Allow all AWS Cognito users, for example, might need to access GCP resources for very niche use-cases
Allowed external Identity Providers for workloads in Cloud IAM Allow all Some external identity providers such as Terraform Cloud for example might need to connect to Workload Identity Pools
Disable Enabling Identity-Aware Proxy (IAP) on global resources FALSE Use of IAP is encouraged on global and regional resources
Disable Enabling Identity-Aware Proxy (IAP) on regional resources FALSE Use of IAP is encouraged on global and regional resources
Allowed VPC Service Controls mode for Anthos Service Mesh Managed Control Planes Allow all Anthos Service Mesh should be able to be used with VPC Service Controls but project owners should have the final decision whether to use the COMPATIBLE mode or not
Allowed Destinations for Exporting Resources Deny all If the GCP resource where these policies are applied can later on be migrated to an external organization, it is required to allow it here prior to the migration. Thus, it might be important to override this default value prior to the migration !
Allowed Sources for Importing Resources Deny all Resources imports should be avoided since these projects could transgress organization policies
Require Enabled Services Allow List for Cross-Organization Move Allow ["SHARED_VPC"] Shared VPCs can be migrated under certain conditions, mainly that host projects must be migrated first : more details here
Allowed Binary Authorization Policies (Cloud Run) Allow all No Binary Authorization policies are defined by this module, thus, we allow all policies
Allowed ingress settings (Cloud Run) Allow ["internal", "internal-and-cloud-load-balancing"] To trigger Cloud Run securely, we want to be able to trigger them from GCP resources ou users within our internal network or from GCP users that go through a load balancer secured by IAP if possible : more details here
Allowed VPC egress settings (Cloud Run) Allow ["private-ranges-only", "all-traffic"] When setting up a VPC Connector with Cloud Run, egress can forward egress traffic to the VPC for all traffic or when IP addresses follow RFC 1918. All traffic option provides more network audit capabilities but might be too restrictive
Restrict allowed Google Cloud APIs and services Allow all This policy can deny Cloud DNS, Compute Engine or Deployment Manager services from being used within the GCP resource where these policies are applied, but these services can most probably be used in several use-cases
Restrict Authorized Networks on Cloud SQL instances TRUE Restricts adding Authorized Networks for unproxied database access to Cloud SQL instances
Restrict Public IP access on Cloud SQL instances TRUE If misconfigured (without self-managed SSL certificates), using Authorized Networks might cause a data leakage from unencrypted data in transit : more details here
Enforce Public Access Prevention TRUE This governance policy prevents existing and future resources from being accessed via the public internet by disabling and blocking ACLs and IAM permissions that grant access to allUsers and allAuthenticatedUsers
Cloud Storage - restrict authentication types Allow all Users and service accounts should be allowed to connect to Cloud Storage as long as they are using signed requests
Retention policy duration in seconds Allow all Retention policy may vary a lot depending on the use-case, specifying a list of allowed values might be too restrictive
Enforce uniform bucket-level access TRUE Using uniform bucket-level access is recommended, because it unifies and simplifies how access to Cloud Storage resources are granted

Auto-generated module documentation

Requirements

No requirements.

Providers

Name Version
google n/a

Modules

No modules.

Resources

Name Type
google_org_policy_policy.organization_policies resource

Inputs

Name Description Type Default Required
admin_project_id Only images from the admin project will be allowed as the source for boot disks for new instances. string n/a yes
allowed_customer_ids List of Google Workspace or Cloud Identity customer IDs that can access the GCP ressources. list(string) n/a yes
allowed_domains List of domains that can be used as essential contacts. list(string) n/a yes
custom_organization_policies List of custom policies that differ from the common policies defined by the module 
list(object({
    constraint          = string                # Name of the GCP Constraint : https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints
    inherit_from_parent = optional(bool, false) # Whether the policy should propagate the policies from its parents
    rules = set(object({                        # List of rules for the policy
      allow_all = optional(string)              # "TRUE" or "FALSE", only condition can also be filled
      deny_all  = optional(string)              # "TRUE" or "FALSE", only condition can also be filled
      type      = optional(string)              # "Allow" or "Deny", condition and values can also be filled
      values    = optional(list(string))        # condition and type can also be filled
      enforce   = optional(bool)                # "TRUE" or "FALSE", only condition can also be filled
      condition = optional(object({             # can be used to filter on which ressources the policy will be applied
        description = string
        expression  = string
        location    = string
        title       = string
      }))
    }))
  }))
 [] no
export_candidate_parent_ids List of GCP organizations where the GCP ressources can be exported list(string) [] no
parent_id Defines on which GCP ressource the policies are applied. string n/a yes

Outputs

No outputs.