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.
Related
I have a requirement to create an azure blob using power automate based on a trigger. I am using the access key to connect to the storage account. If I need to rotate the access key, what are the options to avoid the manual edit in the connection. Is it possible to use azure key vault to retrieve the access key and use it in the connection details of create blob component?
The password field in the azure blob storage connector in power automate does not seem to accept the variable value, Is there a workaround?
When it comes to the Key Vault side of things, you can use the Key Vault managed storage account key feature to list (sync) keys with an Azure storage account, and regenerate (rotate) the keys periodically.
Please note that Key Vault Managed Storage Account Keys (legacy) is supported as-is with no more updates planned. For more info - Manage storage account keys.
Additional Links:
Manage storage account keys with Key Vault and Azure PowerShell
Create SAS definition and fetch shared access signature tokens in code
I hope this helps!
Per my understanding, there are two types of SAS tokens when it comes to Azure Storage Account.
Account-level SAS tokens
Blob container/Queue level SAS token
I observed that if we do not choose to use the primary/secondary keys to authenticate with the storage account and use the account level SAS tokens as an authentication mechanism then I can not create the Blob container level SAS tokens using Stored Access Signature. Why is that? Is there a way to make it work? I do not want to provide access to my service to the account level keys and want to create SAS tokens to implement the RBAC at the runtime, is there any way for same?
I observed that if we do not choose to use the primary/secondary keys
to authenticate with the storage account and use the account level SAS
tokens as an authentication mechanism then I can not create the Blob
container level SAS tokens using Stored Access Signature. Why is that?
This is by design. A container level SAS only lets you work at the container level where you can perform operations on the blobs inside that container. Creation of a blob container is an account level activity and thus you would need to use an Account SAS. At this time, Account SAS do not have a concept of Shared Access Policy.
I do not want to provide access to my service to the account level
keys and want to create SAS tokens to implement the RBAC at the
runtime, is there any way for same?
Yes, there is. Azure Blob Storage support Azure AD based authentication/authorization and has support for Role-based Access Control (RBAC) available in Azure Subscription. You can assign granular RBAC roles to your users in Azure AD and they will be able to perform only the operations allowed by their roles. You can read more about it here: https://learn.microsoft.com/en-us/azure/storage/common/storage-auth-aad.
You can find more details about various authorization options available in Azure Storage here: https://learn.microsoft.com/en-us/rest/api/storageservices/authorize-requests-to-azure-storage.
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 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.
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.