add Pod Identity support

[andyzhangx]

Is your feature request related to a problem? Please describe.

Describe the solution you'd like in detail

add support for Pod Identity to enable finer grain scope of identity as an alternative to using the cluster’s identity. We do see cases where Azure resources are closely associated with the cluster. But we also see customers partitioning AKS clusters using namespaces, and in those cases it’s more likely that RBAC grants to resources like storage/key vault would be to Managed Identities that were scoped to a Kubernetes namespace.

Describe alternatives you've considered

Additional context

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[rompom]

Hi @andyzhangx, do you think the support for podidentity will be feasible ?

I have this kind of architecture : 1 "client" per namespace, , 1 file share / namespace, 1 key vault / namespace

For now I'm using the secret store csi driver to glue everything (shortened version) :

1. Create the kv
2. Create the file share, store the keys in kv
3. Map the kv with podidentity to the secret store csi
4. Access the azure file in aks with the secrets retrieved from the secret store csi

With a podidentity support, it would looks like (shortened version 2) :

1. Create the file share
2. Map the file share with the podidentity
3. Access the file share in aks

[andyzhangx]

@rompom azure file driver could use k8s secret to access file share, it's not necessary depending on pod identity, here is an example: https://github.com/kubernetes-sigs/azurefile-csi-driver/blob/master/deploy/example/storageclass-azurefile-secret.yaml

[rompom]

@andyzhangx sure, but my idea was more or less to not have to use k8s secrets at all if possible, and the pod identity was a pretty good candidate for this :)

[andyzhangx]

Agent node still needs account name & key to mount azure file, I think the question here is whether it’s necessary to store account key as a secret, answer is No.
There is parameter storeAccountKey(“true” by default) defined here , so if you set as false in storage class, it won’t store account key as a k8s secret, and when there is azure file mount on agent node, it would use node identity to get account key and then mount azure file.

As you could see, there are pros and cons for this feature(storeAccountKey: “false”), pros is no account key restore as a k8s secret, while cons is that agent node should have read access to the account.