GKE with Workload Identity only: Configure Workload Identity

Follow these steps if you set up your overrides file for Workload Identity on GKE inStep 6: Create the overrides.

If you are not using Workload Identity on GKE, proceed toPart 3, Step 1: Expose Apigee ingress gateway.

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, seeService accounts overview.

You created Google Cloud service accounts for your Apigee hybrid installation inStep 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, seeConfigure Service Accounts for Pods.

If you havegcp.workloadIdentity.enabled set totrue 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 inStep 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.

1. 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 fromapigeectl management with theApigee hybrid Helm migration tool, the overrides syntax for Workload Identity will have changed. You will need to check the following.
   • namespace is required. For example:

     instanceID: "hybrid-instance-1"namespace: "apigee"

   • The syntax to enable Workload Identity is different for Helm than forapigeectl. For Helm,gcp.workloadIdentity.enabled replacesgcp.workloadIdentityEnabled.
   • 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'sgsa property. For example:

       logger:    gsa: "apigee-logger@my-hybrid-project.iam.gserviceaccount.com"

   See:gcp.workloadIdentity.enabled.

2. Check that the currentgcloud configuration is set to your Google Cloud project ID with the following command:

   gcloud config get project

If needed, set the currentgcloud configuration:

gcloud config set project $PROJECT_ID

3. Verify that Workload Identity is enabled for your GKE Cluster. When you created the cluster inStep 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 seenull 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

4. 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 updateNODE_POOL_NAME \  --cluster=$CLUSTER_NAME \  --region $CLUSTER_LOCATION \  --project $PROJECT_ID \  --workload-metadata=GKE_METADATA

   Zonal clusters

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

   WhereNODE_POOL_NAME is the name of each node pool. In most Apigee hybrid installations, the two default node pools are namedapigee-data andapigee-runtime.

5. 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: 100diskType: 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 thehelm upgrade with the--dry-run flag for theapigee-datastore,apigee-env,apigee-org, andapigee-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 \  -foverrides.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

1. Get the command to set up Workload Identity forapigee-datastore and run the command underNOTES: in the output.

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

2. Get the commands to set up Workload Identity forapigee-telemetry and run the command underNOTES: in the output.

   helm upgrade telemetry apigee-telemetry/ \  --namespace $NAMESPACE \  -foverrides.yaml \  --dry-run

3. Get the commands to set up Workload Identity forapigee-org and run the command underNOTES: in the output.

   helm upgrade$ORG_NAME apigee-org/ \  --namespace $NAMESPACE \  -foverrides.yaml \  --dry-run

4. Get the commands to set up Workload Identity forapigee-env and run the command underNOTES: in the output.

   helm upgrade$ENV_NAME apigee-env/ \  --namespace $NAMESPACE \  --set env=ENV_NAME \  -foverrides.yaml \  --dry-run

   Repeat this step for each environment in your installation.

5. (Optional) You can see the status of your Kubernetes service accounts in theKubernetes: Workloads Overview page in the Google Cloud console.

   Go to Workloads

   Note: You may see an error status for theapigee-cassandra-backup andapigee-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, seefeedbackCassandra backup overview.

Next steps

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