Change:
Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2016-09-26T18:16:57Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.1", GitCommit:"", GitTreeState:"clean", BuildDate:"2016-12-14T00:52:01Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"} Environment: Cloud provider or hardware configuration: Azure OS (e.g. from /etc/os-release): Ubuntu 16.04 LTS Kernel (e.g. ): 4.4.0-28-generic Install tools: Azure ACS Engine What happened: PVC keeps pending and returns "no key found for storage account" What you expected to happen: Storage class can retrieve the storage account key and successfully create the blob and pv. How to reproduce it (as minimally and precisely as possible): 1 - Create a new storage account and create a blob container named vhds 2 - Create a storage class as below 3 - Create the pvc 4 - Check kube-controller-manager logs: I0122 19:02:49. 1 ] no key found for storage account artyoudbs I0122 19:02:49. 1 ] failed to provision volume for claim "default/kaui-db" with StorageClass "slow": failed to find a matching storage account Anything else do we need to know: I can retrieve storage account keys using azure-cli: I've already used storageclass and pvc in azure with success before.
I was trying with a storage account in a different resource group. With the storage account in the same RG it works. Is it expected or a bug?
you have to use the storage account in the same resource group. Otherwise, the resource group is not authorized to retrieve the storage account's key
So you're saying the permission to attach a disk to a given VM is implicit by nature of them being in the same RG? I'm not sure that's accurate. I've had non-k8s VMs previously that use an attached disk from a different RG.
I am not sure about attach, but listing storage account and keys appears to be limited to the same RG.
Sure, but you shouldn't need to do those things if the user is walking up with a disk URI for a disk that just happens to live in a different storage account. You don't need storage account keys for attach.
Is there a specific "is in this resource group" check that you implemented? I would've assumed you just take the URI and try to attach it...
you are right, attach or walking up the disk URI doesn't check RG or storage account. The particular issue here happened during provisioning using a provided storage account that lived out of the RG. In such case, when the provsioner tried to find the account key, it failed.
Ah, yeah, I think it seems reasonable to say that dynamic provisioning only works when the targetted storage account is in the same resource group.
+1 So the doc needs some words about this case to stress storage account, if provided, must be in the same RG.
PR

Discussion:
* `skuName`: Azure storage account Sku tier. Default is empty. * `location`: Azure storage account location. Default is empty. <del> * `storageAccount`: Azure storage account name. If storage account is not provided, all storage accounts associated with the resource group are searched to find one that matches `skuName` and `location`. If storage account is provided, `skuName` and `location` are ignored. </del> <ins> * `storageAccount`: Azure storage account name. If storage account is not provided, all storage accounts associated with the resource group are searched to find one that matches `skuName` and `location`. If storage account is provided, it must reside in the same resource group as the cluster, and `skuName` and `location` are ignored. </ins> ### User provisioning requests