Using Workload Identity

This page explains how to authenticate your Cloud Run for Anthos service to use Google Cloud APIs by enabling Workload Identity.

To use Google Cloud APIs such as the Compute APIs, Storage and Database APIs, or Machine Learning APIs from within your GKE cluster, you must have permissions and authenticate your Cloud Run for Anthos service by enabling Workload Identity and binding a Kubernetes service account to act as a Google service account.

Enabling Workload Identity on your cluster

To set up Workload Identity with Cloud Run for Anthos, see the following instructions to enable it on your cluster; otherwise, skip to the next section:

Enable Workload Identity on a new cluster or Enable Workload Identity on an existing cluster

Enabling metrics on a cluster with Workload Identity

When enabling Workload Identity, Cloud Run for Anthos doesn't report certain metrics, such as revision request count or request latency to Google Cloud's operations suite, but continues reporting metrics for CPU and memory.

To enable all metrics, you need to manually set permissions to write metrics to Cloud Monitoring by granting the Monitoring Metric Writer role to the Google service account (GSA) associated with your Cloud Run for Anthos service.

Grant the Monitoring Metric Writer role permissions to your service's GSA:

gcloud projects add-iam-policy-binding PROJECT_ID 

  --member=serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com 

  --role=roles/monitoring.metricWriter

Replace:

PROJECT_ID with the project ID for a cluster project that hosts your KSA.
GSA_PROJECT with the project ID for a GSA that's not in the cluster. You can use any GSA in your organization.

For more information, see Granting, changing, and revoking access to resources.

Binding service accounts

You need to set up a relationship for a Kubernetes service account (KSA) to act as a Google service account (GSA). Any workload running as the KSA automatically authenticates as the GSA when accessing Google Cloud APIs.

If a Kubernetes service account (KSA) doesn't exist, create one in the same Kubernetes namespace as your Cloud Run for Anthos service; otherwise, skip to the next step:
```
kubectl create serviceaccount --namespace K8S_NAMESPACE KSA_NAME
```

Create a relationship between KSAs and GSAs, so that the workload running as the KSA automatically authenticates as the GSA when accessing Google Cloud APIs:

Authorize your KSA to act as a GSA:

gcloud iam service-accounts add-iam-policy-binding \
--role roles/iam.workloadIdentityUser \
--member "serviceAccount:PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME]" \
GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com

Update the cluster to leverage the binding:

kubectl annotate serviceaccount \
--namespace K8S_NAMESPACE \
 KSA_NAME \
 iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com

Deploying a new service with a new identity

Deploy your service using the KSA that exists within the cluster and namespace of the service you want to deploy. The service account may belong to a different project than the cluster.

Console

Go to Cloud Run
Click Create Service if you are configuring a new service you are deploying to. If you are configuring an existing service, click on the service, then click Edit and Deploy New Revision.
Under Advanced Settings, click Container.
Click the Service account dropdown and select the desired service account.
Click Create or Deploy.

gcloud

You can update an existing service to have a new runtime service account by using the following command:

gcloud run services update SERVICE --service-account SERVICE_ACCOUNT

Replace:

SERVICE with the name of your service.
SERVICE_ACCOUNT with the service account associated with the new identity.

You can also set a service account during deployment using the command:

gcloud run deploy --image IMAGE_URL --service-account SERVICE_ACCOUNT

Replace:

IMAGE_URL with a reference to the container image, for example, gcr.io/myproject/my-image:latest.
SERVICE_ACCOUNT with the service account associated with the new identity.

YAML

You can download and view existing service configuration using the gcloud run services describe --format export command, which yields cleaned results in YAML format. You can then modify the fields described below and upload the modified YAML using the gcloud beta run services replace command. Make sure you only modify fields as documented.

To view and download the configuration:

gcloud run services describe SERVICE --format export > service.yaml

Update the serviceAccountName: attribute:
```
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE
spec:
  template:
    spec:
      serviceAccountName: SERVICE_ACCOUNT
```
Replace
- SERVICE with the name of your Cloud Run service.
- SERVICE_ACCOUNT with the service account associated with the new identity.
Replace the service with its new configuration using the following command:
```
gcloud beta run services replace service.yaml
```