Authenticating 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 do not 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.

gcloud

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

gcloud run services add-iam-policy-binding SERVICE \
  --member='USER:EMAIL' \
  --role='roles/run.invoker'

where

  • 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='user:test-user@gmail.com' \
    --role='roles/run.invoker'
    

Testing your private service

Using 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:

gcloud run services proxy SERVICE --project PROJECT-ID

Using curl

You can alternatively 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 gcloud auth print-identity-token. 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.

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.