Acme Blogging App Hosting on Google Cloud Platform
This page details the one-off steps required to build the cloud foundations.
A recap of the overall foundation process:
Here we configure users and groups.
Groups | Members |
---|---|
gcp-billing-admins@domain | Bob Billing-Admin |
gcp-developers@domain | Dave Dev |
gcp-devops@domain | Dave Dev |
gcp-network-admins@domain | |
gcp-organization-admins@domain | Dazbo Org-Admin-SA |
gcp-project-viewers@domain | Vanessa Viewer |
gcp-security-admins@domain |
Name | Notes | |
---|---|---|
Bob Billing-Admin | bob-billing-admin@domain | Can see and manage all billing information. No access to projects or project resources. |
Dave Dev | dave-dev@domain | Can work with instances, connect to bastion, invoke functions, etc. Can only see monitoring and billing related to specific projects. No IAM. Cannot view secrets. |
Dazbo Org-Admin | dazbo-org-admin@domain | |
Vanessa Viewer | vanessa-viewer@domain | Read only access to resources. Can see billing and monitoring data, including monitoring dashboards. |
Principal | Role | Resource |
---|---|---|
gcp-organization-admins | Editor | Non-Prod |
gcp-organization-admins | Secret Manager Admin | Non-Prod |
gcp-organization-admins | Cloud Run Admin | Org |
gcp-organization-admins | Cloud Functions Admin | Org |
gcp-organization-admins | Service Account User | Org |
gcp-organization-admins | Folder IAM Admin | Org |
gcp-organization-admins | Monitoring Admin | Org |
gcp-organization-admins | Monitoring Metrics Scopes Admin | Org |
gcp-organization-admins | Editor | Non-Prod |
gcp-organization-admins | Compute Network Admin | Non-Prod |
gcp-organization-admins | Compute OS Login | Non-Prod |
gcp-organization-admins | Compute OS Login External User | Non-Prod |
gcp-project-viewers | Viewer | Org |
gcp-project-viewers | Organisation Viewer | Org |
gcp-project-viewers | Monitoring Viewer | Org |
gcp-devops | Editor | Non-Prod |
Here we configure the top-level organisation in GCP.
This process automates the one-off creation of the shared Infra-Admin Project, which is itself a Project Factory. This is where we will persist our Terraform state and allow us to run subsequent Terraform configurations.
The process:
This Project Factory has been custom-built, through a combination of bash shell and a Terraform configuration.
Pull the repo. Then:
cd iac/0-infra-bootstrap
# Configure variables for this org and for unique project IDs
source ../init_vars.sh
# Now run the bootstrap
sh ./boostrap_admin_project.sh
Pull the repo. Change to the infra
folder. Then:
. init_vars.sh
# From boostrap_admin_project.sh
# - Obtain the service account key
# - Create backend.tf
Rather than re-invent the wheel, here I’m using Terraform modules from the Google Cloud Foundation Toolkit (CFT) to help bootstrap the Cloud Build CI/CD environment.
Here we create a project for hosting the Cloud Build pipeline. It adds appropriate roles, and also creates a bucket to underpin the shared Google Container Repo.
cd iac/1-cloud-build-shared-services
source ../init_vars.sh
gcloud config set project ${TF_VAR_admin_id}
# We need to point to a new state, but in the existing bucket
cat > backend.tf << EOF
terraform {
backend "gcs" {
bucket = "${TF_VAR_admin_id}"
prefix = "terraform/cloud-build-ci/state"
}
}
EOF
terraform init
terraform validate
terraform plan -out cb-proj-plan.tfplan
terraform apply "cb-proj-plan.tfplan"
The output looks something like this:
cb_project_id = "cb-cloudbuild-6a53"
cb_sa = "800117839038@cloudbuild.gserviceaccount.com"
gcr_bucket_id = "eu.artifacts.cb-cloudbuild-6a53.appspot.com"
gcr_url = "eu.gcr.io/cb-cloudbuild-6a53"
Finally, enable vulnerability scanning on the new GCR through the Console.