Enabling Workload Identity Federation on AKS and EKS

Version 1.12 keyboard_arrow_down

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:

Configure Apigee hybrid to use Workload Identity Federation

  1. 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.
  2. 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:

  3. 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 for all components):

    SAKEY=$(cat ./fwi/credential-configuration.json); kubectl -n apigee exec vault-0 -- vault kv patch secret/apigee/orgsakeys udca="$SAKEY"
  4. 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.