feat: Support for Azure AD Workload Identity

content/docs/2.7/concepts/authentication.md

@@ -92,7 +92,7 @@ metadata:
   namespace: default # must be same namespace as the ScaledObject
 spec:
   podIdentity:
-      provider: none | azure | aws-eks | aws-kiam       # Optional. Default: none
+      provider: none | azure | azure-workload | aws-eks | aws-kiam  # Optional. Default: none
   secretTargetRef:                                      # Optional.
   - parameter: {scaledObject-parameter-name}            # Required.
     name: {secret-name}                                 # Required.
@@ -116,7 +116,7 @@ spec:
       path: {hasicorp-vault-secret-path}                # Required.
   azureKeyVault:                                        # Optional.
     vaultURI: {key-vault-address}                       # Required.
-    credentials:                                        # Required.
+    credentials:                                        # Optional. Required when not using pod identity.
       clientId: {azure-ad-client-id}                    # Required.
       clientSecret:                                     # Required.
         valueFrom:                                      # Required.
@@ -128,10 +128,10 @@ spec:
       type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.
       keyVaultResourceURL: {key-vault-resource-url-for-cloud}         # Required when type = Private.
       activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}  # Required when type = Private.
-  secrets:                                              # Required.
-  - parameter: {param-name-used-for-auth}               # Required.
-    name: {key-vault-secret-name}                       # Required.
-    version: {key-vault-secret-version}                 # Optional.
+    secrets:                                            # Required.
+    - parameter: {param-name-used-for-auth}             # Required.
+      name: {key-vault-secret-name}                     # Required.
+      version: {key-vault-secret-version}               # Optional.
 ```
 
 Based on the requirements you can mix and match the reference types providers in order to configure all required parameters.
@@ -231,19 +231,20 @@ You can pull secrets from Azure Key Vault into the trigger by using the `azureKe
 
 The `secrets` list defines the mapping between the key vault secret and the authentication parameter.
 
-Users need to register an application with Azure Active Directory, and grant "read secret" permissions on the Azure Key Vault. Learn more in the Azure
-Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal).
+You can use pod identity providers `azure` or `azure-workload` to authenticate to the key vault by specifying it in the
+`TriggerAuthentication` / `ClusterTriggerAuthentication` definition.
+
+If you do not wish to use a pod identity provider, you need to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specify its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a secret on the cluster.
 
-The `clientId` and `tenantId` for the application
-are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a secret on the cluster.
+Ensure that "read secret" permissions have been granted to the managed identity / Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal).
 
 The `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like
 `Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds.
 
 ```yaml
 azureKeyVault:                                          # Optional.
   vaultURI: {key-vault-address}                         # Required.
-  credentials:                                          # Required.
+  credentials:                                          # Optional. Required when not using pod identity.
     clientId: {azure-ad-client-id}                      # Required.
     clientSecret:                                       # Required.
       valueFrom:                                        # Required.
@@ -269,22 +270,43 @@ Currently we support the following:
 
 ```yaml
 podIdentity:
-  provider: none | azure | aws-eks | aws-kiam  # Optional. Default: none
+  provider: none | azure | azure-workload | aws-eks | aws-kiam  # Optional. Default: none
 ```
 
 #### Azure Pod Identity
 
-Azure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which let's you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*.
+Azure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*.
 
 You can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`.
 
 ```yaml
 podIdentity:
-  provider: azure # Optional. Default: false
+  provider: azure # Optional. Default: none
 ```
 
 Azure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`.  You can set this label on the KEDA operator deployment.  This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`.
 
+#### Azure Workload Identity
+
+[**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an
+[**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals)
+without having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*.
+
+You can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`.
+
+```yaml
+podIdentity:
+  provider: azure-workload # Optional. Default: none
+```
+
+Azure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer
+to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the
+following flags -
+
+1. `--set podIdentity.azureWorkload.enabled=true`
+2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}`
+3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}`
+
 #### EKS Pod Identity Webhook for AWS
 
 [**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod.
@@ -293,7 +315,7 @@ You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.
 
 ```yaml
 podIdentity:
-  provider: aws-eks # Optional. Default: false
+  provider: aws-eks # Optional. Default: none
 ```
 
 #### Kiam Pod Identity for AWS
@@ -304,5 +326,5 @@ You can tell KEDA to use Kiam via `podIdentity.provider`.
 
 ```yaml
 podIdentity:
-  provider: aws-kiam # Optional. Default: false
+  provider: aws-kiam # Optional. Default: none
 ```

content/docs/2.7/scalers/azure-event-hub.md

@@ -26,6 +26,8 @@ triggers:
     endpointSuffix: servicebus.airgap.example
     # Required when cloud = Private.
     activeDirectoryEndpoint: https://login.airgap.example/
+    # Required when cloud = Private.
+    eventHubResourceURL: https://eventhubs.airgap.example/
 ```
 
 **Parameter list:**
@@ -43,6 +45,7 @@ triggers:
 - `cloud` - Name of the cloud environment that the Event Hub belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`, Default: `AzurePublicCloud`, Optional)
 - `endpointSuffix` - Service Bus endpoint suffix of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `servicebus.cloudapi.de` for `AzureGermanCloud`).
 - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.microsoftonline.de/` for `AzureGermanCloud`).
+- `eventHubResourceURL` - Event Hub resource URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://eventhubs.azure.net/` for known Azure Clouds).
 
 > 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour).