Connect a Google Cloud project: in the console

Note

The console wizard is currently offered in staging only, while Google’s verification of Bobbin’s sensitive-scope consent screen is pending — production accounts currently use the script or Terraform path instead, and the console offers both side by side. This page describes the wizard so you know what to expect once it reaches production.

What you are being asked to grant

Before any redirect to Google, the wizard shows you the complete ledger: the four roles listed on the overview page, bound to one named service account, plus the one notification channel. Nothing else. What Bobbin cannot do is stated in the same breath, at the verb level: every API call it makes is a read — get, list, query — and there is no write, update, create, delete or patch call anywhere in the product.

What Google’s consent screen actually says, and what it means

Google renders one fixed description for the cloud-platform scope the wizard requests — something like “See, edit, configure and delete your Google Cloud data” — which is far broader than what the wizard actually does with it. That wording is boilerplate Google controls, not something Bobbin chose or can narrow. The wizard says so before you reach the consent screen, and lists the complete set of calls it makes with that permission, so nothing on Google’s screen is a surprise.

The token, in one sentence

The permission lives in your browser session, applies the grants above as you, and is discarded. Bobbin never holds write access to your project — not during the wizard, and not afterwards. The grants that persist are the four read-only role bindings on the service account, nothing tied to your own identity or session.

It happens in your audit log

Because the wizard applies the grant under your own signed-in Google identity, the change appears in your Cloud Audit Logs as your action — not as something Bobbin did to your project. See Verify access for the query that shows it.

What is applied

The wizard applies exactly the grants above, one binding at a time, naming each one as it lands — the same steps the script runs, applied live instead of from a terminal. At the end it hands off to the same verification check described in Verify access: success is what that check reports, never the wizard’s own opinion of the calls it made.

If your organisation blocks it

If your organisation enforces iam.allowedPolicyMemberDomains, the wizard detects it before attempting any change and stops with nothing applied — it never leaves you wondering what landed and what did not. It shows the exact exception steps (the same ones the script prints), and offers to email them to your organisation’s IAM administrator if that is not you. Nothing is sent automatically; the email is a draft you review first.

Prefer to run it yourself

The wizard’s own screen offers the script and the Terraform module side by side, with your workspace’s values already filled in. Being visibly indifferent to which path you take is deliberate — pick whichever fits how your team works.