Files
hunfabric/blueprints/data-solutions/shielded-folder
2023-01-30 23:47:33 +01:00
..
2023-01-18 15:50:49 +01:00
2023-01-30 23:32:13 +01:00
2023-01-30 23:32:13 +01:00
2023-01-30 23:32:13 +01:00
2023-01-30 23:47:33 +01:00
2023-01-30 23:32:13 +01:00
2023-01-30 23:47:33 +01:00
2023-01-30 23:47:33 +01:00

Shielded folder

This blueprint implements an opinionated Folder configuration to implement GCP best practices. Configurations implemented on the folder would be beneficial to host Workloads hineriting contrains from the folder they belong to.

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

  • Organizational policies
  • Hirarckical 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:

Shielded architecture overview

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 defined.

We use three groups to control access to resources:

  • data-engineers: They handle and run workloads on the wokload subfolder. They have owner access to all resources in the workload folder in order to troubleshoot possible issues with pipelines. This team can also impersonate any service account.
  • 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 support the configuration of an instance of Cloud KMS to handle encryption on the resources. The encryption is disabled by default, but you can enble it configuring the enable_features.kms variable.

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

How to run this script

To deploy this blueprint on 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 (or a regular user) having this minimal set of permission:

  • Billing account
    • roles/billing.user
  • Folder level
    • roles/resourcemanager.folderAdmin
    • roles/resourcemanager.projectCreator

The shielded Folfer blueprint assumes groups described are created in your GCP organization.

Variable configuration

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

organization = {
  id     = "12345678"
  domain = "example.com"
}
prefix = "prefix"

Deploying the blueprint

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

terraform init
terraform apply

Variables

name description type required default
organization Organization details. object({…})
prefix Prefix used for resources that need unique names. Use 9 characters or less. string
access_policy Access Policy name, set to null if creating one. string null
access_policy_create Access Policy configuration, fill in to create. Parent is in 'organizations/123456' format. object({…}) null
data_dir Relative path for the folder storing configuration data. string "data"
enable_features Flag to enable features on the solution. object({…}) {…}
folder_create Provide values if folder creation is needed, uses existing folder if null. Parent is in 'folders/nnn' or 'organizations/nnn' format. object({…}) null
folder_id Folder ID in case you use folder_create=null. string null
groups User groups. map(string) {…}
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({…})) {…}
projects_create Provide values if projects creation is needed, uses existing project if null. Projects will be created in the shielded folder. object({…}) null
projects_id Project id, references existing projects if project_create is null. Projects will be moved into the shielded folder. object({…}) null
vpc_sc_access_levels VPC SC access level definitions. map(object({…})) {}
vpc_sc_egress_policies VPC SC egress policy defnitions. map(object({…})) {}
vpc_sc_ingress_policies VPC SC ingress policy defnitions. map(object({…})) {}
vpc_sc_perimeters VPC SC regular perimeter definitions for shielded folder. All projects in the perimeter will be added. object({…}) {}

#TODO Proper README (after deciding if this is a blueprint or a FAST stage)

Implemented

  • Use of Scoped Policies (create or inherit)
  • VPC SC adding all Folder's project into the perimeter
  • Org policies
  • Hierarchical firewall rules

TODO

  • Log sync
  • KMS