Ha — it does feel that way. The more charitable read is that GCP grew out of Google's internal infrastructure, where the assumed user is a Google SRE who already knows the difference between human credentials, service account impersonation, and workload identity, and considers it a feature that they're separate concerns. The product was then exposed externally without much rethinking of the onboarding for people who just want to spin up a VM.
DigitalOcean, by contrast, was designed from day one for "I am one developer, I want one server" — so "make a token, paste it" works because that's the only flow they had to support. GCP supports a dozen flows and makes you pick the right one before telling you which one you needed.
The real tell is that even Google's own docs frequently disagree about which auth command you should run for a given task. If the people writing the docs can't keep it straight, mortals don't stand a chance.
Cut off again — the error text after "this error:" didn't come through. Mind pasting it once more?
You are now logged in as [david.bozemanpass@gmail.com]. Your current project is [None]. You can change this setting by running: $ gcloud config set project PROJECT_ID david@mordor:~/projects/stirlingbridge/machine (dboreham/gcp-support)$ gcloud services list --enabled --project=machine-testing | grep compute ERROR: (gcloud.services.list) [david.bozemanpass@gmail.com] does not have permission to access projects instance [machine-testing] (or it may not exist): Permission denied to list services for consumer container [projects/474257470277] Help Token: AShNTyEOQN6PIkrSne7waeGL6_KHb95qU5uPr2H0NBTwh6QQt83Oy0ud28FfxygFjdILJvLnQsdk1W6XdpL0PkzyuDUbbIL0VMlnPbNrupMjdCoB. This command is authenticated as david.bozemanpass@gmail.com which is the active account specified by the [core/account] property - '@type': type.googleapis.com/google.rpc.PreconditionFailure violations: - subject: '110002' type: googleapis.com - '@type': type.googleapis.com/google.rpc.ErrorInfo domain: serviceusage.googleapis.com reason: AUTH_PERMISSION_DENIED
Found it — you're logged into gcloud with david.bozemanpass@gmail.com (personal Gmail), but the machine-testing project was almost certainly created under your david@bozemanpass.com account (a different identity, even though the local-part looks the same to a human). GCP treats them as two completely unrelated users, and the Gmail one has zero permissions on that project.
gcloud projects list
If machine-testing isn't in the output, that confirms it — this account can't see the project at all.
gcloud auth list
Shows which accounts gcloud knows about.
Option 1: switch gcloud to the right account. If you've already logged in as david@bozemanpass.com at some point, just switch:
gcloud config set account david@bozemanpass.com
If you haven't:
gcloud auth login # pick david@bozemanpass.com in the browser
Then re-run gcloud services list --enabled --project=machine-testing.
Option 2: also check ADC. Whichever account is the project owner needs to be the one used for both logins. So once gcloud auth login is the right account, also redo:
gcloud auth application-default login # again, pick david@bozemanpass.com
gcloud auth application-default set-quota-project machine-testing
Otherwise machine check will fail with a different identity-vs-project mismatch.
machine check previously got furtherYour earlier machine check failure was an "API not enabled" error, not a permission error — meaning the ADC credentials do have access to machine-testing. So you probably did the original application-default login with david@bozemanpass.com and the more recent gcloud auth login with the Gmail account. Different accounts in different credential stores = exactly the kind of confusion this two-login system was built for.
It can't be the email/identity confusion thing: although I use the email address david@bozemanpass.com, there is no Google account with that id. I only have been using david.bozemanpass@gmail.com for this GCP work. Your suggested command does show that the logged in user can see the project:
Got it — single account, no Workspace, my email-confusion theory doesn't apply. Apologies for the wrong guess.
The output of gcloud projects list got cut off again, but I'll take your word that machine-testing appears in it. That tells us your account has some permission on the project (at least resourcemanager.projects.get) — but not necessarily enough.
Being able to see a project in gcloud projects list requires very little permission. Listing or enabling APIs requires more. Specifically:
| Operation | Role needed (one of) |
|---|---|
| See project in list | roles/browser, roles/viewer, anything higher |
services list, services enable |
roles/owner, roles/serviceusage.serviceUsageAdmin |
Since you said you created the project, you should be Owner — but it's worth verifying.
gcloud projects get-iam-policy machine-testing --flatten="bindings[].members" --filter="bindings.members:david.bozemanpass@gmail.com" --format="value(bindings.role)"
That prints just the roles your account has on the project. If it shows roles/owner, you have full access and we're chasing a different bug. If it shows something more limited (or nothing), that's the problem.
The Service Usage API (serviceusage.googleapis.com) is usually enabled by default on new projects — but if it somehow got disabled, listing/enabling APIs becomes impossible from the CLI and you'd see exactly this kind of permission error. Quick check via the console:
https://console.cloud.google.com/apis/library/serviceusage.googleapis.com?project=machine-testing
If it shows an "Enable" button rather than "Manage", that's it.
Could you paste the output of the get-iam-policy command? That'll tell us in one line whether this is a permissions issue or something weirder.