Anonymizing data with Presidio on Azure

Introduction

Earlier this week Laure showed me an awesome SDK that provides context aware, pluggable and customizable data protection and anonymization for text and images. Which is called ; Presidio! Where this has proven to be very useful for a use case we were working on. In today’s post, we’ll take a look how you can leverage both App Service and Logic Apps to build your own demo with Presidio. Though if you want to test things straight away, do check the demo website as maintained by the Presidio team themselves ; https://presidio-demo.azurewebsites.net/.

 

What does it do?

In essence, there are two steps involved ;

  • Analyzing ; Where an NLP trained model will go look for sensitive data and provide a list of locations where it found those.
  • Anonymization ; Where the list of locations is then used to filter out / mask sensitive information.

To get to a result where you can ensure that sensitive data like credit card numbers, locations, names, SSN numbers, bitcoin wallets, phone numbers, financial data, etc can be kept confidential. Which you can see on the following example.

Continue reading “Anonymizing data with Presidio on Azure”

Taking a glance at running an Azure Webapp on a custom location powered by Azure Arc

Introduction

Earlier this week I published the following repository ; https://github.com/beluxappdev/demo-arc-appservice. Which basically contains all the needed steps (via Azure CLI) to create an environment that showcases how Azure AppService and Azure Arc work together. For today’s blog post, I would like to take you on the journey from a “consumer” of this App Service Environment (running on any Kubernetes distribution, managed via Arc) to deploy a Webapp onto it. Where we can then see how the it is currently looking in the preview!

 

Let us make it real! The platform…

Continue reading “Taking a glance at running an Azure Webapp on a custom location powered by Azure Arc”

Azure API Management – What are my networking options?

Introduction

A very common discussion to have with enterprises around Azure API Management (“APIM”) is the aspect of network integration. At the end of the day, the response to that is very simple… Only the developer & premium SKU allow VNET integration. The integration is achieved by doing “injection”, which means that the service is “dedicated” to you and “the machines” are placed directly in your VNET. Azure APIM does not leverage private link (yet?)… Which then opens the next discussion, as the premium SKU is about 3,42 Euro per hour, where the basic SKU floats at about 20 Eurocent per hour. At this point, for most organizations, the cost impact will take priority over the most optimal design. Where today’s post will take a look at the various options at hand.

Update (March 2022)

Since the initial post, the ability to leverage private endpoints have been made available ; https://docs.microsoft.com/en-us/azure/api-management/private-endpoint. This concept will probably be more interesting to you than the approaches mentioned in this post!

Flavors / Tiers

When taking a look at the pricing info, you will notice there are multiple flavors you can choose from ;

  • The consumption tier is the one where you are charged for the amount of calls you make. It is an awesome model in terms of linking your business outcome to the cost model at hand. The downside is, that is does not offer a developer portal or any typical enterprise features (like VNET integration or a self-hosted gateway).
  • The basic and standard tiers are economic tiers at both about 45 and 130 Euros per month. They do include a developer portal.
  • The developer and premium tiers are the ones typically picked by enterprises due to their VNET integration, HA/DR options (for Premium) and the self-hosted gateway.

Continue reading “Azure API Management – What are my networking options?”

Azure DevOps Governance 101 – How does Identity, Billing and Service Endpoints intertwine?

Introduction

A common discussion I have had in my role is around the “billing structure” of Azure DevOps. Though the discussion typically spreads out to other topics like identity and service connections for deployment. In today’s post, we’ll go over the general governance structure behind Azure DevOps.

 

High Level Structure

For this, let us start with a complex drawing! 😉

 

As a bit of an introduction ;

  • Azure Active Directory is a component used for identity on both the Azure DevOps side (organization level), Azure Subscription and on the contract level for Role Based Access Control (RBAC).
  • Azure DevOps has the concept of an organization, which can hold multiple projects. The billing & identity part reside on organizational level (marked in red). Where the service connections for deployment (pipelines) resides on project level (marked in green).
  • There can only be one AAD linked to an Azure DevOps subscription. Though you can invite users from another AAD tenant via a typical B2B invite. Thus granting access to users outside of the AAD tenant linked to that organization.
  • There can only be one Azure subscription linked for billing. Though you can have multiple Azure subscriptions linked as service connections for deployment.
  • Multiple Azure DevOps organizations can use the same Azure subscription for billing. This will even allow the scenario of multi org billing.

So far for the basics… Let us now delve deeper into various topics.

Continue reading “Azure DevOps Governance 101 – How does Identity, Billing and Service Endpoints intertwine?”

Identity based security for LogicApp to LogicApp communication

Introduction

For today’s post we’ll go through a simple (yet powerful!) example that shows you how to securely communicate between two LogicApps. For this we will leverage the concept of managed system identity on the sender and access token validation on the receiver.

Conceptual

To get a bit of an idea of the flow, let us take a look at the drawing below…

The sender (LogicApp on the top left) is foreseen of a Managed System Identity in AAD. It will leverage this capability to get an access token from AAD. In addition, we will include a specific audience in the scope. This refers to an application object inside of the AAD tenant.
This token will then be included in the authorization header (as a JWT token) towards the receiver (LogicApp on the top right). The receiver will validate the JWT token by checking the public keys of the issues (AAD). Next up, it will check if the Issuer and Audience provided match the defined policy. If all is okay, then it will accept the request.

Continue reading “Identity based security for LogicApp to LogicApp communication”

Azure Serverless Compute Options

Introduction
A bit less than a year ago I blogged my opinion on “Cloud Native”, where the objective of today is to provide a bit more nuance to this previous post. Let us categorize it as “progressive insights”, due to having these type of discussions on a virtually daily basis. Therefore I wanted to share this with a broader audience, as I expect this is valuable to all. Where I will also try to make it a bit more tangible to link it to “Serverless” options in Azure.

Continue reading “Azure Serverless Compute Options”

Logic Apps ; When do I go for a consumption or a fixed pricing model?

Introduction

Today’s post is about the Logic Apps billing model. As you might know, the Integrated Service Environment has been generally available since May 2019. Since then, there is a consumption plan and a fixed price approach for Logic Apps. Lately I have noticed that this still remains confusing… Let us try to demystify this one then? 😉

 

Bibliography

Continue reading “Logic Apps ; When do I go for a consumption or a fixed pricing model?”

How to estimate the costs of your Azure Kubernetes Service (AKS) cluster?

Introduction

Aside from the variety of technical questions, a very common discussion around Azure Kubernetes Service (AKS) is … “What will it cost me?”. In today’s post we’ll dissect how the pricing dynamics work and how you can optimize the cost for your cluster(s). Where this might not be rocket science, I do have noticed some organizations struggling with this. So with this I hope to help those out… 😉

Continue reading “How to estimate the costs of your Azure Kubernetes Service (AKS) cluster?”

Cloud Native in the Enterprise ; What about outsourcing?

Introduction

At the beginning of the month Geert posted the following question on Twitter ;

Where the “depends” was a common word to be found in this thread. 😉 So let us delve into this today, shall we?

Continue reading “Cloud Native in the Enterprise ; What about outsourcing?”

Azure Networking ; Service endpoints, Private links and VNET Injection

Introduction

Today’s post is inspired by the combination of a twitter thread from earlier today… and having had the same conversation with a customer earlier today too! Truth be told, there are a variety of networking options when integration Azure Services with your VNET (Virtual Network). So let us go over them!

 

The different options

When you want to integrate PaaS services, you have several options on how to integrate them into your VNET ;

 

Now lets us take a look at the differences by using the following schematic ;

 

You will see that both the “SQL Managed Instance” and “Azure Kubernetes” service reside inside of the virtual network. This is what used to be called “VNET injection”, and where you deploy the service directly into the VNET. Typically you give each of those services their own subnet, without any other things inside of it to avoid interoperability issues. Though from then on you can leverage private traffic within your VNET and have hybrid integration scenarios (aka “Connect to On Premises”).

When looking towards the “Azure Storage”, you can see two colors ;

  • Purple indicates a “Private Link” & “Private Endpoint”. The private link is the line from the service to the dot. Where the dot is actually the private endpoint, which will have a private ip belonging to the range of the subnet (within the VNET) it belongs too. This means that the service will be able to connects you privately and securely to a service powered by Azure Private Link. The nuance difference between “VNET injection” and “Private Link” is that the first is used for resources dedicated to you (AKS Workers, SQL Managed Instance, …) and the latter is used for services that share resources underneath (AKS Master Nodes, Azure SQL DB, Azure Storage, …). This will also allow you to connect to services in a hybrid integration scenario.
  • The orange link depicts the concept of a service endpoint. It extends your virtual network private address space to a shared service. The endpoints also extend the identity of your VNet to the Azure services over a direct connection. Endpoints allow you to secure your critical Azure service resources to only your virtual networks. Traffic from your VNet to the Azure service always remains on the Microsoft Azure backbone network. If you want to understand more of the mechanics underneath, check the following post from when I took my first glance at them. Important to know is that the service will still have its public IP, and that you will leverage that to connect to it. It is used to connect from inside of the VNET to a public endpoint, while you can configure the firewall of the public service to filter on your private range. It cannot be used to connect to a service in a hybrid integration scenario.

 

Not all options work for all services!

Though be aware that not all services have all options available… Check the documentation of the services at hand and the above options. I know this makes it a bit complex at times. Though the capabilities are constantly evolving! And sometimes network integration is also only unlocked in premium editions of a service. For example, in the past you could only get a fully private scenario for App Service by leveraging the Isolated edition (or “App Service Environment”). This made it possible to inject the service into your VNET. Though it had a starting cost of about 1k USD… With the arrival of Private Link/Endpoint, this is not a requirement anymore. Where the API Management does still require either the Premium (Production) or Developer (Non-Production) variants of the service to unlock VNET integration.

 

Closing Thoughts

Things might be confusing at times. Though I hope this brief post helps you position the different options you have in terms of network integration.

  • Service Endpoints ; Connect in a hardened way from a VNET to a shared service
  • Private Link ; Give a shared service a private endpoint in your VNET
  • Deploy inside of a VNET (“VNET Injection”) ; Deploy a service privately for you into your VNET