Trying to update my Service Bus apps to use the new RTM and I need this information.
<add name="AzureWebJobsDashboard" connectionString="DefaultEndpointsProtocol=https;AccountName=;AccountKey=" />
<add name="AzureWebJobsStorage" connectionString="DefaultEndpointsProtocol=https;AccountName=;AccountKey=" />
Previously I just used the connection string associated with each queue. I have tried about every combination of username and key I have associated with my account with no luck.
The AzureWebJobsDashboard connection string is your Azure Storage Account used by the Azure SDK to store logs used by the WebJobs dashboard.
The AzureWebJobsStorage connection string is your Azure Storage Account that is used to by the SDK to do things like trigger when a file is uploaded to blob storage or a message is added to a queue. It sounds like you may not need this though if you are only using Service Bus Queues. If this is the case for you, then you could use the same connection string that you use for the AzureWebJobsDashboard. Generally, you would use two different storage accounts so that one is used for dashboard logging and the other is used for application functionality (queues, tables, blobs).
The connection string is available in the Azure Management Portal (classic) by click on Storage in the left navigation, highlight the storage account you want to use, and then click the Manage Access Keys button at the bottom of the page.
The connectionString for AzureWebJobsDashboard and AzureWebJobsStorage are obtained from Azure Storage account.So follow the steps below to view the storage access keys.
1. Sign in to the Azure portal. https://portal.azure.com
2. In the navigation pane, click on Storage accounts.
3. Choose the desired storage account,click on Access keys and copy the Connection string.
The previous answers are correct, but I add this answer to give some clarity about the AzureWebJobsStorage key for someone learning Azure.
When creating a function app, a storage account is also setup. And inside the Function App, a application setting named AzureWebJobsStorage is created.
The connection string can be seen when checking Configuration under Function App. This reveals the name of the name of storage account and the access key.
Under Access keys in the Storage Account the connection string can be confirmed to be the same.
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.
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.
Whenever I create a new Storage (classic) account through the Azure portal I consistently have issues whereby the Table/Queue/File storage is not created at all, leaving the account with only Blob storage, like this:
Instead of like this (separate account):
I have tried this multiple times and all have had the same result. I don't see how I can be getting this wrong as there is only 4 options on the form to create the account, and none of them govern the content of the account.
When I then attempt to create a new Table or Queue in this new account I get a 502 Bad Gateway error.
Am I missing something here? Can anyone tell me how I can add the required storage types to the account.
Not sure what's up with the portal, but a storage account always comprises blob, table, queue, and file storage (unless you create a Premium storage account - that's strictly blobs).
You should be able to confirm this by creating an app to, say, create, write, and read from a queue or table.
EDIT I see you edited your question, showing that you did try to create a table/queue. If this is a non-premium account, I suggest reaching out to support, as this makes no sense.
EDIT 4/2017 Aside from Premium storage accounts (which only have page blobs), there is another type of general (non-premium) storage account, specific to blobs only, where you won't be able to create Tables and Queues, but it's not available via the "Classic" deployment model; it's available only via "Resource Manager" deployment model:
In my case the issue was due to selecting Zone Redundant Storage (ZRS).
Since ZRS accounts only support Block Blobs, you will not see the
table, queue or file endpoints listed on the portal for the new
account.
https://blogs.msdn.microsoft.com/windowsazurestorage/2014/08/01/introducing-zone-redundant-storage/
Recreating the storage account using Globaly Redundant Storage (GRS) worked.
I want to create a key in my mobile app backend that contains my storage account primary key like this tutorial instructs, but I can't figure out where in the Azure Portal I should create the key. I can't find the Connection Strings blade that the tutorial refers to. Am I missing something, or should I use the storage account primary key somewhere else?
You can retrieve the key from portal, instead of creating it yourself.
The Azure storage connection string is like this,
Standard
DefaultEndpointsProtocol=http;AccountName=myAccount;AccountKey=myKey;
Secure
DefaultEndpointsProtocol=https;AccountName=myAccount;AccountKey=myKey;
Update:
This should be what you are looking for,
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.