Aad-pod-identity: MSI bindings - get client and resource ID from secrets

[ThomasSchoenbeck]

Hi, i am wondering if there will be a way to reference client and resource ID inside an AzureIdentity from Kubernetes Secrets?

Much like the example aadpodidentity-sp.yaml for using Service Principals as seen below

Service Principal Example

apiVersion: v1
kind: Secret
metadata:
  name: demo-aad1-sp
type: Opaque
data:
  ClientSecret: CLIENT_SECRET
---
apiVersion: "aadpodidentity.k8s.io/v1"
kind: AzureIdentity
metadata:
  name: demo-aad1
spec:
  type: 1
  TenantID: TENANT_ID
  ClientID: CLIENT_ID
  ClientPassword: {"Name":"demo-aad1-sp","Namespace":"default"}

Idea for referencing values from secrets

apiVersion: "aadpodidentity.k8s.io/v1"
kind: AzureIdentity
metadata:
  name: demo-aad1
spec:
  type: 0
  ResourceID: {"Name":"demo-aad1-resource","Namespace":"product"}
  ClientID: {"Name":"demo-aad1-client","Namespace":"product"}

[aramase]

@ThomasSchoenbeck Currently, there are no plans to support that.

Curious why you prefer this over the current approach?

[cwoolum]

This would be helpful for me. I can give a use case.

I deploy my AKS cluster, Managed Identities, and all resources for my services using Terraform.

To deploy my actual services to our AKS cluster, we use a GitOps flow. The downside is that with the current configuration, we need to update all of the templates to deploy to a new cluster. Since Terraform owns the creation of the resources, I could easily create secrets with the Resource and Client Ids when the cluster and identities are created. That way when Flux picks up the app configuration, the latest config is already in place.

[RTodorov]

Hello there,

I second the OP and @cwoolum here. My scenario is very similar to his (Terraform + GitOps with flux). I'm pushing the Client ID to the cluster as a Secret and I just found out I cannot reference it in the AzureIdentity resource.

It would be very useful if we could specify both Client ID and Resource ID as Kubernetes secrets @aramase .

[cwoolum]

Would you take a PR on this? I might have time to work on it.

[RTodorov]

Hello folks,

Could we get an update on this issue? It seems like a relatively easy change but it would be nice to understand if you're willing to accept it (so someone can open in a PR, either @cwoolum or myself) or if this is something you'd reject.

Thank you @aramase

[chewong]

Following up with @cwoolum to see if #638 is ready for review.

[chewong]

Hey @cwoolum @RTodorov. Instead of referencing Client ID and Resource ID as secrets, have you checked out https://www.hashicorp.com/blog/deploy-any-resource-with-the-new-kubernetes-provider-for-hashicorp-terraform/?

On a side note, the reason why we reference ClientPassword as a secret is that it's sensitive information and saving it as a secret ensures that it's not exposed. I would argue that Client ID and Resource ID aren't sensitive and having two ways to create AzureIdentity (using clientID + resourceID and clientIDSecretRef + resourceIDSecretRef) could confuse users. Please let me know what you think.

[cwoolum]

We use flux for deploying all of our services and their associated Kubernetes resources so the Kubernetes Terraform provider wouldn't work for that. In fact, aad-pod-identity is deployed by flux as well so the CRD wouldn't even exist until flux first spins up and synchronizes. I really wouldn't want to introduce a process that has an asynchronous dependency. By having it just as a simple Secret or ConfigMap, we keep those deployments decoupled.

I feel like *SecretRef is a pretty straight forward but I wrote it haha. Thinking about it, they really are not secrets so they could just be in a ConfigMap.

[chewong]

Hey folks, after some discussion, we've decided not to support this feature at the moment because of the following reasons:

1) we currently don't offer official supports for aad-pod-identity + Terraform;
2) it's not a frequently-requested feature;
3) potential confusion to users and implementation complexity if we introduce multiple ways to create AzureIdentity and AzureIdentityBinding (e.g. we will have to take care of precendence - what if the user defines all of clientID + resourceID + clientIDSecretRef + resourceIDSecretRef when creating AzureIdentity?)

However, if we have more users onboarding to aad-pod-identity with Terraform in the future, we will definitely re-consider this feature again.

[julie-ng]

How about Terraform + Environment Variables + Makefiles?

Sharing in case this is helpful to others @ThomasSchoenbeck @cwoolum

I've been playing around with using Terraform to spin up an AKS cluster with some "secure defaults", incl. AAD Pod identity. And here is how I've approached it

• Terraform creates AKS cluster with azurerm_kubernetes_cluster provider
• Terraform installs aad-pod-identity with helm_release provider
• Get resource and client IDs via terraform output
• Use these in environment variables in YAML files

The Makefile looks something like this:

.EXPORT_ALL_VARIABLES:

MI_CLIENT_ID=$(shell terraform output managed_pod_identity_client_id)
MI_RESOURCE_ID=$(shell terraform output managed_pod_identity_resource_id)

preview:
    cat pod-identity.yaml | envsubst

apply:
    cat pod-identity.yaml | envsubst | kubectl apply -f -

There's no need to put the reference IDs as secrets. And because the variables are set in the Makefile, they only exist in the child process, so I don't need to pollute my own session.

Any thoughts about this approach?

[cwoolum]

Aaah, that is a very intriguing approach! I might be able to do something similar where I'm able to update my Git Repo that has my identity configs from Terraform using something similar!

Thanks for an alternative viewpoint! I'll see if I can make that work.

[gregberns]

I am onboarding to AKS and using Terraform for all infrastructure. aad-pod-identity is a part of the infrastructure that I'd like to bake in to the Terraform process - its distinctly separate from application deployment. Though I'm only on day two of looking at this project, from what I see now it would be really helpful to have good support for declaritive automation of the process.

cc: @cwoolum @chewong

[gregberns]

I've added an example of a basic Terraform configuration if anyone landing here is interested. See: #798