This documentation is for the Latest version of Knative serving, which uses fleets and Anthos Service Mesh. Learn more.

The past version (Cloud Run for Anthos) has been archived but the documentation remains available for existing users.

Available versions

Latest
Archive

Using Workload Identity Federation for GKE

Learn how to authenticate your Knative serving services with Workload Identity Federation for GKE to access Google Cloud APIs such as the Compute APIs, Storage and Database APIs, or Machine Learning APIs.

To authenticate your Knative serving services, you must:

Enable Workload Identity Federation for GKE in your cluster
Configure permissions
Bind your Kubernetes Service Account (KSA) to a Google Service Account (GSA)

After following these steps, you can deploy a new Knative serving service that uses the identity that you created.

Enabling Workload Identity Federation for GKE on your cluster

To set up Workload Identity Federation for GKE with Knative serving, you can setup fleet Workload Identity Federation instead of using a Google Cloud Service Account JSON file.

Configure permissions to enable all metrics

To enable metrics, like reporting request count or request latency to Google Cloud Observability, you need to grant write permissions for Cloud Monitoring. For example, you can grant the Monitoring Metric Writer role (roles/monitoring.metricWriter) to the Google Service Account that is associated with Knative serving because it includes the necessary permissions for writing monitoring data. See Using service accounts for more information about creating Google Service Accounts.

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 that you bind, automatically authenticates as the GSA when accessing Google Cloud APIs. The KSA that you bind must exist within the cluster and namespace of the Knative serving service for which you want to use Workload Identity Federation for GKE. The GSA can belong to a different Google Cloud project from the Google Cloud project where the cluster resides.

If a GSA doesn't exist, create one; otherwise, skip to the next step. You can create a GSA for use with Knative serving within any Google Cloud project in your organization and then use it from in the Google Cloud project where your Knative serving services run.

To create a new GSA, run the following command:
```
gcloud iam service-accounts create GSA_NAME
```
Replace GSA_NAME with the name of the new Google service account.

For more information about using Google service accounts with your Knative serving services, see Using service accounts.
Ensure that your GSA has the IAM roles that you need. You can grant additional roles using the following command:
```
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
    --role "ROLE_NAME"
```
Replace:
- PROJECT_ID: with the Google Cloud project ID where your Google Service Account resides.
- GSA_NAME with the name of your Google Service Account.
- ROLE_NAME with the IAM role to assign to your GSA, like roles/monitoring.metricWriter.
If a Kubernetes Service Account doesn't exist, create one in the same Kubernetes namespace as your Knative serving service; otherwise, skip to the next step:
```
kubectl create serviceaccount --namespace K8S_NAMESPACE KSA_NAME
```
Bind the Kubernetes and Google service accounts to create the identity and then deploy it to your cluster:
1. Allow the KSA to impersonate the GSA by creating an IAM policy binding between the two.
```
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_ID.iam.gserviceaccount.com
```
  Replace:
  - PROJECT_ID with the ID of the Google Cloud project for the cluster where your Kubernetes Service Account and Knative serving services reside.
  - K8S_NAMESPACE/KSA_NAME with the namespace and name of your Kubernetes Service Account.
  - GSA_NAME@GSA_PROJECT_ID with the name of your Google Service Account and ID of the Google Cloud project. You can use any Google Service Account in your organization. To view your Google Service Accounts, see Listing service accounts.
2. Add the iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT_ID annotation to the KSA, using the email address of the GSA.
```
kubectl annotate serviceaccount \
--namespace K8S_NAMESPACE KSA_NAME \
 iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT_ID.iam.gserviceaccount.com
```
  Replace:
  - K8S_NAMESPACE/KSA_NAME with the namespace and name of the Kubernetes Service Account for which you created a binding.
  - GSA_NAME@GSA_PROJECT_ID with the name of your Google Service Account and ID of the Google Cloud project for which you created a binding.

Deploying a new service to use Workload Identity Federation for GKE

Deploy a new Knative serving service that uses the Workload Identity Federation for GKE you created.

Console

Go to Knative serving in the Google Cloud console:

Go to Knative serving
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 & Deploy New Revision.
Under Advanced settings, click Container.
Click the Service account dropdown and select the desired service account.
Click Next to continue to the next section.
In the Configure how this service is triggered section, select which connectivity you would like to use to invoke the service.
Click Create to deploy the image to Knative serving and wait for the deployment to finish.

Command line

For existing services, set the Kubernetes Service Account by running the gcloud run services update command with the following parameters:
```
gcloud run services update SERVICE --service-account KSA_NAME
```
Replace:
- SERVICE with the name of your Knative serving service.
- KSA_NAME with the Kubernetes Service Account that you used to create the workload identity.
For new services, set the Kubernetes Service Account by running the gcloud run deploy command with the --service-account parameter:
```
gcloud run deploy --image IMAGE_URL --service-account KSA_NAME
```
Replace:
- IMAGE_URL with a reference to the container image, for example, gcr.io/cloudrun/hello.
- KSA_NAME with the Kubernetes Service Account that you used to create the workload identity.

YAML

You can download the configuration of an existing service into a YAML file with the gcloud run services describe command by using the --format=export flag. You can then modify that YAML file and deploy those changes with the gcloud run services replace command. You must ensure that you modify only the specified attributes.

Download the configuration of your service into a file named service.yaml on local workspace:
```
gcloud run services describe SERVICE --format export > service.yaml
```
Replace SERVICE with the name of your Knative serving service.
In your local file, update the serviceAccountName: attribute:
```
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE
spec:
  template:
    spec:
      serviceAccountName: KSA_NAME
```
Replace
- SERVICE with the name of your Knative serving service.
- KSA_NAME with the Kubernetes Service Account that you used to create the workload identity.
Deploy the configuration to your Knative serving service by running the following command:
```
gcloud run services replace service.yaml
```

Migrating existing services to use Workload Identity Federation for GKE

If you enabled Workload Identity Federation for GKE on an existing cluster, each service on that cluster for which you want to use Workload Identity Federation for GKE must be migrated. Learn how to migrate existing services.

Next steps

Learn how to manage access to your services.