Last summer I posted about taking a look under the hood of the Azure Active Directory integration for a Linux Virtual Machine. For today, let’s take it a bit further… What if we would want to pre-provision a set of UIDs (User IDs) & GIDs (Group IDs) on a range of virtual machines for cross machine consistency. Let’s say, we would want to make use of an NFS drive and use the same UID/GID across all those boxes. Can we do that with the AAD extension? If so, how can we do it? Let’s hope we can… Otherwise it’ll become a rather short blog post.
This post is based upon my personal experience reverse engineering how this extension works. This is by no means a support statement. If you’re a technical nut (like myself) and want to know how you can tweak this at your own doing… Then this post is for you. 😉
Continue reading “Reverse engineering the “AADLoginForLinux” in order to tweak proactive user configuration”
Proxy servers are a very common thing in a lot of enterprises. They are used so that people cannot directly access the internet, and additional management capabilities to the flow (logging, authentication, …). Now that sounds very dandy, though what about those non-browser-based tools? How can we ensure that tools like Azure CLI, Azure Powershell & AzCopy work with our “beloved” enterprise proxy? That’ll be the topic for today!
What will we be doing today? I’ve setup a proxy server in my own lab… Basically deployed a Squid proxy by means of a container.
Next up, I’m going to use the three earlier mentioned tools on both Linux (WSL) & Windows, and see what needs to be done to get things working. In the following screenshots you’ll typically see a “split screen”, where left is a “tcpdump” on the box running the proxy server and right will be the commands on the box running the tools. If you see a lot of mumbo jumbo (network packets) on the left, that’ll mean that the proxy server was being used. Ready?!? Cool, let’s go!
Continue reading “What the proxy?!? How to use a proxy with the typical Azure tools…”
Earlier this week I received a two folded question ; “Does a service endpoint go over internet? As when I block the storage account tags with a NSG, my connection towards the storage account stops.” Let’s look at the following illustration ;
The first thing to mention here is that the storage account (at this time) always listens to a public IP address. The funky thing is, that in Azure, you’ll have a capability called “Service Endpoint“, which I already covered briefly in the past. For argument’s sake, I’ve made a distinction in the above illustration between the “Azure Backbone” and the “Azure SDN”. A more correct representation might have been to have said “internal” & “external” Azure Backbone in terms of the IP address space used. So see the “Azure Backbone” in the above drawing as the public IP address space. Here all public addresses reside. Where the “Azure SDN” is the one that covers the internal flows. Also be aware that an Azure VNET can only have address spaces as described by RFC1918. So why did I depict it like this? To indicate that there are different flows;
- Connections from outside of Azure (“internet”)
- Connections from within the Microsoft backbone (“Azure Backbone”)
- Connections by leveraging a service endpoint
So how does the service endpoint work?
So to answer the question stated above ;
- Q: Does a service endpoint go over “the internet”?
- A : Define “internet”…
- If you mean that it uses a public ip address instead of an internal one? Then yes.
- If you mean that it leaves the Microsoft backbone? Then no.
- If you mean that the service is accessible from the internet? Unless you open up the firewall, it won’t (by default, when having a service endpoint configured).
- Q: When I block the storage tag in my network security group (“NSG”), then the traffic stops. How come?
- A: The NSG is active on NIC level. The storage account, even when using a service endpoint, will still use the public IP. As this public IP is listed in the ranges that are configured in the service tag, you’ll be effectively blocking the service. This might be your objective… Though if you do this to “lock down the internet flow”, then you won’t achieve the requested you wanted. You should leverage the firewall functionality from the service for which the service endpoint was used.
As always, let’s do a deep dive to experience this flow! So I did set up the above drawing in my personal lab ;
Continue reading “Hardening your Azure Storage Account by using Service Endpoints”
Posts about security are always the ones that make everyone get really excited… Or maybe not everyone. 😉 Anyhow, what is typically the weakest link in any security design? Indeed, the human touch… The effects of this can range from having seen secrets to creating drift (unwanted changes vs de expected baseline). In today’s post, I’ll walk you through an example setup that aims to close some additional holes for you. How will we be doing this? By basically automating the entire infrastructure management with Azure Devops & Terraform. Now you’ll probably think, what does that have to do with security? Good response! We’re going to reduce the points to where human contact can interfere with our security measures. Though we want to do this without putting our agility at risk!
For this exercise, we’re going to leverage this blueprint ;
Continue reading “Landscaping a Secure/Closed Loop Infrastructure in Azure with Terraform & Azure Devops”
If you have gone through the typical authentication scenarios, then you’ve probably seen that almost every single one is calling the Graph API. Where that is already cool as such, we’re all probably more interesting in using our own APIs… Today’s post will go through the process of calling -both- the Microsoft Graph API and your own API from the same code base.
Starting Knowledge Assumption
My assumption is that you are already familiar with the basics of Oauth, where you’re aware that a Single Page Application (SPA) is using an “Implicit Grant Flow“. Also be aware that the Azure Active Directory (AAD) v1 endpoint differs from the v2 endpoint in terms of resources & scopes.
In the v1 endpoint, you would target a “resource” in order to get authorization ;
Where the v2 endpoint rotates around the usage of scopes ;
The latter indicates both the resource & the permission that is targeted…
Setup of the day
As our test bed for today, we’re having a Single Page Application that has its own “Application ID” (clientid in Oauth). Which will be linked to two backend APIs; Microsoft’s Graph API and our own
Both our APIs have a given set of scopes that indicate the permissions that a user grants towards these APIs…
Probably everyone can relate that they do not want to invest the time in something “as commodity” as authentication when developing. Though on the other hand, the “identity” part is a key part to keeping your application (and thus your organization’s data) secure. So how to find the perfect fit in terms of this balance? Leveraging identity providers is the typical path to take here. Where there are quite a few in a SaaS service model even. From the Microsoft stables, you can find both Azure Active Directory & Azure Active Directory B2C to play an important role in this space.
When looking in this space, the defacto protocol standards here are Oauth2 & OpenID Connect. Where OIDC (OpenID Connect) is actually a layer built on top of Oauth2. Anyhow, where they provide a very good / robust security layer, the flip side of the coin is that (like with any security product) there is a given entry barrier in terms of understanding the complexity it brings (in terms of authentication flows).
Continue reading “Integration MSAL (Microsoft Authentication Library) into VueJS”
Last week the blog post “Simplifying security for serverless and web apps with Azure Functions and App Service” was published. In essence, it talks about how you can integrate Azure Functions with Azure Key Vault in order to retrieve secrets and import them into the application settings (being environment variables). You can do this in a secure manner, by providing the Azure Functions platform with a Managed Service Identity, and granting its underlying service principle with (limited: list & read) rights to the Key Vault.
Let’s take a look!
The first thing we’ll need to do, is to enable the “Managed service identity” for our Azure Function plan. Let’s browse to our Azure Function plan, and then select “Platform features”.
Continue reading “Using Azure Key Vault with your application settings (environment variables) powering Azure Functions”