Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
2.3.0, 2.4.0
-
None
Description
We have been using jclouds with Azure Blob Storage successfully. However when changing the SKU of one of the Storage Accounts from Standard to Premium jclouds was suddenly no longer able to authenticate against the storage event though the credentials were valid. E.g. checking the existence of a container results in:
request: HEAD https://XXX.blob.core.windows.net/test?restype=container HTTP/1.1 failed with response: HTTP/1.1 403 Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.
After some investigation this seems to be caused by Premium storage not supporting the SharedKeyLite authenticatication method jclouds uses. Other projects seem to also have stumbled over this issue (e.g. https://github.com/khenidak/dysk/issues/6#issuecomment-355877888 , https://github.com/terraform-providers/terraform-provider-azurerm/issues/3939#issuecomment-524401721 ).
My reading of https://docs.microsoft.com/en-us/rest/api/storageservices/authorize-with-shared-key would have been that auth is the same for the SKUs and we have opened a support case with Microsoft to get further information. But given that at least one of the issues I linked before also mentioned raising this with them it is unlikely this behavior is unintended or will change.
Everyone else encountering this seems to switch to SharedKey authentication instead to resolve the issue and their code changes seem quite contained at first glance. This would also resolve the local development workflow issue of the Azurite storage emulator from Microsoft not supporting SharedKeyLite on blob storage.
To reproduce the problem just create Standard and a Premium SKU storage account and try to use them with jclouds to do a call like containerExists. With all else being the same Standard SKU will work while Premium SKU 403s.