Enabling Workload Identity Federation on AKS and EKS

This topic explains how to enable Workload Identity for Apigee hybrid installations on AKS and EKS platforms.

Overview

Workload identity federation lets applications running outside Google Cloud impersonate a Google Cloud Platform service account by using credentials from an external identity provider.

Using workload identity federation can help you improve security by letting applications use the authentication mechanisms that the external environment provides and can help replace service account keys.

For an overview, see Best practices for using Workload Identity Federation.

Set up Workload Identity Federation

To use Workload Identity Federation with Apigee hybrid, first configure you cluster and then apply the feature to your Apigee hybrid installation.

Configure your cluster to use Workload Identity Federation.

Follow the Google Cloud instructions to Configure Workload Identity Federation for Kubernetes, with the following modifications:

In the step Configure Workload Identity Federation, the default audience for created Workload Identity pools and providers is as follows. Use this default or set a custom expected audience, and save this value for later use.
```
https://iam.googleapis.com/projects/PROJECT_NUM/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID
```
You should not need to perform the steps under Create a pair of service accounts, because the service accounts you will need should already have been created:
- IAM service accounts: You most likely have already created the IAM service accounts (also called "Google service accounts") during initial installation of Apigee hybrid with the create-service-account tool. See About service accounts for a list of IAM service accounts needed by Apigee hybrid.
  You can see a list of IAM service accounts in your project with the following command:
```
gcloud iam service-accounts list --project PROJECT_ID
```
- Kubernetes service accounts: The Apigee hybrid charts create the necessary Kubernetes service accounts for each component when you run the helm install or helm update command.
  You can see the Kubernetes service accounts in your cluster with the kubectl get sa commands:
```
kubectl get sa -n APIGEE_NAMESPACE
kubectl get sa -n apigee-system
```
Stop after step 1 under Deploy a Kubernetes workload. Save the credential configuration file and save the path entered for the --credential-source-file parameter, for example: /var/run/service-account/token.
Note: You can also find the values for audience and credentialSourceFile in the credential configuration json file, under the paths .audience and .credential_source.file respectively. You will need these values for the overrides file to configure Apigee hybrid.

Configure Apigee hybrid to use Workload Identity Federation

Copy the credential source file and the output file (credential-configuration.json) into the following chart directories. These were the values you provided in step 1 under Deploy a Kubernetes workload.
- apigee-datastore/
- apigee-env
- apigee-org/
- apigee-telemetry/
Tip: You can use a subdirectory for these files, for example: apigee-datastore/fwi/
Make the following global changes to your cluster's overrides file:
```
gcp:
  workloadIdentity:
    enabled: false # must be set to false to use Workload Identity Federation
  federatedWorkloadIdentity:
    enabled: true
    audience: "AUDIENCE"
    credentialSourceFile: "CREDENTIAL_SOURCE_FILE"
```
Where:
- AUDIENCE is the allowed audience of the Workload Identity Provider, the value under .audience in the credential configuration json file you configured in step 1 under Deploy a Kubernetes workload.
- CREDENTIAL_SOURCE_FILE is the filename and path to the credential source file used by Workload Identity Federation to obtain the credentials for the service accounts. This is the value you provide for credential-source-file when you configure Workload Identity Federation with the create-cred-config command in Sstep 1 under Deploy a Kubernetes workload. For example:
Configure the overrides for each component using Workload Identity Federation. Select the instructions for cert files, Kubernetes secrets, or Vault as appropriate for your installation. <
Cert file

Replace the value of serviceAccountPath with the credential source file. This must be the path relative to the chart directory. For example:
```
udca:
  serviceAccountPath: fwi/credential-configuration.json
```
K8s Secret
1. Create a new Kubernetes secret using for the credential source file.
```
kubectl create secret -n apigee generic SECRET_NAME --from-file="client_secret.json=CREDENTIAL_CONFIGURATION_FILE"
```
  For example:
```
kubectl create secret -n apigee generic udca-fwi-secret --from-file="client_secret.json=./fwi/credential-configuration.json"
```
2. Replace the value of serviceAccountRef with the new secret. For example:
```
udca:
  serviceAccountRef: udca-fwi-secret
```
Vault

Update the service account key, SAKEY in Vault with the credential source file. For example, for UDCA (the procedure is similar foe all components):
```
SAKEY=$(cat ./fwi/credential-configuration.json); kubectl -n apigee exec vault-0 -- vault kv patch secret/apigee/orgsakeys udca="$SAKEY"
```

Apply the changes to each affected component with the helm update command:

If you are using Vault for the first time with this cluster, update the apigee-operator chart:

helm upgrade operator apigee-operator/ \
  --namespace apigee-system \
  --atomic \
  -f overrides.yaml

Update the rest of the affected charts in the following order:

helm upgrade datastore apigee-datastore/ \
  --namespace apigee \
  --atomic \
  -f overrides.yaml

helm upgrade telemetry apigee-telemetry/ \
  --namespace apigee \
  --atomic \
  -f overrides.yaml

helm upgrade $ORG_NAME apigee-org/ \
  --namespace apigee \
  --atomic \
  -f overrides.yaml

Update the apigee-env chart for each env, replacing ENV_NAME each time:

helm upgrade $ENV_NAME apigee-env/ \
  --namespace apigee \
  --atomic \
  --set env=$ENV_NAME \
  -f overrides.yaml

See the Apigee hybrid Helm reference for a list of components and their corresponding charts.

For more information about Workload Identity Federation and best practices, see Best practices for using workload identity federation.