Understanding Azure MSI (Managed Service Identity) tokens & caching


Now that Azure MSI turned generally available for App Services and Azure Functions, there is no more excuse not to use it. As a recap, Azure MSI is a great way to develop more secure applications and to setup more secure environments. The reason for this is mostly because it saves you from having to generate credentials (Service Accounts or Apps) yourself. Continue reading

Posted in Azure | Leave a comment

Azure Firewall, a step towards a “managed” NVA?


Microsoft recently made Azure Firewall available in public preview. This Firewall as a Service offers a new way to protect and control network traffic via both network and application rules. At the time of writing, Azure Firewall is used to control outbound traffic only. Network rules are similar to what you can do with NSG but application rules allow URL based rules as shown below:

Continue reading

Posted in Azure | Tagged , | 1 Comment

Integrating On-Premises Jenkins with VSTS to deploy to an ILB ASE


I recently had to work on integrating an on-premises Jenkins with VSTS in order to use VSTS’s out of the box capabilities to deploy resources to Azure. Although there is quite a good documentation on this topic, you must be able to read between the lines. So, with this blog post, I’m not going to repeat was is described in the article but I’m going to try to fill the gap when it comes to integrating with an on-premises Jenkins and not with a Cloud-based Jenkins, as assumed by the Microsoft documentation. Since an image tells more than a lengthy speech, here is one that sum it up all:

Continue reading

Posted in Azure, DevOps, vsts | Tagged , , , | Leave a comment

My recipe to build secure applications hosted in Azure


Here are some tips that might help you building and hosting secure applications in Azure.

Application Architecture: Clients and APIs

Make sure to make a clear segregation between clients and APIs. I’m not a great fan of MVC where the C part is often used as an API layer by developers. I advocate for a clear separation between the client part (could be a mobile APP, a SPA, etc.) and the API layer. The clients and APIs should be hosted in different App Services.

Continue reading

Posted in Azure, Azure Active Directory, Azure Key Vault, Security | Tagged , , | Leave a comment

Azure Security Cheat Sheet


Cybersecurity is a concern for everyone today as more and more workloads are connected in a way or another, meaning exposed in a way or another. When it comes to the Cloud, things turn wilder as PaaS, CaaS, FaaS and even IaaS to some extent, represent a paradigm shift. Organizations tend to rely on good old recipes that are perfectly suitable for traditional on-premises systems but not especially a good fit for the Cloud, even when talking IaaS, since the underlying network plumbing does not have much in common with on-premises networks. Moreover, insiders represent a severe security risk but some organizations still think their premises is way more secure than the Cloud, just because, it is within the walls.

Continue reading

Posted in Azure | Tagged , , | Leave a comment

Deploy Azure App Services to multiple regions within the same subscription – VSTS trick


Most of the times, when deploying App Services such as a webapp to a single region, you simply use the Azure App Service Deploy task, that is currently in version 3.0 and whose a preview of the next version is to come.

However, using the very same task to deploy an App Service to multiple regions, in case you have a HA setup is a little more challenging. Looking at the below screenshot:


you can easily specify the name of the App Service. The problem is that, when working with multiple regions, the name will most probably be the same in the other region, therefore, the task cannot distinguish which service is targeted.  So, ideally, we should be able to select the resource group to make this distinction.

It turns out that one can select the resource group when ticking the Deploy to slot option:


but what if you don’t use slots??? Then, the easy fix is to put the value “production” in the Slot field.

Credits to Thomas Browet (@thomas_brw), one of my colleagues, for the tip.

Happy deployments!

Posted in Azure, DevOps, vsts | Tagged , , , | 2 Comments

VSTS task/extension upgrade explained


There is quite good documentation on Microsoft web sites on how to build custom tasks and custom extensions but things become a little more complicated when it comes to upgrading existing tasks and/or extensions. Since I ended up reverse engineering extensions built by big third parties (by downloading them), I thought it was well worth a blog post to prevent you having the same pain.

That said, you have to distinguish the tasks & extensions. For a private use, one can perfectly work only with tasks. Extensions are a way to distribute one or more tasks from the market place, either for a private share, either for public share. I will only consider the latter.

Fixing a bug

If you want to fix a bug of an existing task, you can simply upgrade the patching or minor version number and upgrade the extension number in the manifest.

"version": {
"Major": "1",
"Minor": "0",
"Patch": "1"

Updating the extension in the Management Portal (I’ll come to this later) will automatically make the build agents of accounts consuming the extension, picking up the last version of the task.

Publishing a major version of a task

If the change is bigger than merely a bug fix and if you want to have task versions side by side to avoid breaking anything or to propose multiple versions of a same task such as:


you’ll need to work a little more. In that case, you can duplicate your existing task but end up with a folder structure like this:

my task
—-v1 artifacts
—-v2 artifcats

The task identifier must remain the same, the name may be left unchanged or be changed and the major versions must be different. In the extension manifest, the contribution should refer to the root folder of the task and its identifier like this:

"contributions": [
      "id": "ca1755b2-751f-45e3-9bad-89a5c08d457d",
      "type": "ms.vss-distributed-task.task",
      "targets": [
      "properties": {
        "name": "rootfoldername"

Deleting a task or a version

I wouldn’t recommend you trying this but it seems to have no effect on accounts having already your extension installed, and this, to avoid any disruption of service I guess. However, beware that removing an extension from the marketplace seems to be one step too far as existing account’s build/release definitions will be broken if using tasks from your extension.

In case of a mere task/version deletion, new accounts will only see the remaining tasks and/or versions while existing accounts would only get a fresh copy by uninstalling and reinstalling completely the extension which is unlikely to happen. It could be handy at tenant level to have an upgrade version as well to opt-in explicitly and have a better control over what the supplier is doing. Today, the only two options are “Disable” and “Uninstall”.

Updating the extension itself

The only way to push changes to existing and new accounts is to publish a new version of the extension itself. This can be easily done by updating the extension manifest manually and by calling tfx extension create, or simply by calling tfx extension create –rev-version which will create the extension package and change the manifest in order to increment the version number. Once the package is produced, you can simply use the update menu option:


Happy VSTS.


Posted in vsts | Tagged , , , , , | Leave a comment