So KubeDB provisioner is responsible to pull images from the registry. In our AKS cluster this would be our private registry, which is configured to only accept Azure Active Directory authentication - one cannot use user/password authentication.
We setup federated identity credentials for the namespace service account and we have the respective Azure AD Identity associated with it. The framework that allows this is Azure Workload Identity.
Assuming the federated identity credentials and the azure identity itself already exist, the following steps must be taken to enable it for the KubeDB provisioner pod:
The KubeDB provisioner pod must have the label azure.workload.identity/use: "true"
The KubeDB namespace service account must have the name recorded in the federated identity credentials subject
The KubeDB namespace service account must have the annotation azure.workload.identity/client-id: <azure identity client id>
Now, the service account name is not an issue - we can create the federated identity credentials with any name as needed. Custom annotation is not a problem either, since the kubedb-provisioner chart allows to customize annotations.
The problem is the custom label. It seems that KubeDB charts make a deliberate decision NOT to allow custom labels on the objects they create.
I am sure there is some K8s best practice behind it, but what can be done when it is absolutely necessary to add a label to a KubeDB pod?
To complicate things a little bit more, we deploy all the apps using ArgoCD. So if I use some kind of out-of-band "labeller" (do not know if that exists at all) it would be at odds with ArgoCD. I will have to instruct the latter to ignore the differences in labels, which is doable, but not ideal.
What is the best way to add custom labels to the KubeDB pods given that their helm charts do not support it and that we use ArgoCD to deploy it?
I also asked the question on SO - https://stackoverflow.com/questions/78908068/kubedb-provisioner-and-azure-workload-identity
So KubeDB provisioner is responsible to pull images from the registry. In our AKS cluster this would be our private registry, which is configured to only accept Azure Active Directory authentication - one cannot use user/password authentication.
We setup federated identity credentials for the namespace service account and we have the respective Azure AD Identity associated with it. The framework that allows this is Azure Workload Identity.
Assuming the federated identity credentials and the azure identity itself already exist, the following steps must be taken to enable it for the KubeDB provisioner pod:
azure.workload.identity/use: "true"azure.workload.identity/client-id: <azure identity client id>Now, the service account name is not an issue - we can create the federated identity credentials with any name as needed. Custom annotation is not a problem either, since the kubedb-provisioner chart allows to customize annotations.
The problem is the custom label. It seems that KubeDB charts make a deliberate decision NOT to allow custom labels on the objects they create.
I am sure there is some K8s best practice behind it, but what can be done when it is absolutely necessary to add a label to a KubeDB pod?
To complicate things a little bit more, we deploy all the apps using ArgoCD. So if I use some kind of out-of-band "labeller" (do not know if that exists at all) it would be at odds with ArgoCD. I will have to instruct the latter to ignore the differences in labels, which is doable, but not ideal.
What is the best way to add custom labels to the KubeDB pods given that their helm charts do not support it and that we use ArgoCD to deploy it?