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:
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 PubSubsec-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 thewokloadsubfolder. They have owner access to all resources in theworkloadfolder 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 theaudit-logandsec-coreprojects.
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.folderAdminroles/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
