Open hectoralicea opened 5 years ago
OSBA is a binary program. You can associate an MSI to a VM, a VMSS, and so on, but you can't associate an MSI to a binary program. This doc contains all services that support managed identities. Maybe it helps.
Unless OSBA is guaranteed to be scheduled on a fixed agent node, then you can associate an MSI to this node, and make OSBA access the MSI endpoint to get access token. However, this is not a typical usage so we don't have the plan to achieve it recently.
You can associate an MSI to all the nodes in a AKS cluster also, right? The issue is that right now I need a myriad of services principals and managed identities in my stack. I would like to reduce it to just one managed identity that can manage everything in a resource group and only require a person with a contrib access to that resource group to create and assign that managed identity to what ever is in the VM. Having to pull in the tenant owner of the account to create these service principals is really burdensome. If as a contributor I have the right to create and delete resources, that should include the right to create a managed identities that can manipulate things that I created.
If every node in the cluster is bound a user-assigned MSI, then this can be achieved. The use case sounds good to me. I'll schedule time to implement this. Thanks for the feedback!
I'd love to be able to use it with aad-pod-identity. It'd make it much easier to manage identity cleanup on cluster removal.
@norshtein is there any update on this?
RIght now it appears I need both managed identities and service principals to manage my kubernetes cluster. It would be nice if I can merge everything to use just managed identities since these show up in the resource group and not in the AAD.
Let me know what you think of this idea. Is this a good idea, or am I nuts.
The enhancement request is to allow managed identities object ids as inputs for the
azure.clientId
parameter