We noticed that our service account in one of our key vault was locked and we do not know why or who locked it. Is there a way for us to check logs or investigate why it got locked
Hoping you have enabled logging on key vault, if so you should be able to access it from storage account. Some information about key vault logging is also available within Azure Monitor. Check following link for details. Azure Key Vault Logging
If you want you can use tools like log analytics to interrogate the data you have stored within the storage account.
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!
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.
we have a storage account that is locked down. My pipeline has connections that reference a key vault to get the access token for the storage account.
When I create an event trigger in ADF, ADF lets me find and connect to the storage account (without asking for a key or prompting me to select the linked service connection). It tells me what files it will include based on my begins with and ends with values (it found 2 files). It saves successfully.
When I publish it, I get this error in between publish to adf-publish and generating the arm templates.
The attempt to configure storage notifications for the provided storage account ****failed. Please ensure that your storage account meets the requirements described at https://aka.ms/storageevents. The error is Failed to retrieve credentials for request=RequestUri=https://management.azure.com/subscriptions/********/resourceGroups/<resource group name>/providers/Microsoft.Storage/storageAccounts/<storage account name here to gen 2 data lake>/listAccountSas, Method=POST, response=StatusCode=400, StatusDescription=Bad Request, IsSuccessStatusCode=False, Content=System.Net.HttpWebResponse, responseContent={"error":{"code":"InvalidValuesForRequestParameters","message":"Values for request parameters are invalid: keyToSign."}}
I believe this is due to the fact that ADF trigger creation process (and therefore its JSON) does not allow you to point to a Key Vault to get the access token for the storage account you are connecting to. Is this the issue? Is there a fix for this?
Appreciate any help, thanks - April
I think the storage account is attached to a VNET and running behind the firewall. I faced similar issue because of this. You may remove the firewall once and configure the trigger and then bring the firewall back.
It's not strictly necessary to disable the firewall. You can also use this feature on your storage account.
We have recruitment that need to store the file in Blob Storage. The blob storage account which i have created for a company. There are multiple site for a same company. We need to restrict the site member to see other site files. So I need the access key based on container level.
The container will be created dynamically from C#. The credential / access key that should be created while creating the container from C# and the container level access key / credential will be shared with site members not the storage account access key. Storage account key will be in application configure side. So storage account key will be hidden from the site members.
How do I get the container level access key / credential in Azure blob storage?
I think SAS could meet your requirements.With a SAS, you can grant clients access to resources in your storage account, without sharing your account keys. And you could set the interval over which the SAS is valid and the permissions granted by the SAS. For example, a SAS for a blob might grant read and write permissions to that blob, but not delete permissions.
You could create SAS pointing to one or more resources and including a token that contains a special set of query parameters.
Here are two examples about how to use SAS, first SAS examples and create SAS.
If you still have other questions, please me know.
I have registered a Free-Trial account on Azure site.
In documentation I found:
http://msdn.microsoft.com/en-us/library/windowsazure/dd179428.aspx
that I need some Shared Keys to use APIs.
But where are they located on Azure Management Portal?
I could not find them at all.
Do I need a paid account for this?
If you open the Azure portal, click on the "Hosted Servcies, Storage Accounts & CDN" link on the lower left and then pick "Storage Accounts". Once you click on "New Storage Account" and create a storage account, you will see "Primary access key" and "Seconardy access key" on the right hand side if you select that storage account in the middle.
More info:
Creating a storage account: http://msdn.microsoft.com/en-us/library/windowsazure/gg433066.aspx
Viewing keys: http://msdn.microsoft.com/en-us/library/windowsazure/hh531566.aspx
Note, if you are meaning Shared Access Signatures for blob storage, look at: http://blog.smarx.com/posts/new-storage-feature-signed-access-signatures
Each storage account you create will have a primary and secondary key, which is ultimately used in the REST header for accessing tables, blobs, and queues. If you're using .NET, Java, PHP or any other language where you've found a library wrapping the REST API, you won't have to worry about constructing REST headers; instead, you'll just create a storage endpoint using your primary or secondary key.
Making this easier, the key can be stored in your configuration settings. Then, if you ever change your storage account (maybe one for development, one for production), it's a simple matter of changing your configuration settings instead of changing code.
FYI - these keys are created automatically when you create a new storage account. And... you may use either key, and invalidate / re-create either key at any time (which is great if, say, you share your secondary key with a 3rd-party service and then want to terminate your relationship with that service).
I'd suggest grabbing the Windows Azure Training Kit and trying out a few of the first exercises, as you'll see exactly how to reference a storage account this way.