Securing your pre-production environment in the cloud
One of my all-time favorite features of Azure App Service is deployment slots because of all the great time saving scenarios they offer developers. In a nutshell, site slots allow a developer to setup a staging environment for their application then swap it with their production code seamlessly, with no downtime. One of the common asks folks have about this feature is whether they can secure their pre-production environment so that it’s not visible on the web before it’s ready to release.
The good news is that this scenario can be implemented with a few button clicks! The Azure App Service Authentication Authorization feature can be leveraged to secure a site slot since they’re basically fully functional web apps.
In this blog I will walk you through a pretty simple, yet powerful, scenario. I will create a Web application and staging slot used to deploy my code before releasing to production. I will then use the Authentication Authorization feature to secure my staging slot so it’s available for my Azure Active Directory users only. I will leverage GitHub for source code repository and CI. The GitHub repository will map to my staging environment.
The results? An Azure Web app with a secure staging environment allowing you develop your code in peace.
The steps below assume you own or have access to:
- An Azure Subscription (get one here)
- A GitHub account
- At least one repository that can be deployed to Azure App Service
- You will use mostly the Azure Preview portal (code named Ibiza) and the existing management portal
Setting things up
Create a new Web Application. Make sure you select a Standard pricing tier (deployment slots are only supported in the Standard and Premium tiers).
Next, you will setup a staging slot for your new Web App. Scroll down to the Web app blade and click Deployment Slots. In the Deployment Slots blade, click the “+” button and in the Add a slot blade pick a name for your slot (in this sample we are calling it “stage”). Make sure to select the “Don’t clone configuration from an existing slot” option. For more information about Site Slots configuration check out this document.
Now, it is time to setup continuous integration between Github and your new staging site. Click “Set up continuous deployment” on the Staging Slot blade, then select the source repository and configure your CI source (more information about setting up CI is here).
Now that we have a staging environment site with a CI connection, we will secure it using Azure Active Directory (AAD). Use the “All settings” link on the staging site, select the Authentication / Authorization option and click the “on” button under “Active Directory Authentication.”
Note: the Active Directory will be selected based on the tenant that is associated with the logged in user to the management portal. To create your own directory follow the instruction in this document.
Now you’re now ready to go! Click the Browse button in the website blade for your staging slot (the URL for the staging slot will be http://<site name>-<slot name>.azurewebsites.net/). If you have associated your AAD user name with your Microsoft ID used for the management portal you may not see the sign in page for your staging slot. To make sure it works, use InPrivate browsing on IE or Incognito for Chrome.
Assuming you setup CI with the staging slot, you will now be able to swap your code into production. Click the Swap button on the staging slot blade to push the code content from the staging slot to the production slot. Note: you can select the target slot for swapping (if you have more than two slots) and that before the swap operation is initiated you can preview the changes and address any warning that may come up.
In conclusion, combining the power of Site Slots and the Authentication Authorization features allows developers to:
- Setup pre-production environments for their web applications, swap them into production easily and have fine-tuned control over settings on each environment
- Secure pre-production environments to make sure they are not visible to the public
Source: Microsoft Azure News