Here is a question I would like to get some expert advice on. I have a few internal services within a vnet. They are exposed to external services via apim. The apim is in the external mode(hosted outside the Vnet). My question is, do I need apim for internal communication between internal services within the vnet? I feel it is redundant. But I would like some advice on some best practices in my case. Is apim not necessary for internal traffic?
Thanks
Related
I'm trying to configure an app service such that it has a private link setup into our VPN enabled vnet but also allow public access (e.g. to allow front door and our devops agents access).
The docs (https://learn.microsoft.com/en-gb/azure/app-service/networking/private-endpoint) note that "by default" public access is diabled, to me that sounds like it is possible to not have the default, is that actually possible?
I'd rather not route everything through our vnet (using hub and spoke design) because to my mind that adds a single point of failure we don't need, e.g. having front door connect to the app service over the MS backbone means it isn't reliant on my vnet infrastructure. But the vpn access is useful for internal access direct to the app service.
I also asked this on the MS forums and with some help came to what i think is an acceptable answer: https://learn.microsoft.com/en-us/answers/questions/968600/app-service-using-private-link-but-still-need-publ.html
I have Azure APIM setup and deployed few apis into the apim instance using the azure devops pipelines. Later we wanted to Integrate the APIM with the Vnet, so assigned the apim instance to a Vnet, with dedicated subnet and also assigned NSG rules with recommended ports open as per the MSFT documentation. Also attached certificates and defined some custom domain names as well. But end of the day, I was not able to see and APIs nor create/deploy the to the instance again. Not exactly sure what the issue is?
This is one of the error I see everytime I get to the instance page.
**Failed to connect to management endpoint at apim-xxx-xxx-dev-xxx.management.azure-api.net:3443 for a service deployed in a virtual network. Make sure to follow guidance at https://aka.ms/apim-vnet-common-issues.**
Not sure whether this is the issue or something else....
Any help or information is highly appreciated.
In the internal VNet integration, the API Management gateway and developer portal are accessible only from within the virtual network via an internal load balancer. See the documentation here. In this type of deployment, you will have to use a VPN or express route connection to the Azure VNet.
As #wali mentioned in his answer, with the internal VNet integration, all APIM service endpoints can only be accessed from within the VNet.
If you want to expose backend APIs in a VNet to external users via APIM, you can consider using the external VNet integration.
If you want both the external and internal users to access the APIs via APIM, you can use the internal VNet integration with an Application Gateway, like what is mentioned in this document.
I have a resource (specifically, a Kubernetes service deployed to my AKS cluster) to which I want to limit access. I've looked around through the MSDN documentation on What is Azure Virtual Network?, VPN Gateway design, and more, but I don't see a clear way that I can either:
Require AAD authentication before a specific IP/Port is accessed, or
Whitelist access coming from a specific IP/subnet (eg, specifying CIDR format www.xxx.yyy.zzz/nn that should get access).
There seem to be ways to restrict access that require I install some a RADIUS VPN client, but I don't want to require this. It seems like there are a ton of hoops to jump through -- is there a way I can block all incoming traffic to my AKS cluster except from specific AAD roles or from specific IP ranges?
It would be helpful to understand what you intend to use AKS for (web site, batch computing, etc.)
First you should fully explore the networking options offered by the service itself. Start with locking down to your personal IP address and the service will likely (based on Azure docs) append a deny-all to the end of your networking rules. To get the IP address it sees you from, try IP Chicken.
I offer two additional options: Application Gateway or API Management.
One way to lock this down, based on the information you shared, is Application Gateway.
Application Gateway (Product Page)
Ingress Controller for AKS
"Application Gateway Ingress Controller (AGIC) allows you to use Application Gateway as the ingress for an Azure Kubernetes Service (AKS) cluster." - from Azure Docs
API Management
You also have API Management paired with policies on that resource. It can restrict by AAD (check pricing tier for details) and IP address (on any pricing tier).
If the organic networking options of AKS don't cover your use case, I would choose API Management. Price and options are better for what it seems you are aiming for.
When configuring API Management inside a VNET one can choose between External and Internal.
My goal is to allow external trafic into API Management. But when request are made from other services within the VNET or from services that are on-premise and are using Express Route those calls should not be routed over the public internet. Those calls sould be routed directly to the APIM instance inside the VNET.
Is the above possible using the External mode? Or do I then need to set it Internal and use a Application Gateway to expose the endpoint for external traffic?
For the setup you've described you should use internal on apim and the vnet. Then all internal traffic should be routed via VNets/VPN. For the external traffic you should consider using a WAF with VNet UDR to route through to apim.
I have certain azure resources like AKS, redis, cosmos, APIM etc. To secure the resources from attacks like DDOS, we put them all in private vnet and made them accessible only via APIM. Is that the right approach? In this case we only need to worry about the security of APIM. However the cost associated with vnets are high and we are evaluating other options. One thing I see is DDOS protection plan which protects the whole RG. So another approach is to remove the VNET and make the RG protected with the DDOS protection plan. However, are there any other attacks which are possible even with DDOS protection plan? Whats the best way to address them? Any leads will be very helpful
you could use service endpoints for cosmos and restrict access only from vnet. For aks you can use loadbalanceripranges construct of k8s to whitelist ip's from api gateway.