KEDA Trigger Authentication with Azure Service Principal

Question

Does KEDA support azure service principal(client id and secret)? I read through the documentation but could not find an example. The documentation did mentioned service principal for key vault but my understanding is that the service principal here is to authenticate to key vault then read the secrets from there.

Answer 1

KEDA supports Azure service principal authentication. You can use Azure service principal (client ID and secret) to authenticate to Azure Key Vault and read secrets from there. You can then use these secrets to authenticate to other Azure services, including KEDA. Once you have authenticated to Azure Key Vault, you can use the secrets to authenticate to KEDA. Here's an example of how to authenticate to Azure Kubernetes Service (AKS) using Azure service principal

To set up Azure service principal authentication for KEDA, Create the Service Principal using CLI or portal and get the appId (client ID) and password (client secret) and tenant

az ad sp create-for-rbac --name arkokedaServicePrincipal

Assign the necessary permissions to the service principal for the Azure resource you intend to monitor with KEDA.

az role assignment create --assignee <appId> --role <role> --scope <scope>

Here replace <appId>, <role>, and <scope> with the values you recieved from the first step.

or if creating a fresh resource like AKS cluster then directly push it while creating the cluster

az aks create \ --resource-group myResourceGroup \ --name myAKSCluster \ --service-principal  <appId> \ --client-secret  <password>

Store Service Principal Credentials i.e. the service principal's appId and password in a Kubernetes secret. Replace <client-id> and <client-secret> with your values.

kubectl create secret generic my-keda-secret --from-literal=AzureClientID="de471dbf-XXX-XX-XX-XX" --from-literal=AzureClientSecret="XXX~L4HVPmZ-XX7Xzx" --from-literal=AzureServiceBusConnection="Endpoint=sb://kedacluster.servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=XXXXXX6wrr/CIc3iBQXXX+AXXXM="

Make sure you have already installed Keda on your system helm install keda kedacore/keda --namespace

Finally configure KEDA to use the Service Principal

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: my-scaled-object
spec:
  scaleTargetRef:
    name: productpage-v1
  triggers:
    - type: azure-servicebus
      metadata:
        queueName: kedaqueue
        connectionFromEnv: AzureServiceBusConnection
  authenticationRef:
    name: keda-trigger-auth-service-bus

Here replace the productpage-v1 with your own deployment which you want to scale with keda- and kedaqueue with your own service bus queue name

Create a TriggerAuthentication YAML to accompany the ScaledObject, since you also need a TriggerAuthentication resource to refer to the secret holding the service principal's credentials.

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: keda-trigger-auth-service-bus
spec:
  secretTargetRef:
    - parameter: connection
      name: my-keda-secret
      key: AzureClientID
    - parameter: connection
      name: my-keda-secret
      key: AzureClientSecret

apply them with kubectl apply -f

Now you can monitor Keda for autoscaling events- kubectl logs -f deployment/keda-operator -n <namespace>

kubectl get deploy -w

Reference Documents:

• Azure Key Vault developer's guide
• Use a service principal with Azure Kubernetes Service (AKS)
• Similar SO Thread
• KEDA KV Secret
• KEDA Authentication with example