shielded-folder

Shielded folder

This blueprint implements an opinionated folder configuration according to GCP best practices. Configurations set at the folder level would be beneficial to host workloads inheriting constraints from the folder they belong to.

In this blueprint, a folder will be created setting following features:

• Organizational policies
• Hierarchical firewall rules
• Cloud KMS
• VPC-SC

Within the folder, the following projects will be created:

• 'audit-logs' where Audit Logs sink will be created
• 'sec-core' where Cloud KMS and Cloud Secret manager will be configured

The following diagram is a high-level reference of the resources created and managed here:

Design overview and choices

Despite its simplicity, this blueprint implements the basics of a design that we've seen working well for various customers.

The approach adapts to different high-level requirements:

• IAM roles inheritance
• Organizational policies
• Audit log sink
• VPC Service Control
• Cloud KMS

Project structure

The Shielded Folder blueprint is designed to rely on several projects:

• audit-log: to host Audit logging buckets and Audit log sync to GCS, BigQuery or PubSub
• sec-core: to host security-related resources such as Cloud KMS and Cloud Secrets Manager

This separation into projects allows adhering to the least-privilege principle by using project-level roles.

User groups

User groups provide a stable frame of reference that allows decoupling the final set of permissions from the stage where entities and resources are created, and their IAM bindings are defined.

We use groups to control access to resources:

• gcp-data-engineers: They handle and run workloads on the workload subfolder. They have editor access to all resources in the workload folder in order to troubleshoot possible issues within the workload. This team can also impersonate any service account in the workload folder.
• gcp-data-security: They handle security configurations for the shielded folder. They have owner access to the audit-log and sec-core projects.

Encryption

The blueprint supports the configuration of an instance of Cloud KMS to handle encryption on the resources. The encryption is disabled by default, but you can enable it by configuring the enable_features.encryption variable.

The script will create keys to encrypt log sink buckets/datasets/topics in the specified regions. Configuring the kms_keys variable, you can create additional KMS keys needed by your workload.

Customizations

Organization policy

You can configure the Organization policies enforced on the folder editing yaml files in the org-policies folder. An opinionated list of policies that we suggest enforcing is listed.

Some additional Organization policy constraints you may want to evaluate adding:

• constraints/gcp.resourceLocations: to define the locations where location-based GCP resources can be created.
• constraints/gcp.restrictCmekCryptoKeyProjects: to define which projects may be used to supply Customer-Managed Encryption Keys (CMEK) when creating resources.

VPC Service Control

VPC Service Control is configured to have a Perimeter containing all projects within the folder. Additional projects you may add to the folder won't be automatically added to the perimeter, and a new terraform apply is needed to add the project to the perimeter.

The VPC SC configuration is set to dry-run mode, but switching to enforced mode is a simple operation involving modifying a few lines of code highlighted by ad-hoc comments.

Access level rules are not defined. Before moving the configuration to enforced mode, configure access policies to continue accessing resources from outside of the perimeter.

An access level based on the network range you are using to reach the console (e.g. Proxy IP, Internet connection, ...) is suggested. Example:

vpc_sc_access_levels = {
  users = {
    conditions = [
      { members = ["user:[email protected]"] }
    ]
  }
}

Alternatively, you can configure an access level based on the identity that needs to reach resources from outside the perimeter.

vpc_sc_access_levels = {
  users = {
  conditions = [
        { ip_subnetworks = ["101.101.101.0/24"] }
      ]
  }
}

How to run this script

To deploy this blueprint in your GCP organization, you will need

• a folder or organization where resources will be created
• a billing account that will be associated with the new projects

The Shielded Folder blueprint is meant to be executed by a Service Account having this minimal set of permission:

• Billing account
  • roles/billing.user
• Organization level:
  • roles/logging.configWriter
  • roles/resourcemanager.folderAdmin
  • roles/compute.orgFirewallPolicyAdmin
  • roles/resourcemanager.projectCreator
  • roles/orgpolicy.policyAdmin

The shielded Folder blueprint assumes groups described are created in your GCP organization. Please create them from the [https://admin.google.com/][Google Admin] console.

Variable configuration

There are several sets of variables you will need to fill in:

access_policy_config = {
  access_policy_create = {
    parent = "organizations/1234567890123"
    title  = "ShieldedMVP"
  }
}
folder_config = {
  folder_create = {
    display_name = "ShieldedMVP"
    parent       = "organizations/1234567890123"
  }
}
organization = {
  domain = "example.com"
  id     = "1122334455"
}
prefix = "prefix"
project_config = {
  billing_account_id = "123456-123456-123456"
}

Deploying the blueprint

Once the configuration is complete, run the project factory by running

terraform init
terraform apply

Variables

name	description	type	required	default
access_policy_config	Provide 'access_policy_create' values if a folder scoped Access Policy creation is needed, uses existing 'policy_name' otherwise. Parent is in 'organizations/123456' format. Policy will be created scoped to the folder.	object({…})	✓
folder_config	Provide 'folder_create' values if folder creation is needed, uses existing 'folder_id' otherwise. Parent is in 'folders/nnn' or 'organizations/nnn' format.	object({…})	✓
organization	Organization details.	object({…})	✓
prefix	Prefix used for resources that need unique names.	string	✓
project_config	Provide 'billing_account_id' value if project creation is needed, uses existing 'project_ids' if null. Parent is in 'folders/nnn' or 'organizations/nnn' format.	object({…})	✓
data_dir	Relative path for the folder storing configuration data.	string		"data"
enable_features	Flag to enable features on the solution.	object({…})		{…}
groups	User groups.	object({…})		{}
kms_keys	KMS keys to create, keyed by name.	map(object({…}))		{}
log_locations	Optional locations for GCS, BigQuery, and logging buckets created here.	object({…})		{…}
log_sinks	Org-level log sinks, in name => {type, filter} format.	map(object({…}))		{…}
vpc_sc_access_levels	VPC SC access level definitions.	map(object({…}))		{}
vpc_sc_egress_policies	VPC SC egress policy definitions.	map(object({…}))		{}
vpc_sc_ingress_policies	VPC SC ingress policy definitions.	map(object({…}))		{}

Outputs

name	description	sensitive
folders	Folders id.
folders_sink_writer_identities	Folders id.
kms_keys	Cloud KMS encryption keys created.

Test

module "test" {
  source   = "./fabric/blueprints/data-solutions/shielded-folder"
  data_dir = "./fabric/blueprints/data-solutions/shielded-folder/data"
  access_policy_config = {
    access_policy_create = {
      parent = "organizations/1234567890123"
      title  = "ShieldedMVP"
    }
  }
  folder_config = {
    folder_create = {
      display_name = "ShieldedMVP"
      parent       = "organizations/1234567890123"
    }
  }
  organization = {
    domain = "example.com"
    id     = "1122334455"
  }
  prefix = "prefix"
  project_config = {
    billing_account_id = "123456-123456-123456"
  }
}
# tftest modules=6 resources=38 inventory=simple.yaml