GCP Resource Name Parser

Read a GCP resource name in any of the forms Google uses: relative, full, self link, or service account email. It names the project, the location and the resource, and says whether the project is an ID or a number, which are not interchangeable.

Paste below, or drop a file anywhere on this panel

Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.

The answer appears here

Paste on the left and press Parse the names. Nothing leaves this tab.

Wanted a different tool?

  • GCP IAM Policy Analyzer because IAM bindings return project numbers and service account emails, which is where most of these names come from.
  • AWS ARN Decoder for the same job on AWS, where one ARN format replaces four Google forms.
  • GCP Cloud Run Config Analyzer if the name is a Cloud Run service, because the service account it runs as is the part of its configuration that matters most.

Examples

Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.

A project number, not an ID

Both are valid in a resource name and are different strings. IAM and audit logs return the number; documentation shows the ID.

projects/764086051850/locations/us-central1/services/api

A region where a zone belongs

A zone is a region plus a letter, and the request resolves to nothing with an error about the instance rather than the location

projects/my-app-prod/zones/us-central1/instances/web-1

The default Compute Engine account

Built from the project NUMBER, unlike the App Engine default which uses the ID, and holding Editor on the project unless that grant was disabled

764086051850-compute@developer.gserviceaccount.com

An address on the wrong domain

A user-managed account ends in .iam.gserviceaccount.com, and the plain domain belongs to Google-managed service agents

app@my-app-prod.gserviceaccount.com

Common mistakes

These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.

  1. Treating a project ID and a project number as interchangeable

    Both are valid in a resource name and they are different strings. IAM bindings and audit logs return numbers, documentation shows IDs, and some APIs accept only one. The wrong one fails as a not-found rather than as a validation error, because it is a legal identifier that matches nothing.

    Instead:Resolve once with gcloud projects describe and store whichever your tooling needs, rather than converting at each call site.

  2. Parsing a self link as a relative resource name

    A self link carries the API and version in front of the resource path, so /compute/v1/projects/p/... read as collection and id pairs gives a collection called compute with an id of v1, and shifts every later pair. The parse succeeds and every field is wrong.

    Instead:Skip everything before the first projects, organizations or folders segment.

  3. Assuming the two default service accounts follow one convention

    The Compute Engine default is PROJECT_NUMBER-compute@developer.gserviceaccount.com and the App Engine default is PROJECT_ID@appspot.gserviceaccount.com. Same platform, opposite identifier, and neither matches the user-managed form which puts the project ID in the domain.

    Instead:Read the project from the domain for a .iam.gserviceaccount.com address and from the local part otherwise.

  4. Putting a region where a zone belongs

    A zone is a region plus a letter. zones/us-central1 resolves to nothing, and the error names the resource rather than the location, so it reads as the instance not existing.

    Instead:Check the trailing letter. locations/ is the generic collection newer APIs use and it takes a region or a multi-region, which is a third case again.

  5. Running a workload as a default service account

    The Compute Engine default is granted Editor on the project unless that was disabled, so anything using it can change almost everything. It is also shared, so an audit log cannot say which workload acted.

    Instead:Create a service account per workload with only the roles it needs, and disable the automatic Editor grant.

Google names the same resource four different ways

Each form appears somewhere you will paste it, and they are not interchangeable. Two of the differences have no error message at all, only a not-found.

The four forms

A relative resource name is what an IAM policy holds. A full resource name adds the service host and is what an audit log holds. A self link is an https URL from an API response, and it carries the API name and version in front of the resource path, which is the part a naive parser reads as a collection. A service account email encodes a project in a fifth way again.

projects/p/zones/us-central1-a/instances/web-1
//compute.googleapis.com/projects/p/zones/us-central1-a/instances/web-1
https://www.googleapis.com/compute/v1/projects/p/zones/us-central1-a/instances/web-1
app@p.iam.gserviceaccount.com

A project ID and a project number are both valid and are not the same

projects/my-app-prod and projects/764086051850 can name one project. IAM bindings and audit logs return numbers, nearly all documentation shows IDs, and some APIs accept only one of the two. A number where an ID is expected fails as a not-found rather than as a validation error, because the string is a legal project identifier that simply does not match anything.

gcloud projects describe 764086051850   prints the ID
gcloud projects list                    shows both

The two default service accounts disagree about which one they use

The default Compute Engine account is PROJECT_NUMBER-compute@developer.gserviceaccount.com. The default App Engine account is PROJECT_ID@appspot.gserviceaccount.com. Same platform, same purpose, opposite identifier, and neither of them looks like the user-managed form, which puts the project ID in the domain rather than the local part.

764086051850-compute@developer.gserviceaccount.com
my-app-prod@appspot.gserviceaccount.com
app@my-app-prod.iam.gserviceaccount.com

A zone is a region plus a letter

us-central1-a is a zone inside the region us-central1. Put a region where a zone belongs and the request resolves to nothing, and the error names the resource rather than the location, so it reads as the instance not existing. There is also global, and a handful of multi-regions, us and eu and asia, which are neither.

Two resources break the pattern entirely

A Cloud Storage bucket name carries no project at all and is unique across every Google Cloud customer, which is why it is the one resource whose name says nothing about who owns it. BigQuery uses project:dataset.table, with a colon and a dot instead of slashes. Both are worth knowing because a parser written against the relative form rejects them.

The default Compute account is why least privilege gets skipped

Any workload that does not name a service account runs as it, and it is granted Editor on the project unless that automatic grant was disabled. So the default is broad access, shared between every workload that did not choose, which also means an audit log entry cannot say which one acted. Naming a service account per workload is the single highest-value change available in a GCP project.

What this cannot see

Whether the resource exists, whether you may see it, and whether a project number and a project ID refer to the same project, because all three need a call to Google and this page makes none. It reads the shape of the name and says what each segment is, which is the question you have when a string appears in a log and you cannot tell what produced it.