Authenticate developers

In addition to administrative actions such as creating, updating, and deleting services, developers often want to test services privately before releasing them. This option is for Cloud Run services and not Cloud Run jobs.

Before you start

Make sure you grant permissions to access the services you are authenticating to. You must grant the Cloud Run Invoker role to the developer or group of developers:

Console UI

  1. Go to the Google Cloud console:

    Go to Google Cloud console

  2. Select the service, but don't click it.

  3. Click the Permissions tab in the right side panel. (You might need to first click Show Info Panel in the top right corner.)

  4. Click Add members.

  5. In the Add members field, enter the developer account email.

  6. Select the Cloud Run Invoker role from the Select a role drop-down menu.

  7. Click Save.


Use the gcloud run services add-iam-policy-binding command:

gcloud run services add-iam-policy-binding SERVICE \
  --member='USER:EMAIL' \


  • SERVICE is the name of the service.
  • USER is the value user or group depending on whether you are authorizing a single developer or a group.
  • EMAIL is the email account.

    For example:

    gcloud run services add-iam-policy-binding myservice \
    --member='' \

Test your private service

You can use the Cloud Run proxy or curl to test your private service.

Use the Cloud Run proxy in Google Cloud CLI

The easiest way for you to test private services is to use the Cloud Run proxy in Google Cloud CLI. This proxies the private service to http://localhost:8080 (or to the port specified with --port), providing the token of the active account or another token you specify. This lets you use a web browser or a tool like curl. This is the recommended way to test privately a website or API in your browser.

You can proxy a service locally using the following command line in a Linux, macOS, WSL (preferred), or cygwin environment:

gcloud run services proxy SERVICE --project PROJECT-ID

Use curl

Alternatively, you can test private services without the proxy by using a tool like curl and by passing an auth token in the Authorization header:

curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" SERVICE_URL

For the curl command to work, you must pass a valid ID token for a user with the run.routes.invoke permission, such as the Cloud Run Admin or Cloud Run Invoker. See Cloud Run IAM Roles for the full list of roles and their associated permissions.

To get a valid ID token for the identity logged into the gcloud CLI, use the gcloud auth print-identity-token command. You can use tokens created by the gcloud CLI to invoke HTTP requests in any project, as long as your account has the run.routes.invoke permission on the service.

For development purposes, use gcloud CLI-generated ID tokens. However, note that such tokens lack an audience claim, which makes them susceptible to relay attacks. In production environments, use ID tokens issued for a service account with the appropriate audience specified. This approach enhances security by restricting token usage to the intended service only. For non-Google Accounts, use Workforce Identity Federation to invoke your Cloud Run service so you don't have to download a service account key.

We recommend that you allocate the minimum set of permissions required to develop and use your services. Make sure that IAM policies on your services are limited to the minimum number of users and service accounts.