Keda: Provide support for AAD Pod Identity

[tomkerkhove]

Provide support for AAD Pod Identity to make it easier to authenticate to certain Azure workloads.

https://github.com/Azure/aad-pod-identity#getting-started

[tomkerkhove]

@jeffhollan I would consider this as required for v1.0

[jeffhollan]

Could this be used as a connection mechanism for the Service Bus scaler? Can I think of it like Managed Identities for Azure Resources, but in Kubernetes?

[tomkerkhove]

That is correct @jeffhollan - AAD Pod Identity allows you to assign AD Apps to Pods which will use MSI (concept)

This would allow us to connect to Azure Storage, Monitor, et al without using secrets.

[yaron2]

Important to note this only works for clusters running in Azure.

[tomkerkhove]

That's a good point, I was just reading about that.

Are there plans to support this kind of things via some sort of vendor plugins or so? It would be really good to be able to opt-in for this.

[yaron2]

Unfortunately its coupled to metadata coming from Azure VMs for aks/aks-engine.

[tomkerkhove]

This is decoupled from Keda by using the framework and handled by AAD Pod Identity for us, all we would need to do is provide the capability to choose to use ADAL instead.

[yaron2]

Yep.

[lee0c]

@jeffhollan This is something we will actually need for the current customer's setup to get to production. Having secrets stored on the cluster isn't doable for security reasons & all authentication & secret management is done with MSI. Is this on your radar as something that will be implemented?

[tomkerkhove]

I consider this a v1.0 requirement

[asavaritayal]

Capturing the discussion from standup - this shouldn't be a blocker but we'd like to align it with the v1.0 release in order to cater to multiple customer scenarios.

[lee0c]

To follow up from standup, it is a blocker in cases where there are enterprise security restrictions to keep in mind. Our customer case had very stringent security & would need their design to pass review (by people who may not be familiar with namespacing). In a scenario where the rest of the application is working through Pod ID, it is highly preferable to have KEDA fit that story to meet security expectations.

[lee0c]

@jeffhollan @anirudhgarg My next two weeks will be fairly busy but I'm willing to look into this & potentially put in a PR if you're alright with a bit of delay 😄

[tomkerkhove]

I fully agree, but I think we should not underestimate the impact of adding that because:

• How will the AD App be configured? Part of the KEDA deployment I presume?
• Will you enforce using that for all ScaledObjects that support Azure AD Auth, or will it be configurable on the ScaledObject?

[lee0c]

Not sure on the first question - I'm guessing that most if not all of the set up would be left to the user, since it's unlikely only KEDA would need that set up. To the second, I would assume it would be configurable - for any given ScaledObject you could choose to opt in to pod id & provide pod ID client details. I need to look into it more though!

[jeffhollan]

Yes @lee0c that would be awesome if you could help tackle. And to clarify thinking being this isn't a blocker to 1.0 (meaning it may come a little further down in the backlog from priority POV) but absolutely agree this feature would be a blocker for some customers adopting KEDA. So would be awesome to get some help to get this in even sooner than some of the other work items on @Aarthisk and others.

And yes I'm wondering if there could be some flag on the ScaledObject -- maybe at the metadata level -- to let it know to not look in secrets / env for the connectionString but rather leverage pod identity. We can't enforce it for all ScaledObjects because some like RabbitMQ, Redis, AWS SQS will never really support AAD Identity I imagine.

[patnaikshekhar]

@jeffhollan @lee0c @yaron2 I've created a pull request that includes new fields to support Azure AD Pod Identity for Azure Storage Queue.

[tomkerkhove]

Thanks for your PR @patnaikshekhar!

Before we move forward I'd love to challenge the suggestion to use metadata for indicating this as this is a more general concept than trigger concepts.

Would it make sense to introduce a section called trigger.authentication for this?

This would allow us to keep the trigger metadata purely on the trigger while the authentication node describes how to authenticate and allow users to define how and where it is.

Sample

apiVersion: keda.k8s.io/v1alpha1
kind: ScaledObject
metadata:
  name: azure-queue-po-id-scaledobject
  namespace: keda-aad-pod-id
  labels:
    deploymentName: keda-aad-pod-id
spec:
  scaleTargetRef:
    deploymentName: keda-aad-pod-id
  triggers:
  - type: azure-queue
    metadata:
      queueName: keda-test
      accountName: kedastoragequeuetest
      queueLength: "5"
    authentication:
      method: azureMsi | secret | env
      secretRef:
         name: my-keda-secret # only when method is 'secret'
      env:
         name: my-env-with-secret # only when method is 'env'
         containerName: my-container# only when method is 'env'

[patnaikshekhar]

@tomkerkhove I'm open to ideas :) That would mean a major change to the spec and I meant this to be more of a patch. If we plan to add an authentication section to the spec then we should probably bump up the API version as well. Maybe we should discuss this in the next Keda community meeting?

Current spec is

type ScaleTriggers struct {
    Type     string            `json:"type"`
    Name     string            `json:"name"`
    Metadata map[string]string `json:"metadata"`
}

[tomkerkhove]

I fully get why you used this route, I'm just wondering if that's the correct one.

KEDA is not in v1.0 stage so if we want to make breaking changes, now would be the good time for that imo.

Let's discuss in the standup next week.

[tomkerkhove]

In the last community standup, we've discussed to do a technical discussion on this feature.
If you want to participate, please fill in this Doodle which lists some proposed slots.

Please include your email address in the Doodle or write me at kerkhove.[email protected] so I can send the invite.

Depending on the availability we can add more slots, I think having @lee0c & @yaron2 is a must. Tagging @Aarthisk @ahmelsayed @anirudhgarg @izzymsft as they want to be part of it as well.

[jeffhollan]

Thanks @tomkerkhove - let me know if we have a slot now and I can help schedule too

[tomkerkhove]

Only 4 people filled it in already, would be good to have more people fill it in or need to add slots.

Tom Kerkhove
Azure Architect at Codit, Microsoft Azure MVP

---

From: Jeff Hollan [e-mail]
Sent: Thursday, July 18, 2019 7:14:25 PM
To: kedacore/keda
Cc: Tom Kerkhove; Mention
Subject: Re: [kedacore/keda] Provide support for AAD Pod Identity (#161)

Thanks @tomkerkhovehttps://github.com/tomkerkhove - let me know if we have a slot now and I can help schedule too

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/kedacore/keda/issues/161?email_source=notifications&email_token=ABBE6PYUW3ADB5AY2WPLOITQACQHDA5CNFSM4HLOVPPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2JFMFI#issuecomment-512906773, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABBE6P7BCQQGERWANANWCP3QACQHDANCNFSM4HLOVPPA.

[tomkerkhove]

The scaler spec changes are finalized and general info is surfaced via #331.

We should provide Pod Identity support for following scalers:

• Azure Event Hubs (#334)
• Azure Storage Queue (#335)
• Azure Service Bus Queue (#336)

[ahmelsayed]

Closing this issue as this is a per-scaler change