ritazh
commented
5 years ago @martin2176 The use case you have described can be accomplished with namespaces. Each team can deploy secrets and applications within their own Kubernetes namespaces to limit access from other teams. Take a look at: https://kubernetes.io/docs/tasks/administer-cluster/namespaces/#understanding-the-motivation-for-using-namespaces
As a cluster user, I want to interact with resources that are pertinent to my user community in isolation of what other user communities are doing on the cluster.
Key vault flexvolume definitely supports this use case as each volume is defined at the pod level. As long as the pod can access the secret you have created for the service principal that can access your key vault, then the volume will be mounted successfully to the pod.
scenario like this: Multiple teams (business units) using a shared AKS cluster. Each team want their own key vault and be able to access them using their own Service Principal using KV Flex volume mount. Can I create something like below to be able to do this. The idea being without stepping on each other's Key Vault 1) kvcredsteam1 will be used by Team1 to access Key Vault1 2) kvcredsteam2 will be used by Team2 to access Key Vault2 kubectl create secret generic kvcredsteam1 kubectl create secret generic kvcredsteam2
Is there anything in KV Flex Vol implementation which might prevent the above configuration ? If such a configuration is permitted, is there a limit in number of KVs within reasonable limit of course