For the complete documentation index, see llms.txt. This page is also available as Markdown.

Deploying a connector to Google Cloud Run

Build the P0 connector SDK example, deploy it privately to Google Cloud Run, and register it in P0 so requestors can get just-in-time access to your own application.

This guide walks through deploying the gcp-cloudrun example from the connector repository to Google Cloud Run and connecting it to P0 Security.

The custom application integration is in preview. Contact P0 if you'd like to build a connector for one of your internal applications.

What you're deploying

A custom application connector is a small service that you write and host in your own cloud account. It implements six actions: validateUser, userExists, createUser, deleteUser, setPoliciesForUser, and list. P0 calls validateUser to check whether it may act on a principal at all, userExists to check whether it already has an account for them, list to learn which policies a requestor can ask for, and createUser, deleteUser, and setPoliciesForUser to provision, update, and remove access when a grant starts, changes, or ends.

This guide uses the gcp-cloudrun example included in the SDK (packages/connector-sdk/examples/gcp-cloudrun) as a starting point. It's a complete, deployable connector that you customize to call your own application instead of its placeholder logic.

Prerequisites

  • A Google Cloud project you can deploy to, with the Cloud Run and Cloud Build APIs enabled.

  • The gcloud CLI installed and authenticated to that project.

  • Node.js 24 or later to build the example locally, and Docker if you build the image yourself instead of using gcloud run deploy --source.

  • An installed P0 Google Cloud integration. P0 invokes your Cloud Run service through this integration, so its service account is the identity that reaches your connector. If you don't have it yet, install it first from the Google Cloud integration page by providing your Organization ID.

  • Admin access to your P0 workspace, to register the connector once it's deployed.

Part 1: Build the connector

  1. Clone the connector SDK repository and copy the example into your own repository:

  2. Implement your actions in src/actions.ts. Replace the placeholder logic with calls into your own application's API.

  3. Install dependencies and build:

Part 2: Deploy to Cloud Run

You can deploy straight from source with gcloud run deploy --source ., which builds the image for you, or build the container image yourself first. Either way, the service must run privately. P0 authenticates to it with a signed identity token, not over a public endpoint.

Two identity settings control who can reach and use the connector. Both must point at the same service account: the one from your P0 Google Cloud installation that P0 uses to invoke your connector. If you don't know which service account that is, contact P0.

Setting
Purpose

INVOKER_SA_EMAIL environment variable

The service account P0 uses when it calls your connector. The connector checks every request's signed identity token against this value and rejects anything that doesn't match. This is the application-level check.

roles/run.invoker IAM grant

Grants that same service account permission to reach the private Cloud Run service at all. This is the network-level boundary.

If INVOKER_SA_EMAIL is unset, the connector refuses to start.

Option A: Deploy from source

Option B: Build and push the image yourself

Grant the invoker role

Grant the same P0 service account permission to invoke the service:

Once the service is deployed, you can note its URL for your own testing. P0 resolves this URL automatically when you register the connector, so you don't paste it into P0:

Part 3: Register the connector in P0

Register the connector as a custom application in P0, following Install a custom application. Select Google Cloud Run hosting and enter your project, connector name, and region. P0 resolves the connector's invocation URL from these values, so you don't paste the service URL in.

As part of registration, P0 shows a ready-to-run gcloud command, with its invoker service account already filled in, that grants that account roles/run.invoker on your service. Run it, using the same service account for INVOKER_SA_EMAIL in Part 2 if you haven't already.

When you complete registration, P0 checks that it can authenticate to and reach the connector, so INVOKER_SA_EMAIL and the IAM binding both must be in place before this step. Once the check passes, the connector's entitlements appear in P0's request-access picker, and access requests provision, update, and revoke users through the actions you implemented.

Verify the install

  • Request access to one of your entitlements as a test user and confirm the grant provisions correctly. For the requestor's side of this flow, see Requesting access.

  • Let the grant expire, or revoke it manually, and confirm deleteUser and setPoliciesForUser behave as expected in your application.

  • Check the structured logs the SDK emits per request. Each is tagged with the route and request ID, which is the fastest way to trace a specific grant:

Troubleshooting

Symptom
Likely cause

P0 reports the connector is unreachable at install time

INVOKER_SA_EMAIL is unset or doesn't match the account P0 uses, or roles/run.invoker isn't granted to that account.

The Cloud Run revision fails to start with an exec format error

The image was built for arm64, for example on Apple silicon, without --platform linux/amd64.

Every request returns 403

The identity-token check is failing. Recheck INVOKER_SA_EMAIL against the service account from your P0 Google Cloud installation.

A grant provisions, but access doesn't work in your application

Check the createUser and setPoliciesForUser logs. The connector may be accepting a policy key your application doesn't recognize.

Last updated