Diagnose Permission Denied and Identity Scope

Understand the likely causes

• The application may use ADC from a different source than the CLI, or impersonate an unexpected account. Local allow bindings may omit ancestor policies, deny rules, conditions, and service controls. A network or resource-configuration problem can also be mistaken for a permission problem. Broadening roles without locating the failed stage can leave the original issue unresolved.

1. Preserve the exact authorization question

Record operation, target resource name, project/number as required, timestamp, relevant request context, and the denied permission when available. Use existing authorized error/audit evidence with secrets redacted. Distinguish metadata access from data access and administrative operations. A role name or screenshot of a successful login is not a substitute for identifying this particular request.

2. Trace the credential source without exposing it

Compare deployer, runtime service account, impersonating actor, and application credential discovery. ADC precedence can select an environment configuration or local file before an attached identity. Do not print a token, key, or credential file to prove which account was selected. Inspect approved identity metadata and library configuration under the organization’s process.

3. Check whether the diagnostic record is complete

The complete offline program parses an invented diagnostic record and lists missing fields. It identifies absent request context rather than guessing that a role is insufficient. This is not a policy evaluator or a parser for every Google error format. Its purpose is to make the next authorized investigation concrete without contacting any account.

import json

record = json.loads('{"principal":"runtime-reader","permission":"storage.objects.get","resource":"synthetic-object","request_context":""}')
required = ["principal", "permission", "resource", "request_context"]
missing = [field for field in required if not record.get(field)]
print("missing evidence", ",".join(missing))

missing evidence request_context

4. Examine the applicable policy layers

Review the resource hierarchy, inherited allow grants, role permissions, conditions, and supported deny rules for the actual question. Policy Troubleshooter has documented coverage and limitations; it does not diagnose every ACL or VPC Service Controls case. Organization constraints and service-perimeter denials require their own evidence. Do not remove a control merely because a local binding appears correct.

5. Propose the narrow correction and verification

If authorized review confirms a missing permission, choose a justified role and supported narrow resource scope, with owner and removal conditions. If identity or context is wrong, fix that path rather than granting a more powerful account everywhere. Keep change approval, rollback, and expected allowed/forbidden cases explicit. This guide executes no inspection command, policy change, or access test.

Keep it from recurring

• Maintain an identity map, least-privilege role review, explicit resource targets, and documented ADC/impersonation assumptions. Preserve policy and group-membership governance. Keep secrets out of diagnostics, and distinguish authentication, authorization, service restrictions, and network reachability throughout incident handling.