-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use workload identity instead of storage key? Identity not found? #945
Comments
what blob csi driver version are you using? is it managed by AKS? we are not releasing the workload identity support release yet. |
I believe it's the AKS managed one, will follow up Tuesday when I'm back at the console |
@TeamDman the managed blob csi driver does not support workload identity, it supports managed identity instead, check details here: https://github.com/kubernetes-sigs/blob-csi-driver/blob/master/docs/workload-identity.md in your case, you could remove you could also set |
I hesitate to grant the kubelet identity the perms since that grants the whole cluster access. I'm setting up a shared environment where multiple teams will be using a cluster separated by namespaces; the goal is to be able to use managed identities so I'll check out the second part you linked! Node pools Kubernetes versions Node sizes Cluster Configuration |
Here's what I'm using apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
helmCharts:
- name: blob-csi-driver
repo: https://raw.githubusercontent.com/kubernetes-sigs/blob-csi-driver/master/charts
version: v1.18.0
namespace: kube-system
releaseName: blob-csi-driver
valuesInline:
controller:
replicas: 1
node.enableBlobfuseProxy: true
cloud: AzureStackCloud Will follow up once I get the time to try the |
@TeamDman msi is managed identity, and it can only be assigned to node level. if you want namespace isolation identity, account key stored as k8s secret is the only way now. |
Thanks for the clarification, will wait for GA release of the full support then <3 |
/assign @cvvz |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close not-planned |
@k8s-triage-robot: Closing this issue, marking it as "Not Planned". In response to this:
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-sigs/prow repository. |
Is your feature request related to a problem?/Why is this needed
I have a cluster where I have a k8s service account set up with Workload Identity.
https://learn.microsoft.com/en-us/azure/aks/workload-identity-overview
The identity has Storage Blob Data Reader role, so it should be able to read the storage account?
However, it doesn't seem like this is a supported use case, instead I think we are required to create a k8s secret with a storage key?
https://github.com/kubernetes-sigs/blob-csi-driver/blob/master/deploy/example/e2e_usage.md
Describe the solution you'd like in detail
I'd like this to work without needing to create a secret for the storage key, since I should be able to give the workload identity principle the necessary roles to access the storage
Describe alternatives you've considered
Additional context
The above example errors with the following
I tried adding the object id in case that helped, but it seems that I was right the first time and only the client ID should need to be specified
The text was updated successfully, but these errors were encountered: