I started getting this problem today when I try to use same secret for my second application in a single key vault;
Multiple resources/entities can access a single Key Vault instance – provided they’re all in the same location (data center).
You may choose to segment your keys, secrets and certificates, either by placing them in different Key Vaults or by using different access methods/identities, however that’s not necessary.
The only time you need a separate Key Vault instance is when the resources/entities accessing it are in another location (data center/region).
It’s worth noting that you don’t need to worry too much about provisioning Disaster Recovery for resources using Key Vault, as the SLA Microsoft provide is unsurprisingly good: https://docs.microsoft.com/en-gb/azure/key-vault/key-vault-disaster-recovery-guidance. One caveat to that would be if you’re running IaaS/PaaS instances and want to run a DR fail-over yourself to another data center, at which point you’d need to manually migrate the keys/secrets/certificates in your main Key Vault into another instance (and re-point your VMs accordingly)
To secure your web app make sure you have setup HTTPS only and client certificate required.
To further restrict access, you can setup IP address-based rule.
To add an access restriction rule to your app, select Networking under settings and click on Configure Access Restrictions. On the Access Restrictions pane, select Add rule. After you add a rule, it becomes effective immediately.
Rules are enforced in priority order, starting from the lowest number in the Priority column. An implicit deny all is in effect after you add even a single rule.
On the Add Access Restriction pane, when you create a rule, do the following:
Under Action, select either Allow or Deny.
Optionally, enter a name and description of the rule.
In the Priority box, enter a priority value.
In the Type drop-down list, select the type of rule.
The different types of rules are described in the following sections.
Note
There is a limit of 512 access restriction rules. If you require more than 512 access restriction rules, we suggest that you consider installing a standalone security product, such as Azure Front Door, Azure App Gateway, or an alternative WAF.
Set an IP address-based rule
Follow the procedure as outlined in the preceding section, but with the following addition:
For step 4, in the Type drop-down list, select IPv4 or IPv6.
Specify the IP Address Block in Classless Inter-Domain Routing (CIDR) notation for both the IPv4 and IPv6 addresses. To specify an address, you can use something like 1.2.3.4/32, where the first four octets represent your IP address and /32 is the mask. The IPv4 CIDR notation for all addresses is 0.0.0.0/0. To learn more about CIDR notation, see Classless Inter-Domain Routing.
Azure DevOps required to deploy build to App Services and we need to allow these services for this use case. Microsoft has introduced an AzureDevOps service tag for it but as of this writing the tag is not working. The work around is to open app to selected geography where Azure DevOps is running. In my case, they are running in EASTUS. I am going to add this rule to allow Azure DevOps to works with Azure App Service;
This will open up App to the whole EastUS region but still is better than opening it up to the whole world.
As of this writing Azure DevOps Service tag is not supported for hosted agents. AzureDevOps tag does not cover Microsoft Hosted Agents IP range, which makes the use case for using it in Azure App Service limited. The only relevant use case is, if a custom web hook is hosted on App Services.
Azure DevOps IP address and domain URLs can be used and Azure Virtual machine scale set agents to shrink the possible IP range. Refer to following links for further info;
I have created a resource group in East US2. I am going to move “app service plan” from “East US” to “East US2.
Great. The resource is moving.
The resource can be moved but its location (region) is retained.
This time I am going to move same resource from East US to East US2 (Region transfer).
If you click ok, you will see this message;
No use. One region resource cannot be moved to another region with Move option. What it means, that you have to create your resource group, app service plan, apps domain name, application insights in a separate region.
Follow this article from Microsoft to move your resources from one region to another.
The easiest way is to clone existing pipeline through Azure DevOps portal. Click on Pipelines -> Your pipeline à Click the ellipse in the upper right corner (three vertical dots), then click clone.
If clone is not available due to any reason, you can create a new pipeline based on an existing yaml file which is basically cloning.
Pipelines -> New Pipeline -> Configure (3rd page of the wizard) -> Select “Existing Azure Pipelines YAML file”.
Here you can select the branch and the file you want to use. However, this does not copy the variables set in the pipelines.
Above solution will work within same project. If you want to clone/import pipeline from a different project, Select “Export to YAML” from source project pipeline. This will download a YAML file on your local. Open file, make changes and import to your new project repo.
Locally redundant storage (LRS) replicates your data three times within a single data center in the primary region. LRS provides at least 99.999999999% (11 nines) durability of objects over a given year.
The following diagram shows how your data is replicated within a single data center with LRS:
LRS is the lowest-cost redundancy option and offers the least durability. If a disaster such as fir or flooding occurs with the data center, all replicas of a storage account may be lost or unrecoverable.
Zero-redundant storage
Zone-redundant storage (ZRS) replicates your Azure Storage data synchronously across three Azure availability zones in the primary region. Each availability zone is a separate physical location with independent power, cooling, and networking. ZRS offers durability for Azure Storage data objects of at least 99.9999999999% (12 9’s) over a given year.
The following diagram shows how your data is replicated across availability zones in the primary region with ZRS:
Microsoft recommends using ZRS in the primary region for scenarios that require consistency, durability, and high availability.
If your application is restricted to replicating data only within a country or region due to data governance requirements, you may opt for LRS or ZRS. The reason, In some cases, the paired regions across which the data is geo-replicated may be in another country or region.
