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.
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
gcloudCLI 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
Clone the connector SDK repository and copy the example into your own repository:
Implement your actions in
src/actions.ts. Replace the placeholder logic with calls into your own application's API.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.
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
Pass --platform linux/amd64 when you build on Apple silicon. Cloud Run runs linux/amd64, and an arm64 image fails at startup with an exec format error.
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
deleteUserandsetPoliciesForUserbehave 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
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.
Related links
Custom application, the integration overview and install steps
Deploying a connector to AWS Lambda, the same install for an AWS Lambda connector
Deploying a connector with Terraform, if you manage your cloud infrastructure as code
Google Cloud integration, which P0 uses to invoke your connector
Last updated