Provide support for using Azure AD service principal authentication with client secret/certificate

[Aashish93-stack]

Proposal

Proposing the following updates:

• Add a provider for azure service principal
• Update the AuthPodIdentity, triggerAuthentication to take in a ClientID, Audience and Secret
• Adding mechanism to load the base64 decoded Kubernetes secret
• Adding a mechanism to decode the certificate and get the AadToken

Use-Case

We have a use case where we need to support System Assigned Identity for accessing eventhub and since PodIdentity and Workload Identities don't support System-Assigned Identity out of box, we are looking into service-principal based authentication using certificates

Anything else?

No response

[Aashish93-stack]

I'd be happy to contribute this feature to the project.

[JorTurFer]

Hi @Aashish93-stack
You can use Workload Identities with the service principal, doesn't it solve your problem?
I mean, if you already have a service principal, you can federate it with the cluster and use Workload Identity using that service principal without any secret/certificate

[Aashish93-stack]

@JorTurFer unfortunately, there are some use cases where we don't have access to the service principal to configure federation and other cases where users don't won't to onboard the workload-identity, so we are hoping to add a certificate based authentication to cover all our bases

[tomkerkhove]

Yes, this is another way of authenticating.

I think service principal support makes sense but I'd suggest to post a configuration proposal here first to make sure we are all aligned first.

Is that OK for you @Aashish93-stack?

[JorTurFer]

Agreed with @tomkerkhove

BTW, There is also the option of using User Managed Identities if you need them as WI already supports them

[tomkerkhove]

BUt then you still need Workload Identity :) In some scenarios you just want to use a SP.

[Aashish93-stack]

@tomkerkhove sure that works for me.

Under the triggerAunthentication I was thinking of adding a provider azure-service-principal and it would have the following structure

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: {trigger-authentication-name}
  namespace: {trigger-authentication-namespace}
spec:
  podIdentity:
     provider: azure-service-principal
     clientId: {{UUID}}
     tenantId: {{UUID}}
     audience: {{audience}}
 secretTargetRef:               #Optional: Required when using azureServicePrincipal and not Secret from Azure KeyVault
    - parameter: {{secretRef}}
      name: {{secret-name}}
      key: {secret-key-name}
 azureKeyVault:                #Optional: Required when using azureServicePrincipal and not referencing Secret from Kubernetes                 
      vaultURI: {key-vault-address}                                        
      credentials:                                                          
          clientId: {azure-ad-client-id}                                      
          clientSecret:                                                       
             valueFrom:                                                        
                secretKeyRef:                                                   
                   name: {k8s-secret-with-azure-ad-secret}                       
                   key: {key-within-the-secret}                                  
          tenantId: {azure-ad-tenant-id}   

I was thinking that the certificate can imported from a Kubernetes secret or Azure Key Vault, so when specifying the provider as azureServicePrincipal we would also need either the secretTargetRef or azureKeyVault.

Then in the triggerauthentication_types add a new const

const (
	PodIdentityProviderAzureServicePrincipal PodIdentityProvider = "azure-service-principal" // New const for service-principal
	PodIdentityProviderNone                          PodIdentityProvider = "none"
	PodIdentityProviderAzure                          PodIdentityProvider = "azure"
	PodIdentityProviderAzureWorkload          PodIdentityProvider = "azure-workload"
	PodIdentityProviderGCP                            PodIdentityProvider = "gcp"
	PodIdentityProviderSpiffe                         PodIdentityProvider = "spiffe"
	PodIdentityProviderAwsEKS                      PodIdentityProvider = "aws-eks"
	PodIdentityProviderAwsKiam                    PodIdentityProvider = "aws-kiam"
)

and update the AuthPodIdentity struct with new optional fields

type AuthPodIdentity struct {
	Provider PodIdentityProvider `json:"provider"`
	// +optional
	IdentityID string `json:"identityId"`
	// +optional
	ClientID string `json:"clientId"`
	// +optional
	Audience string `json:"audience"`
	// +optional
	TenantID string `json:"tenantId"`
}

Also, we need to create a new class (could be name azure_aad_service_principal.go) which would be responsible to for decoding the certificate and getting the servicePrincipalToken, this would be called from the individual scalers. In case of EventHubScaler, after getting the servicePrincipalToken, a new JWTProvider needs to be configured and passed in the while creating a new eventhub client

[JorTurFer]

I wouldn't add this as a new pod identity because it isn't. Maybe we could add another section like azureServicePrincipal or something like that. WDYT?

[Aashish93-stack]

Yes, that makes sense, updating trigger auth structure to this ->

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: {trigger-authentication-name}
  namespace: {trigger-authentication-namespace}
spec:
  azureServicePrincipal:
     clientId: {{UUID}}
     tenantId: {{UUID}}
     audience: {{audience}}
 secretTargetRef:               #Optional: Required when using azureServicePrincipal and not Secret from Azure KeyVault
    - parameter: {{secretRef}}
      name: {{secret-name}}
      key: {secret-key-name}
 azureKeyVault:                #Optional: Required when using azureServicePrincipal and not referencing Secret from Kubernetes                 
      vaultURI: {key-vault-address}                                        
      credentials:                                                          
          clientId: {azure-ad-client-id}                                      
          clientSecret:                                                       
             valueFrom:                                                        
                secretKeyRef:                                                   
                   name: {k8s-secret-with-azure-ad-secret}                       
                   key: {key-within-the-secret}                                  
          tenantId: {azure-ad-tenant-id}   

and will add a new struct in the triggerauthentication_types

type AzureServicePrincipal struct {
	ClientID string `json:"clientId"`
	// +optional
	TenantID string `json:"tenantId"`
	// +optional
	Audience string `json:"audience"`
}

Since it's no longer part of the PodIdentity, was thinking of adding a AzureServicePrincipalHandler which can be used for decoding the certificate and returning the ServicePrincipalToken and this can be called by the new if block for triggerAuthSpec.AzureServicePrincipal in resolveAuthRef function under scale_resolvers.go and store the token in the authParams map, which can then be used by the individual scalers. Does this look good ?

[JorTurFer]

WDYT @v-shenoy ?