From the Azure Portal, on the Configure Tab for a notification hub I am able to generate a primary key and secondary key. I understand these are required to gain programmatic access to the Azure API - allowing my client app to create registrations and send messages.
Could anyone please explain:
Why are there two keys (primary and secondary)?
Do the keys generated from this UI expire and if so how long do they live before expiry?
They don't expire. The reason there are two is because it's recommended that you regenerate the keys periodically for security reasons. For example, suppose your application is using the primary key today. If you regenerated the primary key, then your application would be broken until you could update it and resulting in downtime. Instead, you can change your application to use the secondary key with basically little or no downtime. Then, after your application has been updated, you can regenerate the primary key. Next month (or whatever schedule you like), you can repeat the process, switching back to the primary key and regenerating the secondary key.
This is not unique to Notification Hubs. You will see primary and secondary keys in other services such as Storage and Media Services. The idea is the same.
Related
I have a question that I can't find the answer to in MS Documentation in regards to the Log Analytics Workspace keys. Does anybody know if I go to the Agent Management for a Log Analytics Workspace and hit Regenerate for a key, does it affect the connection for existing agents that were onboarded using the old key (will machines that were onboarded previously be disconnected)? Or it will only affect future onboarding machines (meaning I cannot onboard using the old key)?
When I try to click on Regenerate, I get this message which is confusing a bit:
"This will nullify old keys, so after regenerating you'll need to update the keys in all agent instances and all other instances, like APIs, Logic Apps and Microsoft Flow"
If someone has any experience with this it would be so helpful!!
If we regenerate the azure log Analytics Workspace key, the old key will expire and all gent instances connecting the workspace with the key will be disconnected.
Does Azure Key Vault supports Geo-Replication between the regions? I don't see any options?
https://learn.microsoft.com/en-us/azure/key-vault/general/disaster-recovery-guidance
"The contents of your key vault are replicated within the region and
to a secondary region at least 150 miles away but within the same
geography to maintain high durability of your keys and secrets. See
the Azure paired regions document for details on specific region
pairs."
From #Karthikeyan Vijayakumar comment above:
However I have the application deployed on both West US (primary) and East US(secondary) and I want to sync between the regions.
You don't need to replicate your Key Vault instance to make it available to your applications in both regions.
Simply call the URL (https://<vault-instance-name>.vault.azure.net), Azure DNS will dynamically resolve to the active region. By default, the active region is the region where you created the instance. In the event this region is unavailable, the DNS will resolve to the geo-replica, hosted in the corresponding paired region.
The problem with this approach is that you still on the mercy of Microsoft, as the service will be reestablished only if they decide to failover the region.
Short story long: There is no user managed geo replication of Azure Key vault like Azure SQL for example. In your case, you need to build a workflow that replicates the values between your primary and secondary key vaults.
Backup and Restore : https://learn.microsoft.com/en-us/azure/key-vault/general/backup?tabs=azure-cli
You can use these capabilities to build your workflow.
You can use the changelog to track changes to your key vault, and trigger a backup/Restore or you can schedule it like once a day.
A change tracking is better as you can only replicate changes and not the entire key vault.
Regards
When creating a shared access policy or registering a device in Azure IoT hub, there will be a Primary key and Secondary key pair generated. And I noticed I can connect a device to IoT hub using either Primary key or Secondary key.
So, what's the purpose of having Primary/Secondary keys? How should I design the use of both keys?
The goal of primary and secondary key is two-fold.
First of all it would allow you to keep using your service when you want to replace your key. Say you connect all your services using the primary and you want to refresh it. You could use the secondary temporarily in your services and then change your primary without having downtime. After you do the change you can configure your services to use the new Primary key.
The second possibility would be that you give partners your secondary key and you use your primary if one of your partners would abuse the key you could replace it without having downtime in your own services.
The subject says it all...
Why there are two keys for Azure DocumentDB (primary and secondary)?
This is so that you can expire a key without having any system downtime. Say you want to replace your primary key. The procedure is
Configure your service to use the secondary key - if you use the service config you can do this without downtime.
Regenerate the primary key
(Optional) reconfigure your service to use the new primary key
If there was only one key at a time, your service would be down while you did the key replacement.
Good practise is to replace your keys on a regular basis (e.g every 6 months or whatever is appropriate based on the sensitivity of your data). You should also replace keys when anyone who has access to the keys leaves your business or team. Finally, you should obviously replace them if you think they have been compromised in some way. E.g. accidentally written to a log or posted to a public GitHub repo - it happens...
https://securosis.com/blog/my-500-cloud-security-screwup
Both the primary and secondary keys can be regenerated in the Azure portal (note: at the time of writing this is the preview portal). Select your DocumentDB then the Keys pane. There are two buttons at the top of the pane:
I just created a new DocumentDB instance. When I go to the "Keys" area on the new Azure portal, I don't see a primary key or secondary key. My URI is listed. I tried use the regenerate feature hoping that would create the keys, but no luck. Anyone else have this problem? How would I report this to Msft without a technical support subscription?
The account can take several minutes to provision, during which time the keys will not be available (since the account has finished creating). If, in the portal, you choose to Browse | DocumentDB accounts, you will see the status (creating, updating, online). Once your account is in an online state, the keys will be available. Can you ensure that the account is indeed in an online state and, if so, refresh your browser and see if the keys are available?