Step 12 (Optional): Configure Workload Identity

Apigee hybrid v.1.12 supports Workload Identity on GKE and Workload Identity Federation on AKS and EKS. The procedures in this guide only cover configuring Workload Identity on GKE. For AKS and EKS, follow the procedures in Enabling Workload Identity Federation on AKS and EKS

Configure Workload Identity on GKE

Google Cloud service accounts and Kubernetes service accounts

A Google Cloud service account is a special kind of account that can be used to make authorized API calls by authenticating as the service account itself. Google Cloud service accounts can be given roles and permissions similar to an individual user. When an application authenticates as a service account, it has access to all resources that the service account has permission to access. If you want to learn more about Google Cloud service accounts, see Service accounts overview.

You created Google Cloud service accounts for your Apigee hybrid installation in Step 4: Create service accounts. Apigee uses these service accounts to authenticate the hybrid components.

Kubernetes service accounts are similar to Google Cloud service accounts. A Kubernetes service account provides an identity for processes that run in a Pod, and allows it to authenticate to the API server similarly to a user. If you want to learn more about Kubernetes service accounts, see Configure Service Accounts for Pods.

If you have gcp.workloadIdentity.enabled set to true in your overrides file, when Helm charts for each hybrid component will create the Kubernetes service accounts for the components when you install or upgrade them like you did in Step 11: Install Apigee hybrid using Helm charts.

When you configure Workload Identity on GKE, you associate the Google Cloud service accounts with the Kubernetes service accounts in the Kubernetes cluster. That way, the Kubernetes service accounts can impersonate the Google Cloud service accounts and use their assigned roles and permissions to authenticate with the hybrid components.

Follow these instructions to configure Workload Identity for your project.

Prepare to configure Workload Identity

Verify that Workload Identity is enabled in your overrides file. It should be enabled at the overrides file in the following properties.
Note: If you migrated your cluster from apigeectl management with the Apigee hybrid Helm migration tool, the overrides syntax for Workload Identity will have changed. The syntax to enable Workload Identity is different: gcp.workloadIdentity.enabled replaces gcp.workloadIdentityEnabled.You will need to check the following.
- namespace is required. For example:
```
instanceID: "hybrid-instance-1"
namespace: "apigee"
```
- If you are using a single service account (Non-prod) for all components, specify it with: gcp.workloadIdentity.gsa. For example:
```
  gcp:
    workloadIdentity:
      enabled: true
      gsa: "apigee-non-prod@my-hybrid-project.iam.gserviceaccount.com"
  
```
- If you are using a separate service account for each component (Prod installations), specify the service account with the component's gsa property. For example:
```
  logger:
    gsa: "apigee-logger@my-hybrid-project.iam.gserviceaccount.com"
  
```
See: gcp.workloadIdentity.enabled.
Check that the current gcloud configuration is set to your Google Cloud project ID with the following command:
```
gcloud config get project
```

If needed, set the current gcloud configuration:

gcloud config set project $PROJECT_ID

Verify that Workload Identity is enabled for your GKE Cluster. When you created the cluster in Step 1: Create a cluster, step 6 was to Enable Workload Identity. You can confirm if Workload Identity is enabled by running the following command:

Regional clusters

gcloud container clusters describe $CLUSTER_NAME \
  --region $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --flatten 'workloadIdentityConfig'

Zonal clusters

gcloud container clusters describe $CLUSTER_NAME \
  --zone $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --flatten 'workloadIdentityConfig'

Your output should look like the following:

  ---
  workloadPool: PROJECT_ID.svc.id.goog

If you see null instead in your results, run the following command to enable Workload Identity for your cluster:

Regional clusters

gcloud container clusters update $CLUSTER_NAME \
  --workload-pool=$PROJECT_ID.svc.id.goog \
  --project $PROJECT_ID \
  --region $CLUSTER_LOCATION

Zonal clusters

gcloud container clusters update  $CLUSTER_NAME \
  --workload-pool=$PROJECT_ID.svc.id.goog \
  --zone $CLUSTER_LOCATION \
  --project $PROJECT_ID

Enable Workload Identity for each node pool with the following commands. This operation can take up to 30 minutes for each node:

Regional clusters

gcloud container node-pools update NODE_POOL_NAME \
  --cluster=$CLUSTER_NAME \
  --region $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --workload-metadata=GKE_METADATA

Zonal clusters

gcloud container node-pools update NODE_POOL_NAME \
  --cluster=$CLUSTER_NAME \
  --zone $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --workload-metadata=GKE_METADATA

Where NODE_POOL_NAME is the name of each node pool. In most Apigee hybrid installations, the two default node pools are named apigee-data and apigee-runtime.

Verify that Workload Identity is enabled on your node pools with the following commands:

Regional clusters

gcloud container node-pools describe apigee-data \
  --cluster $CLUSTER_NAME \
  --region $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --flatten "config:"

gcloud container node-pools describe apigee-runtime \
  --cluster $CLUSTER_NAME \
  --region $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --flatten "config:"

Zonal clusters

gcloud container node-pools describe apigee-data \
  --cluster $CLUSTER_NAME \
  --zone $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --flatten "config:"

gcloud container node-pools describe apigee-runtime \
  --cluster $CLUSTER_NAME \
  --zone $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --flatten "config:"

Your output should look something like:

---
diskSizeGb: 100
diskType: pd-standard
...
workloadMetadataConfig:
  mode: GKE_METADATA

Configure Workload Identity

Use the following procedure to enable Workload Identity for the following Hybrid components:

apigee-datastore
apigee-telemetry
apigee-org
apigee-env

When you run the helm upgrade with the --dry-run flag for the apigee-datastore, apigee-env, apigee-org, and apigee-telemetry charts, the output will include the commands you will need to configure Workload Identity with the correct GSA and KSA names.

For example:

helm upgrade datastore apigee-datastore/ \
  --namespace $NAMESPACE \
  -f overrides.yaml \
  --dry-run

NAME: datastore
  ...
For C* backup GKE Workload Identity, please make sure to add the below membership to the IAM policy binding using the respective kubernetes SA (KSA).
  gcloud iam service-accounts add-iam-policy-binding  \
        --role roles/iam.workloadIdentityUser \
        --member "serviceAccount:my-project.svc.id.goog[apigee/apigee-cassandra-backup-sa]" \
        --project :my-project

Get the command to set up Workload Identity for apigee-datastore and run the command under NOTES: in the output.
```
helm upgrade datastore apigee-datastore/ \
  --namespace $NAMESPACE \
  -f overrides.yaml \
  --dry-run
```
Get the commands to set up Workload Identity for apigee-telemetry and run the command under NOTES: in the output.
```
helm upgrade telemetry apigee-telemetry/ \
  --namespace $NAMESPACE \
  -f overrides.yaml \
  --dry-run
```
Get the commands to set up Workload Identity for apigee-org and run the command under NOTES: in the output.
```
helm upgrade $ORG_NAME apigee-org/ \
  --namespace $NAMESPACE \
  -f overrides.yaml \
  --dry-run
```
Get the commands to set up Workload Identity for apigee-env and run the command under NOTES: in the output.
```
helm upgrade $ENV_NAME apigee-env/ \
  --namespace $NAMESPACE \
  --set env=ENV_NAME \
  -f overrides.yaml \
  --dry-run
```
Repeat this step for each environment in your installation.
(Optional) You can see the status of your Kubernetes service accounts in the Kubernetes: Workloads Overview page in the Google Cloud Console.
Go to Workloads

Note: You may see an error status for the apigee-cassandra-backup and apigee-cassandra-restore service accounts. This is because you are not currently running backup or restore, and these processes have not been fully configured yet. For more information on Cassandra backup and restore, see feedbackCassandra backup overview.

Next steps

In the next step, you will configure the Apigee ingress gateway and deploy a proxy to test your installation.

Next step

(NEXT) Step 1: Expose Apigee ingress 2