Connect a Google Cloud project: three paths

Connecting a project means granting a service account Nodrik created — yours, dedicated to your workspace, and named for it — four read-only IAM roles on the project, plus one Pub/Sub notification channel so your alerts reach us. There are three ways to apply that grant, and they apply exactly the same thing:

Path	Best for	Page
In the console	Teams who would rather click through a wizard than run anything	In the console
By script	An auditable gcloud script, readable before you run it	By script
With Terraform	IaC-native shops who would rather plan and apply	With Terraform

Being visibly indifferent to which one you pick is itself the point: all three derive from one specification, published in the public thoughtgears/nodrik-onboarding repository, which exists specifically to be read before it is run. There is no installer and no step that phones home.

What every path grants, and nothing more

Four Google-managed viewer roles, on the projects you choose:

Role	What it reads
roles/logging.viewer	Log entries
roles/monitoring.viewer	Metric time series, and the notification channel
roles/errorreporting.viewer	Error groups
roles/run.viewer	Cloud Run service and revision configuration, environment-variable values included

That is the complete list. No path ever requests a write role, and Nodrik’s code has no code path that would use one if it existed.

roles/logging.viewer also reads your Admin Activity audit log — IAM changes, config updates and deploys, which is where the cause lives when nothing was committed. Those entries name whoever made the change, and Nodrik replaces the address with [redacted-email] before the model sees it and before anything is stored. roles/run.viewer returns the full revision spec, environment-variable values included — Nodrik keeps the variable names and discards the values, but the permission allows reading them, so know that if your services carry secrets in plain environment variables. The full account of both is on the security page. Alongside the roles, every path also creates one Cloud Monitoring notification channel, of type pubsub, named Nodrik (@nodrik), pointing at the topic your workspace was given — that channel is what an alert policy notifies to reach Nodrik at all.

The known gotcha: domain-restricted sharing

If your organisation enforces the iam.allowedPolicyMemberDomains org policy, granting a service account from outside your domain fails with FAILED_PRECONDITION — and the raw error will not mention the policy by name. Every path surfaces it, in the way that path can:

• The console wizard reads the policy before it changes anything, and if it is enforced it stops with nothing applied and shows the exact exception steps — with an option to email them to whoever administers IAM for you, if that is not you.
• The script deliberately does not pre-check. Reading org policy needs the Org Policy API, and when that API is off gcloud offers to enable it — a write, on your project, from a procedure that promises to change nothing. Instead the script explains the failure when the first binding hits it, and stops there.
• The Terraform module surfaces the same failure from apply.

The exception is an organisation-level setting, so it is often not the person onboarding who can make it — and the case we most need to support is somebody connecting one project with no organisation access at all. Domain-restricted sharing is written for whoever administers IAM for you: what the policy does, why Nodrik trips it, the exact principal to allow, and both routes to allow it. It is meant to be forwarded, not paraphrased.

Once an exception is in place, retry — nothing already applied is lost, and all three paths pick up where they stopped.

After the grant: verify it

Applying a grant and Nodrik actually being able to read your project are two different claims — an org policy, a typo in a role name, or a channel pointing at the wrong topic can all make a grant look done and not work. The console checks the difference for you: see Verify access.

Removing access

Every path has an exact reverse — see the page for the path you used. You do not have to run it for your data to be deleted: Nodrik’s own side of the teardown (the service account that could read your project, your stored credentials) runs on our schedule within 30 days of you leaving, and does not wait for yours. Either half alone stops Nodrik reading anything.