Azure and GCP: identity, delegation and storage access

Apply provider-specific controls for Azure management/data permissions and SAS, plus GCP service accounts, federation and object ACLs.

Used in these playbooks#

Define the provider-specific authority graph#

Keep the shared IAM procedure, storage procedure and authorization matrix. Add the provider's actual identity and permission system before transferring an AWS hypothesis. Use two owned principals, one allowed and one restricted, and one private canary per tenant. Record Azure tenant/subscription/resource IDs or GCP organization/project/resource names, selected CLI account and impersonation settings. An application tenant must not select another tenant's cloud identity or access path.

Azure: distinguish management, data and delegation#

1. Classify the caller. Record whether the application uses a user, service principal or managed identity. Map application tenant to that principal's object ID and allowed resource. Separate Microsoft Entra directory roles from Azure resource-role assignments. Inspect inherited assignments, groups, conditions and deny assignments using owner exports when visibility is incomplete.

2. Trace the real blob authorization route. A storage management role is not automatically a Blob data role when using Entra authentication. However, management permission to retrieve account keys can create a different data-access route if Shared Key is permitted. Preserve whether the request used Entra, Shared Key or a SAS; otherwise an apparent RBAC bypass may simply be a different credential. Test only the canary and reuse the identical auth mode for both controls. Azure Blob authorization

3. Identify the SAS type. Distinguish user delegation, service and account SAS. Record signed resource, allowed operations, validity interval and any stored-access-policy relationship before testing issuance. Ask tenant A for B's owned canary through the application, then verify only the issued capability's permitted synthetic operation. A correctly issued bearer SAS working after application logout is not automatically a flaw. Revocation mechanisms differ by SAS type; compare against the product's promise instead of assuming a uniform logout rule. Azure SAS overview

GCP: distinguish attachment, impersonation and storage grants#

1. Map service-account selection. iam.serviceAccounts.actAs supports attaching an identity to an executable resource; it does not by itself grant general short-lived token creation. Token Creator permissions are a separate path. Inspect workload-create/update authority, selected service account and that account's actual resource access together. In a disposable fixture, compare one canary-only workload using the normal identity with the same supported operation using a more powerful owned identity. Do not create long-lived keys as a proof step. Service-account permission model

2. Resolve inherited and object-level access. Record project/folder/organization grants and relevant restrictions. For Cloud Storage, determine whether uniform bucket-level access is enabled. When it is disabled, object ACLs can supply access independently of bucket IAM; when enabled, ACL operations are disabled. Compare the exact object and generation under the same account. A project policy export alone cannot establish every object-access path. Uniform bucket-level access

3. Inspect workload federation bindings. Verify issuer, audience, attribute mapping, attribute condition and target-resource/service-account binding. For a shared CI identity issuer, bind trust to the intended organization/repository and environment using the provider's documented claim semantics. Compare legitimate allowed and disallowed identities in an owned fixture. A valid issuer signature establishes token origin, not entitlement to every configured workload pool. Federation for deployment pipelines

Bounded command card#

These commands contact provider APIs. Run individually using prepared owned credentials. Supply approved literal IDs; inspect Azure storage environment variables and GCP impersonation configuration first. The Azure policy command avoids Microsoft Graph name lookups, but is still an authenticated management API request. It does not enumerate group membership or prove effective access. Azure role-assignment CLI

timeout 20 az role assignment list \
  --subscription OWNED_SUBSCRIPTION_ID \
  --scope /subscriptions/OWNED_SUBSCRIPTION_ID/resourceGroups/bounty-fixture \
  --assignee-object-id OWNED_PRINCIPAL_OBJECT_ID \
  --include-inherited --fill-principal-name false -o json

env -u AZURE_STORAGE_KEY -u AZURE_STORAGE_SAS_TOKEN \
  -u AZURE_STORAGE_CONNECTION_STRING timeout 20 az storage blob show \
  --subscription OWNED_SUBSCRIPTION_ID --account-name OWNED_STORAGE_ACCOUNT \
  --container-name bounty-fixture --name canary.txt \
  --auth-mode login --only-show-errors -o json

timeout 20 gcloud --configuration=bounty-lab-low \
  storage objects describe gs://OWNED_BUCKET/bounty/canary.txt \
  --format=json

--auth-mode login prevents the Azure CLI's legacy key-lookup route from changing the identity argument. The last two commands request metadata of one known fixture. Repeat under the intended allowed identity; metadata access does not itself prove the file contents were disclosed. A timeout or absent object is not a permission denial. Azure Blob CLI, GCP object describe

Report and cleanup checklist#

• Provider, tenant/project, principal and selected authentication mode recorded.
• Management, data access and delegated workload authority separated.
• Inheritance, ACLs, conditions and visibility gaps documented.
• Allowed and denied controls address one identical synthetic resource.
• SAS/federation claims redacted; usable tokens excluded from evidence.
• Documented propagation delays considered before claiming revocation failure.
• Disposable workloads, object generations, temporary grants and shares cleaned up.

Preserve the precise failed edge and request IDs. A powerful administrator, intended delegation, stale session or deliberately public object must remain separate from an application tenant escaping its assigned authority.

Vulnerability reverse references#

• Overbroad cloud role trust — A principal outside the integration's intended trust set can obtain an owned role's authority.
• Excessive service-role delegation — A restricted principal can cause an allowed service to execute with a more powerful role than the application contract permits.
• Federated cloud role accepts the wrong workload identity — OIDC role trust accepts a legitimate token from a disallowed controlled subject, repository, branch or audience.
• Anonymous access to private object storage — An unsigned request retrieves an object that the product promises to keep private.
• Unauthorized object creation or replacement — An unauthorized principal can create or replace an object in a protected storage location.
• Signed storage capability exceeds its authorized scope — The application issues or accepts a storage capability for an object, operation or lifetime beyond the caller's entitlement.
• Private delivery policy bypassed through the origin — A private object is protected at the CDN or application edge but remains accessible directly at an owned origin.

Nearby shared procedures#

Object, function, and property authorization · Authentication, recovery, federation, and session lifecycle · Trace input into queries, commands, and templates · Server-side fetching and network trust boundaries · Browser execution, cross-origin reads, and forged actions · Uploads, downloads, paths, archives, and XML · Workflow invariants, replay, idempotency, and races · REST, GraphQL, gRPC, WebSocket, and SSE permission parity