There are several identities in one push
An authenticated Pub/Sub push sends a signed token with the delivery request. The subscription names a service account whose identity the receiver should recognize. Pub/Sub's service agent must be able to obtain the token through the documented permission path, and the receiver must authorize the configured push identity.
Those are distinct checks. The human or deployment account configuring the subscription may need permission to act as the service account. The Pub/Sub service agent handles token generation. The receiving service checks token validity, audience, and allowed identity. Granting one broad role to the application account does not automatically repair all three relationships.
Prepare the full subscription resource name, push endpoint, configured authentication service account, expected audience, and receiver platform. Obtain read access to subscription and IAM configuration. Use a safe test message and keep bearer tokens out of request logs, tickets, and shared diagnostics.
Trace generation and acceptance
- Inspect
gcloud pubsub subscriptions describe SUBSCRIPTION --project=PROJECT_ID. RecordpushConfig, endpoint, authentication service account, and any explicit audience. Confirm that the deployed subscription matches the integration design rather than an older endpoint or account. - Review the documented token-minting permission for the Pub/Sub service agent on the relevant service account. Separately check the deployer's permission to configure that identity. Use the subscription project's number when identifying the service agent, especially in cross-project integrations.
- Inspect receiver authorization. For a Cloud Run target, confirm the configured push service account has the required invoker access and that the audience matches the supported receiver contract. For a custom receiver, validate the Google-signed JWT with a maintained library, including issuer, expiry, intended audience, and expected service-account identity.
- Send a harmless message through the actual subscription. Correlate push response class, receiver authentication logs, and application handling. Distinguish token rejection from a handler that authenticates successfully but returns an application error or exceeds its response expectations.
Illustrative scenario
A fictional notification service moves from one Cloud Run service to another. The endpoint is updated, but the push configuration retains an audience intended for the old receiver. Pub/Sub can still mint tokens, yet the new receiver rejects them. The team corrects the audience and verifies invoker access for the configured push identity. Changing the publisher's identity would not repair this receiver-side mismatch.
| Observation | Check | Narrow response |
|---|---|---|
| No authenticated delivery can be made | Service-agent minting permissions | Restore the documented token path |
| Receiver rejects a validly signed token | Audience and expected identity | Match the receiver contract |
| Deployment cannot set push identity | Configurer's act-as permission | Grant only the required configuration access |
| Authentication passes, messages retry | Handler response and processing | Investigate application completion |
Verify both allowed and rejected calls
Confirm that a real subscription delivery reaches the expected receiver and performs a safe test action. Test that an unauthorized identity or wrong-audience token is rejected in an isolated environment. Check that success responses correspond to the application's accepted delivery boundary, with later business processing tracked separately where used. A valid token proves identity, not successful business completion.
Operating procedure
Keep an integration record containing subscription project, service agent, push identity, endpoint, audience, and receiver IAM owner. Revalidate it after endpoint migrations, account replacements, or organization-policy changes. Monitor authentication failures separately from handler errors and delivery latency. Avoid broad public access as a workaround for a broken token chain; repair the specific configured relationship.
Explore Clouvenix cloud security for implementation and operational handover.