add Pod Identity support about azurefile-csi-driver HOT 14 CLOSED

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

from azurefile-csi-driver.

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

from azurefile-csi-driver.

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

from azurefile-csi-driver.

@fejta-bot: Closing this issue.

from azurefile-csi-driver.

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

from azurefile-csi-driver.

@fejta-bot: Closing this issue.

from azurefile-csi-driver.

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

from azurefile-csi-driver.

@fejta-bot: Closing this issue.

from azurefile-csi-driver.

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

from azurefile-csi-driver.

@fejta-bot: Closing this issue.

from azurefile-csi-driver.

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

from azurefile-csi-driver.

@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

from azurefile-csi-driver.

@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 :)

from azurefile-csi-driver.

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.

from azurefile-csi-driver.