Connect a Google Cloud project: in the console

Note

The console wizard is currently offered in staging only, while Google’s verification of Nodrik’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 Nodrik cannot do is stated in the same breath, at the verb level: every call it makes on your project is one of the list calls named on the security page — or, for a configuration role you opted into, one of that role’s get and list calls — and there is no write, update, create, delete or patch call against your Google Cloud. (Tools you connect yourself are a separate matter — see your own tools.)

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 Nodrik 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. Nodrik 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 Nodrik 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, and offers to email them to your organisation’s IAM administrator if that is not you. The wizard is the only path that can check first: it runs under your own signed-in credentials against an API that cannot offer to turn anything on, whereas the script would have to enable the Org Policy API to look, so it explains the failure instead. Nothing is sent automatically; the email is a draft you review first.

The same steps are published as a page you can send instead: Domain-restricted sharing.

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.