Apigee hybrid v.1.13 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.
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"
- Check that the current
gcloud
configuration is set to your Google Cloud project ID with the following command:gcloud config get project
- 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
andapigee-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
If needed, set the current gcloud
configuration:
gcloud config set project $PROJECT_ID
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 underNOTES:
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 underNOTES:
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 underNOTES:
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 underNOTES:
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.
Next steps
In the next step, you will configure the Apigee ingress gateway and deploy a proxy to test your installation.