Connect a Google Cloud project: with Terraform
The canonical source for this module is the terraform/ directory of
thoughtgears/bobbin-onboarding —
read the module before you apply it. It is a mechanical rendering of the
same specification as the script, not a
separate decision about what Bobbin gets.
What it applies
Section titled “What it applies”On every project you list, the module:
- grants your tenant service account the four read-only roles from the overview page
- creates one Pub/Sub-type Cloud Monitoring notification channel labelled with your tenant topic
That is the complete list — the module never requests, and never grants,
anything beyond it. It also never touches your topic’s own IAM policy:
granting your project’s Cloud Monitoring service agent publish rights on
that topic happens on Bobbin’s side, once you send us the project_numbers
output below.
module "bobbin" { source = "github.com/thoughtgears/bobbin-onboarding//terraform?ref=v0.1.0"
tenant_service_account = "tenant-acme-prod@bobbin-shard-N.iam.gserviceaccount.com" tenant_topic = "projects/bobbin-hub-N/topics/tenant-acme-prod-alerts" project_ids = ["my-production-project"]}
output "bobbin_project_numbers" { value = module.bobbin.project_numbers}Pin ref to a released tag rather than tracking a branch, so an upstream
change never lands in your plan unannounced — see the repository’s
CHANGELOG.md for what changed at each version. A working, minimal root
module is in the repository’s examples/single-project directory.
Inputs and outputs
Section titled “Inputs and outputs”| Input | Type | Required | Description |
|---|---|---|---|
tenant_service_account |
string |
yes | The service account your workspace was given. The only principal these resources ever grant anything to. |
tenant_topic |
string |
yes | Your alert intake topic as a full resource path. |
project_ids |
set(string) |
yes | The GCP projects Bobbin should investigate — one set of grants and one notification channel per project. |
channel_display_name |
string |
no | Defaults to "Bobbin (@bobby)", matching the doc and the script. |
| Output | Description |
|---|---|
notification_channel_ids |
Map of project_id → notification channel resource name. Attach these to the alert policies you want investigated. |
granted_roles |
The exact four roles granted — for your own verification. |
project_numbers |
Map of project_id → project number. Send these to Bobbin so alerts can flow. |
Domain-restricted sharing
Section titled “Domain-restricted sharing”If your organisation enforces iam.allowedPolicyMemberDomains, apply
fails on the first google_project_iam_member with a
FAILED_PRECONDITION error that does not name the policy — the same
failure the script and the manual doc describe, surfaced by Terraform
instead of gcloud. Add a conditional exception for the Bobbin
organisation (ask support for the organisation id) or a
project-level override, then apply again — the resources are idempotent,
so re-running picks up exactly where it stopped. The module deliberately
does not pre-check the policy, for the same reason the script does not:
reading it needs the Org Policy API enabled, and the customer most likely
to hit this is also the one least able to enable it safely.
Removing Bobbin
Section titled “Removing Bobbin”terraform destroyThe exact reverse of apply: it removes the four role bindings and
deletes the notification channel. The channel is configured with
force_delete = true, because Cloud Monitoring refuses to delete a
channel still referenced by an alert policy — your policies survive and
keep firing, just with one fewer notification target.
Not on the Terraform Registry
Section titled “Not on the Terraform Registry”This module is not published to the Terraform Registry — that would
require a repository named terraform-google-bobbin-onboarding, and the
onboarding material is deliberately kept in one repository alongside the
manual doc and the script. Reference it by git source, as shown above.