I'm working through comparing Azure Subscription IDs and Account IDs. Is it really as simple as the subscription ID relates to the storage name and is unique for each storage container, and the account ID relates to your Azure account? Why do you need them both?
So I think here are 4 concepts:
Azure Account - either an Microsoft Account (like xx#outlook.com, xx#hotmail.com), or an Organizational Account (created by Azure AD, if you don't know this you don't need to care). This is what you used to log in to Azure Portal and use the service. Global Unique.
Azure Subscription - more like a billing unit for your Azure Services, including VM, Storage, etc. The identity is a GUID and its name is just for display, no uniqueness required.
Azure Storage Account - used for authentication to Azure Storage with a pair of storage name + storage key. The name is an identity and must be globally unique. You can have multiple storage accounts in a subscription.
There are various reasons about why Azure Storage has its own authentication other than use Subscription certificates or Azure Account. One of them is that Azure Storage are more likely accessed by application programmatically which has different requirements of the portal, so name/key or SASToken are used to do authentication here.
Azure Storage Container - like a directory in an Azure Storage Account to group data. Its name should be unique within one account.
An Azure subscription may have many storage accounts.
A storage account may have many containers.
In order to access the contents of a container, you'll need your corresponding storage account and key. You will not need your subscription credentials to access storage account contents directly.
Related
Like most Azure Functions in the beginning we have a connection string to the associated storageaccount that includes the Accountkey like this
DefaultEndpointsProtocol=https;AccountName=ourstorageAccount;EndpointSuffix=core.windows.net;AccountKey=WQfbn+VBhaY1fi/l0eRBzvAvngiCiOwPmx/==
We obviously want to remove that AccountKey. I had hoped we could use ManagedIdentity and the 'Contributor' Role but what I am reading is telling me you cannot use Managed Identity to access Tables in a Storage Account only Blobs.
I know that we could move the whole connection string to KeyVault but that just becomes ann Azure Management Issue if we want to rotate the keys.
Has anyone succesfully controlled access to Azure Table Storage with Managed Identities?
If not what is the next best approach that preferably allows for simple rotation of keys?
Has anyone successfully controlled access to Azure Table Storage with Managed Identities?
Definitely it is unable to access azure table storage with MSI(managed identity, essentially it is a service principal in azure ad), when using MSI to access some azure resources, it essentially uses the azure ad client credential flow to get the token, then uses the token to access the resource.
However, azure ad auth just supported by azure blob and queue storage, table storage doesn't support it currently, see - Authorize access to blobs and queues using Azure Active Directory.
If not what is the next best approach that preferably allows for simple rotation of keys?
You could use azure function to do that, follow this doc - Automate the rotation of a secret for resources with two sets of authentication credentials, I think it completely meets your requirement, this tutorial rotates Azure Storage account keys stored in Azure Key Vault as secrets using a function triggered by Azure Event Grid notification.
Is there a way to get properties of a storage account, specifically the kind of account - GPv1, GPv2 or blob storage, through an API in Storage Services?
I came across https://msdn.microsoft.com/en-us/library/azure/ee460802.aspx but if possible, I would like to re-use the SharedKey authentication I use for the Blob Service APIs.
In this page, https://learn.microsoft.com/en-us/rest/api/storageservices/ I found this:
"All access to storage services takes place through the storage account. The storage account is the highest level of the namespace for accessing each of the fundamental services. It is also the basis for authentication.+
The REST APIs for storage services expose the storage account as a resource."
How would I get properties of that resource? I played around with setting the restype to storage account, similar to "container" and "table", but could not access it.
When it comes to managing storage accounts, there are two REST APIs:
Storage Service REST API: This API is used to manage the data in the storage accounts. This makes use of account name and access key (also known as storage account key). You can find more details about this API here: https://learn.microsoft.com/en-us/rest/api/storageservices/.
Storage Resource Provider (SRP) REST API: This API is used to manage storage accounts. You can use this API to create, update, delete storage accounts, regenerate account keys and get information about the storage account themselves. This makes use of Azure AD for authentication and authorization. You can find more details about this API here: https://learn.microsoft.com/en-us/rest/api/storagerp/.
Now coming to your question, you can't really use Storage Service REST API to find information about the type of storage account. You would need to use Storage Resource Provider API to find this information. In particular you will be consuming Get Properties SRP API to find this information.
I have create more than 3 storage account and 3 VM and 3 Clusters.
Storage Accounts:
Storage Account 1
Storage Account 2
Storage Account 3
I want to know Storage Account 1 is associated with how many VM and Clusters. How can I find it via Azure Portal ?
A storage account isn't an "owned" or "dedicated" resource. That is, even if you use a storage account for a given app or service, there's no tight coupling between the two. Any service / app that has your account credentials (or a SAS link to a specific container/queue/table within your storage account) will be able to use that storage account.
However, if you look at the settings for a given app or service (in your case, your VM or HDInsight), you can see which storage accounts it's using, with a bit of digging. For example, your VM might have both OS and Data disks, with each disk using potentially a different storage account - you'd need to enumerate the OS+attached disks to see which storage accounts are in use for each.
Further, if you create all resources at once (again, imagine creating a new VM with new storage), all of your resources will be bundled together within the same Resource Group.
You can via the new Azure portal to find the Azure Storage Account, in the storage account, you will find the Container. The vhds container used for Azure VM by default, select the vhds, you will find the VMs' VHD files there. About the HDInsight, the default Container name is the HDInsight name, so we can find the result manually.
I deployed WorkerRole to Azure Cloud Service (classic) in new portal. With this, I also created Azure Storage account for queue.
Try to add AutoScale rule, the storage account is not listed. Tried to select Other Resource and put Resource Identifier of storage, there's no Metric name listed.
Is it by design that classic Cloud Service and new Storage account not working together?
Storage account data (e.g. blobs, queues, containers, tables) are accessible simply with account name + key. Any app can work with them.
However, to manage/enumerate available storage accounts, there are Classic-created and ARM-created accounts, each with different API's.
The original Azure Service Management (ASM) API doesn't know anything about ARM resources. There's a fairly good chance that, since you're deploying to a Classic cloud service, it's using ASM only and will not be able to enumerate ARM-created storage accounts.
If you create a Classic storage account (which has zero difference in functionality), you should be able to see it as an option for auto-scale.
I have a bit more details on the differences in this answer.
At this time, it is not possible to autoscale anything based on a new "v2" storage account. It has nothing to do with the fact that you are using the classic Azure Cloud Service. I am having the same issue with using Azure App Services. In the end, I just created a classic storage account to use for the autoscaling. There is no difference in how you interact with the different types of storage accounts.
I have a Service Principal that has been granted Contributor roles on a storage account.
When I attempt to create a container within that account I receive the following error message
One-time registration of Microsoft.Storage failed - The client 'd38eaaca-1429-44ef-8ce2-3c63a62849c9' with object id 'd38eaaca-1429-44ef-8ce2-3c63a62849c9' does not have authorization to perform action 'Microsoft.Storage/register/action' over scope '/subscriptions/********'
My goal is to allow a Service Principal READ-ONLY to the blobs contained within a given storage account and to create containers within that storage account. What are the steps needed to configure my principle to do that.
Regarding your error, please see this thread: In Azure as a Resource Group contributor why can't I create Storage Accounts and what should be done to prevent this situation?.
My goal is to allow a Service Principal READ-ONLY to the blobs
contained within a given storage account and to create containers
within that storage account. What are the steps needed to configure my
principle to do that.
As of today, it is not possible to do so. Simply because RBAC only applies to the control plane of the API. So using RBAC, you can control who can create/update/delete a storage account. Access to the data inside a storage account is still controlled by an account key. Anyone who has access to the account key will have complete control over that storage account.