aad-pod-identity
aad-pod-identity copied to clipboard
Azure
Enable AzureIdentity binding via annotation
Describe the request Enable a way for an identity binding to be expressed as an annotation.
Explain why AAD Pod Identity needs it
In my particular case I am deploying the external-dns chart and need to associate an AzureIdentity with the pod it creates. It communicates with Azure to update DnsZone recordsets.
The external-dns chart provides a way to add additional annotations, but it does not provide a way to add entirely new objects like an AzureIdentityBinding and does not provide a way to add additional, specific labels.
This specific example does apply in general to most charts. Stable charts typically offer a way to add any number of additional podAnnotations to the deployments, daemonsets, etc. See also. One reason for that is exactly this scenarion: to enable the chart consumer to create associations between the objects being created and arbitrary cluster addons.
For example, if you have the cert-manager addon, it will look for annotations on Ingress objects in order to associate the ingress with a ClusterIssuer or Issuer object.
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
# add an annotation indicating the issuer to use.
certmanager.k8s.io/cluster-issuer: nameOfClusterIssuer
name: myIngress
namespace: myAppNamespace
...
Describe the solution you'd like I would like MIC and NMI to discover a pod annotation that creates the association with an existing AzureIdentity object without requiring an AzureIdentityBinding to be created.
apiVersion: extensions/v1beta1
kind: Pod
metadata:
annotations:
# add an annotation indicating the identity to use.
aadpodidentity.k8s.io/azure-identity: nameOfAzureIdentity
name: myDeployment
namespace: myAppNamespace
...
Describe alternatives you've considered There is also a PR which enables an AzureIdentityBinding to use name-value label selectors instead of a predefined label key. That would also work - however it would still leave the problem of creating an AzureIdentityBinding with the correct labels for every 3rd party system that will be deployed.
It would be much cleaner to create only AzureIdentity objects upfront, and then later have the binding associations controlled entirely by the annotations that the are part of the service chart deployment.
Another alternative would be to fork the standard external-dns chart and add an AzureIdentityBinding to the templates it contains. That would be unfortunate because it would become an external code dependency and upstream changes would need to be merged periodically.
Additional context
@kkmsft Maybe :) I'll ping you next week to learn more about how it should be done
Can you share the details publicly so non-MSFT personnel can jump on this?
We are not adding any net new feature or breaking changes to this project as we are working on the next iteration of pod identity. We hope to open-source it within this year.
@chewong can you share any link to a new iteration? Where can I look at this?
It's going to be available and open-source soon. We will keep everyone posted in this repository's README.
I feel the standard way to overlay functions on pods should be through pod annotation.
