Secure Azure Key Vault

Security is key factor in your operational consistency. You might have a Azure Key Vault configured like this;

Click on “Private endpoint and selected networks”. Click on “Add existing virtual networks” to allow communication between internal network.

This setting will enable internal services to access key vault. The selected internet facing IPv4 addresses will have access to key vault resource.

Azure Key Vault with Azure Apps

I am going to create and configure Azure key vault in this demo. I am assuming that an app services has already been provisioned. We need to make a configuration change for SQL connection so that Key Vault secret can be used without touching the application code.

Provision the Azure Key Vault

For this demo, I am going to use new permission model that is based on Azure role-based access control (RBAC).

I am leaving it as Public endpoint to match the App service configuration.

Click on Review + Create button to start the deployment.

Once created, add yourself to the role “Key Vault Administrator” via the Access Control (IAM). Now you can start managing secrets.

Add the connection string to the Key Vault secrets.

Secret type (Upload options) “Manual”, give it a name and set the value to the SQL Database connection string to your Azure SQL or Azure SQL VM.

Click on Create. Once created, click on the secret to see the secret details, then click again on the current version.

Copy Secret Identifier to your clipboard.

Add the Secret identifier reference to the Azure App Service Settings

Open the App Service configuration settings, and ad a new Connection string setting.

Type the name of the connection string (“SqlConnectionString” for application) and set the value. You can use the same name that you have used in appsettings.json file. Set the value;


Click on Save to save the app settings.

Allow the App Service to access the Key Vault

On the App Service, click on Identity to enable the System Assigned identity. Click on save after turning “On” the status.

Click on the “Role Assignments” button and then click on the “Add role assignment”. In the role assignment, choose scope “Key Vault”, subscription the subscription where you created the Key Vault on previous steps and the name of the Key Vault resource. For the role just select “Key Vault Secrets User (preview)”

You can go to the appsettings.json/web.config file of your application and clear the connection string value;

Visit your website and see if it loads successfully. The connection string is safely stored in the Azure Key Vault, and it’s no longer stored on the file system.

Known issues

ERROR: You might get an error “Keyword not supported: ‘@microsoft.keyvault(secreturi'”. I have experienced that the RBAC permissions can take a one or two minutes to be applied, so try after a few minutes. Also try restarting the application thought the App Service portal so nothing is cached.

another error might be this;

ERROR: Format of the initialization string does not conform to specification starting at index 0.

Check your connection string. it has spaces or is not right.


Azure Virtual Network concepts and best practices

This article describes key concepts and best practices for Azure Virtual Network (VNet) .

VNet concepts

  • Address space: When creating a VNet, you must specify a custom private IP address space using public and private (RFC 1918) addresses. Azure assigns resources in a virtual network a private IP address from the address space that you assign. For example, if you deploy a VM in a VNet with address space,, the VM will be assigned a private IP like
  • Subnets: Subnets enable you to segment the virtual network into one or more sub-networks and allocate a portion of the virtual network’s address space to each subnet. You can then deploy Azure resources in a specific subnet. Just like in a traditional network, subnets allow you to segment your VNet address space into segments that are appropriate for the organization’s internal network. This also improves address allocation efficiency. You can secure resources within subnets using Network Security Groups. For more information, see Network security groups.
  • Regions: VNet is scoped to a single region/location; however, multiple virtual networks from different regions can be connected together using Virtual Network Peering.
  • Subscription: VNet is scoped to a subscription. You can implement multiple virtual networks within each Azure subscription and Azure region.

Best practices

As you build your network in Azure, it is important to keep in mind the following universal design principles:

  • Ensure non-overlapping address spaces. Make sure your VNet address space (CIDR block) does not overlap with your organization’s other network ranges.
  • Your subnets should not cover the entire address space of the VNet. Plan ahead and reserve some address space for the future.
  • It is recommended you have fewer large VNets rather than multiple small VNets. This will prevent management overhead.
  • Secure your VNet’s by assigning Network Security Groups (NSGs) to the subnets beneath them.

Next steps

To get started using a virtual network, create one, deploy a few VMs to it, and communicate between the VMs. To learn how, see the Create a virtual network quickstart.


Azure example of tagging

A resource tag consists of a name and a value. You can assign one or more tags to each Azure resource.

AppNameThe name of the application that the resource is part of.
CostCenterThe internal cost center code.
OwnerThe name of the business owner who’s responsible for the resource.
EnvironmentAn environment name, such as “Prod,” “Dev,” or “Test.”
ImpactHow important the resource is to business operations, such as “Mission-critical,” “High-impact,” or “Low-impact.”

Here’s an example that shows these tags as they’re applied to a virtual machine during provisioning.

You can run queries, for example, from PowerShell or the Azure CLI, to list all resources that contain these tags.

Azure Policy is a service in Azure that enables you to create, assign, and manage policies that control or audit your resources. These policies enforce different rules and effects over your resource configurations so that those configurations stay compliant with corporate standards.

Read more about it here;


Prevent accidental changes by using resource locks

resource lock prevents resources from being accidentally deleted or changed.

You can manage resource locks from the Azure portal, PowerShell, the Azure CLI, or from an Azure Resource Manager template.

To view, add, or delete locks in the Azure portal, go to the Settings section of any resource’s Settings pane in the Azure portal.

Here’s an example that shows how to add a resource lock from the Azure portal. You’ll apply a similar resource lock in the next part.

You can apply locks to a subscription, a resource group, or an individual resource. You can set the lock level to CanNotDelete or ReadOnly

Resource locks apply regardless of RBAC permissions

To make the protection process more robust, you can combine resource locks with Azure Blueprints. Azure Blueprints enables you to define the set of standard Azure resources that your organization requires. For example, you can define a blueprint that specifies that a certain resource lock must exist. Azure Blueprints can automatically replace the resource lock if that lock is removed.

Follow this for an example;