User Guide
This user guide provides a detailed overview of the process of creating an GCP landing zone. It helps in understanding the steps required to deploy the GCP landing zone as per the below functional architecture.
This guide is written for a Dev(Sec)Ops engineer who will be performing an installation and maintenance of the landing zone. The guide may also be useful for Business Security and Compliance users who are seeking to understand how the Landing Zone adds to their overall compliance posture.
- The client operates in a highly regulated industry
- The deployer - the engineer deploying the landing zone using this user guide
- The approver - somebody with an authority to approve requested action
- Google Cloud SDK v319.0.0 or later
- Terraform v1.0.9 or later
- Project Access
NOTE: Consistency in Terraform version is crucial to avoid state lock errors
- Google Cloud Organization
- Billing. Remember to note billing ID and increase the quota for associating projects to 50.
- Authentication
- Permissions
- Service Accounts. Ensure GitHub Actions and Cloud Build service accounts are added to the group_org_admins.
For a detailed setup, refer to the organization bootstrap module documentation.
The Ollion GCP Landing Zone is based on a brilliantly written example of terraform foundation; in collaboration with our partners at Google the Ollion team has significantly extended and automated these artifacts as follows:
Automation
- The foundation scripts have been updated with the latest version of services and terraform providers
- Dynamic guided workflow for seamless deployment
- Golden image monitoring solution and packer pipeline for the golden image creation have been integrated in the Landing Zone
- Deployment failure notifications over slack for debug
- Custom labels to help with monitoring and reporting and to build and organise your compliance posture
- Resource labelling with the name of its creator to aid source lineage
- Automatic instantiation and build of the entire Landing Zone and its resources through wrapper scripts
- Automatic population of variables, there is no requirement for any direct input to terraform.tfvars which are centrally located and populated through guided user UI interactions
- The Landing Zone contains the add-on functionality for the creation of folders after the whole deployment process
- Centralisation of all modules under the modules folder
- Standardised networking script for calculating and populating your network subnets
Enhancements
- The Landing Zone ships with a user-oriented user interface (UI) to simplify and guide the end user through the installation procedure. In addition the UI has a basic built-in approval workflow that generates a compliance report tracing the approval of your deployment.
- Networking preventative controls protect the perimeter, enforcing the use of Cloud Armour and CDN modules with an OPA policy.
- Golden-Images are used for deployable packages with a log of their hardening to the relevant CIS benchmark.
- Additional Business Units (BU) are added through guided and auditable workflow with approvals and then piped to a seamless hands-off deployment process
Compliance and Security
- The GCP landing zone has an Anthos Config Controller (KCC) cluster template that can be used to establish continuous compliance
- There is a set of preventive compliance scripts that make the Landing Zone demonstrate compliance in part with MAS TRM and ABS*
- Multiple compliance and security checks in workflow files that you can investigate and add to your compliance reporting
- Integration with a terraform-validator to prevent the final user to deploy a non-compliant workloads
- Integration with Google’s Security Command Center (KCC) dashboard that allows an operator continuously monitor the Landing Zone compliance.
- The Landing Zone has a GitHub script that helps the final user to secure its repository
*Our road map includes full pre-configured compliance to these and other standards, please get in touch for more details.
The second version of the landing zone is built with the principal of segregation of duties in mind. The landing zone version 2 has plenty of logical compartments such as:
- Application workload
- High Trust Interconnect
- No Trust Interconnect
- Network Hub
- Security Posture
- Billing
- Audit
- etc
The access to a compartment is controlled by a separate RBAC group to ensure that only authorized individuals can access the compartment.
The installation part consists of seven stages:
- Bootstrap
- Organisation setup
- Environment setup
- Network setup
- Project setup
- Application setup
- Continuous compliance setup
To maintain organization and facilitate navigation, this repository is structured as follows:
repo:
|- 0-bootstrap
|- <terraform_code>
|- 1-org
|- <terraform_code>
|- 2-env
|- <terraform_code>
|- 3-networks
|- <terraform_code>
|- 4-projects
|- <terraform_code>
|- 5-app-infra
|- <terraform_code>
|- 6-anthos
|- <application_manifests>
|- kcc
|- <terraform_code>
|- <resource_manifests>
|- modules
|- <terraform_module_folder_1>
|- <terraform_module_folder_2>
Follow the below steps to add the folder under any stage/level of the Landing Zone.
- Copy the below content and create the main.tf file.
resource "google_folder" "department1" {
display_name = var.name
parent = var.parent_folder
}
- Copy the below content and create variables.tf file
variable "name" {
description = "It contains the name of the folder"
type = string
default = "<value>"
}
variable "parent_folder" {
description = "Optional - for an organization with existing projects or for development/validation. It will place all the example foundation resources under the provided folder instead of the root organization. The value is the numeric folder ID. The folder must already exist."
type = string
default = "<value>"
}
- Copy and create versions.tf file.
terraform {
required_version = ">= 1.0.9"
required_providers {
google = {
source = "hashicorp/google"
version = ">= 3.89.0"
}
}
provider_meta "google" {
module_name = "blueprints/terraform/terraform-example-foundation:bootstrap/v2.3.0"
}
}
- Perform terraform plan and then terraform apply, soon you will notice that the folder was created under the organization/folder.
Argument Reference
The following arguments are supported:
- display_name - (Required) The folder’s display name. A folder’s display name must be unique amongst its siblings, e.g. no two folders with the same parent can share the same display name. The display name must start and end with a letter or digit, may contain letters, digits, spaces, hyphens, and underscores, and can be no longer than 30 characters.
- parent - (Required) The resource name of the parent Folder or Organization. Must be of the form folders/{folder_id} or organizations/{org_id}.
That’s quite straightforward, you have to perform next steps:
- Create a user under the GCP-IAM console
- Add the user to the group_org_admins group to grant the user specific permissions to access the Landing Zone.
- Fork the Git-hub GCF-Template repository one time only.
- Create a new branch from the main branch which will be in template form
- Navigate to gcp-lz/rego/rules/tf/google, here you can find the folders of Google servicesgcp-lz
└── rego
└── rules
└── tf
└── google
├── bigquery
│ ├── dataset_encryption.rego
│ └── no_public_access.rego
├── googleworkspace
│ └── user_password_encrpytion.rego
├── kms
│ ├── key_rotation.rego
│ └── key_versioning.rego
├── pubsub
│ └── encryption.rego
├── secret_manager
│ └── replication_enabled.rego
- For the creation of Rego policies of any other Google, you need to create a folder with the service name containing the rego files. For example: Create folder name with storage that contains rego policies for storage service.
└── storage
├── bucket_encryption.rego
├── no_public.rego
├── uniform_access.rego
└── versioning.rego
- Push the the code to bu_main branch, create a pull request and get it approved and merge the changes.
- Now the changes were being deployed over the Landing Zone.
- For adding more policies repeat step-2 to step-5.
- Any constraints that are to be installed into the KCC need to have its respective constraint template defined.
- Create the constraint template and add to the templates directory under kcc/kcc-policies
git add kcc/kcc-policies/templates
git commit -m "Adding custom constraint template"
git push origin temp-branch
Raise a PR to merge into the sync-branch
The script that installs KCC will apply the manifests and have the constraint template defined inside the cluster.
- To add the custom constraint, add the constraint manifest under the kcc/kcc-polices/constraints folder and push it to the sync-branch configured in the config sync. The config sync will fetch the latest update and apply the constraint manifest to KCC.
git add kcc/kcc-policies/constraints
git commit -m "Add custom constraints"
git push origin temp-branch
Raise a PR to merge into the sync-branch
Files and folder hierarchy in repository
Root (gcp-lz)
kcc
kcc-policies
constraints (sub folders - sample GCP services listed)
<BigQuery>
gcp_bigquery_access_control.yaml
gcp_bigquery_encryption.yaml
<PubSub>
templates (sub folders - sample GCP services listed)
<CloudStorage>
<CloudSQL>
There are below folder types are available for the consumption:
- constraints-examples - folder that contains sample constraints
- templates - folder that contains constraint templates
- constraints - folder that contains custom constraints
If end users want to write new constraints for any template that has already been created and applied:
- Write the new constraint .yaml file
- Place the file in the appropriate service folder in the constraints folder. If there isn’t an appropriate service folder, create one
- Create a PR and get it approved to merge into the main branch
If end users want to write a new constraint template from scratch:
- Write the new constraint template .yaml file
- Place the file in the appropriate service folder in the templates folder. If there isn’t an appropriate service folder, create one
- Create a PR and get it approved to merge into the main branch
It’s a very difficult question as the final prices will vary significantly based on number of applications you deploy and associate with it, on a geographical region where the landing zone deployed, on your resources consumption any many more.
Thus, to give a rough understanding for the final user on the cost of the Landing Zone, our team has decided to deploy a standard set of landing zone services without taking into account the final cost of the user’s application.
To conclude, if the landing zone will be deployed “as is“, the final cost estimate is USD 837 per month.
The detailed breakdown estimate:
| N | Stage | Monthly Cost (USD) |
|---|---|---|
| 0 | Bootstrap | 0.06 |
| 1 | Organisation | 0 |
| 2 | Environments | 0 |
| 3 | Networking | 1.6 |
| 4 | Projects | 0.06 |
| 5 | Application Infrastructure | Depends on the client's workload* |
| 6 | Kubernetes Config Controller | 244 |
| Total | 246 |
*Please, take a note that the estimation cost of running sample Bank of Anthos application is about $591 a month.
NOTE: Please, take note that the above breakdown is given for indicative purposes.
Also, please take note that the cost of the Landing Zone has been estimated through the Infracost and we do not warrant its accuracy.
Don’t worry, we are always ready to lend you a hand! Send us an email at lzhelp@ollion.com with your problem and our support team will reach out to you shortly.
Obviously! If you would like to fix the landing zone your self, please submit a pull request into the landing zone repository. Otherwise, please email to the lzadmin@ollion.com with the detailed problem description.
The system has a set of connectors for the other VCS system, but an additional configuration has to be made.
Please, ensure that you are editing index.html under the //frontend/dist/index.html directory. In addition, please ensure that you are editing token values:
<meta property="VUE_APP_GIT_TOKEN" content="paste token here" />
<meta property="VUE_APP_SECRETKEY" content="paste token here"/>
Please, check out a section about the user interface above.
Otherwise, the browser storage won’t be encrypted, which is a potential security vulnerability. If the GitHub token won’t be populated, the auto verification of the pull request won’t work. On the other hand, you’ll skip verification by disabling this functionality:
- The terraform plan successfully completes, but the terraform apply fails during the installation. This might happen due to incomplete pre-requisites and to fix the issues ensure all the pre-requisites are completed properly. If the issue still persists, please take a look at the CloudBuild logs for the deployment of that particular stage.
- Wrapper Script execution fails due to older .terraform folder present that differs with the definitions in .terraform.lock.hcl file. This might happen due to an earlier installation, to fix this please remove the older .terraform folder from the particular stage where it has occurred.
- Contact details in the UI variables page. There are two fields for contact details, one for the primary email and another for the secondary email. The values of these fields should be different.
- Enabling APIs takes time. At several stages in the LZ multiple API services from the GCP are enabled, and it takes several minutes before the API is actually enabled, however the terraform apply might fail even when the terraform plan successfully completes.
At the last stage of LZ deployment, deployment of the Security Command Center (SCC) stage might fail in spinning up the Kubernetes Config Controller (KCC) cluster with the error 2 resources failed but this automatically gets fixed within 4 minutes. This happens due to GCP policy binding as policy binding takes 3-4 minutes to be in act, that’s why sometimes we may face this issue.
If none of the above helped, please describe the problem clearly and send an email to lzhelp@ollion.com.
There is no known bug so far, but you’ll be able to raise a bug in our public repository.
To report a bug, please create an issue in GitHub repository. Depends on the bug type, please use appropriate label:
Please, spend some time in writing a good problem statement and clear title. The well written description will drastically increase chance for the issue to be picked and fixed. Here is a good article on how to write a good GitHub issue.
- Ramneek Khurana, Google Singapore, Customer Success Engineer
- Yang Kai Loo, Ollion, Customer Solutions Consultant Intern
- Brendon Byrne, Ollion, Head of Solution Architecture
- Aditya Khowala, Ollion, DevSecOps Engineer
- Alexander Makarov, Ollion, Technical Product Owner
- Aman Singh, Ollion, DevOps Engineer
- Fahad Khan, Ollion, DevOps Engineer
- Kishor Dhenge, Ollion, Associate Project Manager
- Sachi Dubey, Ollion, Project Manager
- Sanket Nadkarni, Ollion, DevOps Engineer
- Sachin Ghait, Ollion, Senior Software Developer
- Tridev Chawda, Ollion, Lead DevOps Engineer
- Varun Chandak, Ollion, Lead DevOps Engineer
- Vivek Yadav, Ollion, Software Developer