Five tips to enforce both network and identity controls without virtual networks

Security plays a prominent role in modern solutions. Although there is a growing adoption of the Hub & Spoke topology in Azure, which consists in isolating everything from the Internet and controlling how traffic is routed, by integrating services inside virtual networks, it comes at a cost and with a certain level of complexity. Not all companies can afford this. So, let us see what alternatives exist to enforce some security controls at both network & identity levels. Virtual networks and some of the below tips are not mutually exclusive.

Tip #1 – Enforcing network & identity controls with API Management (APIM) policies

APIM allows you to enforce network access control lists with the ip-filter policy:

Figure 1 – IP filter policy

This policy can even be useful when APIM is inside a VNET, especially when you share a single instance across multiple applications. You could as well use this policy to restrict access to a web application firewall (WAF) only.

Different policies are available to enforce identity-related controls. The most used one is validate-jwt:

Figure 2 – Token validation policy

This policy can be integrated with any OIDC-compliant identity provider and allows you to inspect and validate claims that are part of an incoming access token.

Other policies are available to validate the identity (with or without user context) of the caller:

• validate-azure-ad-token: to validate Azure Active Directory tokens (also works with validate-jwt) but validate-azure-ad-token is specific to Azure Active Directory
• validate-client-certificate: to enforce mTLS and make sure the caller includes a trusted certificate as part of its request

On top of this, you can make use of the following policies to authenticate APIM itself against a given backend:

• authentication-basic: as the name indicates, it allows you to perform a basic authentication against a given backend
• authentication certificate: this one allows you to use mTLS from APIM to a given backend
• authentication-managed-identity: this one allows you to request a token to Azure Active Directory, to authenticate against an AAD-protected backend
• get-authorization-context: this one allows you to leverage authorizations defined in the APIM instance, against SaaS solutions and OAuth-compliant identity providers.

As you can see, the sky is the limit in terms of what you can do with APIM.

Tip #2 – Enforcing network & identity controls with Azure App Service and Azure Functions

With both web apps and function apps, you can turn on Access Restriction and Authentication. Access restrictions allow you to authorize IP ranges, while Authentication allows you to plug your app or function into an identity provider. The list of providers is made of Azure Active Directory, social identity providers, and any OIDC-compliant identity provider. This can be done without a single line of code.

Tip #3 – Enforcing network & identity controls with Azure Logic Apps

Logic Apps running on the Consumption tier are public by default, from a network perspective. Here again, you can define IP restrictions in the workflow settings:

Figure 3 – IP restrictions in workflow settings

Specific authorization requirements can also be enforced thanks to the Authorization feature available for logic apps:

Figure 4 – Authorization feature of Logic Apps

Tip #4 – Enforcing network & identity controls with Azure Container Apps (ACA)

ACA is the last-born Azure Container Service. Apps can be entirely isolated from the Internet when working with internal Azure Container App Environments, but you can also use the Consumption tier of ACA, which is public by design. However, whichever flavor you are using, you now can restrict traffic to a desired set of IPs, thanks to ingress rules. As you might know, AKA is entirely backed by K8s, which is fully managed by Microsoft. K8s makes use of ingress controllers when exposing services outside of a cluster. Microsoft has now given the possibility to define allow and deny rules, that are enforced by the ingress controller. More info can be found on this in the official documentation: https://learn.microsoft.com/en-us/azure/container-apps/ingress?tabs=bash#ip-access-restrictions

With regards to identity, ACA also has an authentication feature, which is remarkably like the other services. You can access it through the Authorization blade of any container app.

Tip #5 – A few mixed tips

• You can enforce IP restrictions on the AKS API server (https://learn.microsoft.com/en-us/azure/aks/api-server-authorized-ip-ranges)
• Most data services (SQL, Cosmos, Storage, etc.) have resource-level firewalls that allow you to define IP restrictions, and they support Azure AD authn/authz
• Azure Active Directory conditional access allows you to specify locations from which users can log in, on top of support for Multi-Factor Authentication (MFA)
• You can ban entire countries/regions, as well as IP, ranges from consuming your workloads thanks to WAF policies, which you can assign to Azure Front Door and Application Gateway
• You can restrict Azure Static Web Apps traffic to Azure Front Door only by using the AzureFrontDoor.Backend service tag in the allowed IP ranges.

Conclusion

There are many ways you can restrict traffic to your workloads, whether there are within virtual networks or not. With IP restrictions only, traffic still flies over the Internet, and you do not control it to the same extent as you would if you would be using virtual networks. However, it is even more important to think about these controls when not using virtual networks. Besides network, most Azure Services have a native integration with Azure Active Directory and other identity providers, which gives you a lot of flexibility to control the identity layer. The icing on the cake: these features are usually free of charge and easy to implement.