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.
Related
can anyone explain difference between Azure Application Gateway, Virtual Network Gateway, Virtual WAN, ExpressRoute, Arc and Private Link, please?
It seems to me all services are pretty similar helping with connecting either on-prem to Azure, in-Azure to in-Azure or public to Azure.
They're similar in that they all involve network traffic, but that's pretty much where the similarities end.
Application Gateway is a Layer 7 load balancing service with advanced features like SSL termination. It's used to route client requests to your applications.
Virtual Network Gateway is a VPN gateway for point-to-site (user) and site-to-site (office/datacenter) VPN connections to your own Azure VNETs. This would, for example, allow you to RDP into Azure VMs from your on-prem office using their private IPs.
ExpressRoute is similar to site-to-site, however it doesn't use IpSec tunnels, it's a dedicated, unencrypted connection from your location directly into Microsoft's backbone. (i.e. you don't traverse the public internet). There's no encryption and the connection is faster. This is a service you need to work with a 3rd party internet provider to implement.
Virtual WAN is more like a networking hub where there would be many site-to-site, point-to-site, ExpressRoute, etc... connections spanning a wide area (as the name implies). This would be for large enterpise organizations with many on-prem locations.
Arc is a means of adding your on-prem resources into Azure for management. e.g. you have a physical server somewhere and you want to manage it though ARM/portal.
Azure Private Link is a feature of many Azure services (storage, SQL PaaS, etc..) which allows you to create a private DNS record and assign a private IP address on your internal VNETs. This is used when you want to disable all public network access to a resource and only allow access from within your own VNET.
I have barely scratched the surface of the differences here, but suffice it to say, there are many differences. From this page, you can type the service name into the search and get more specific details on the offering. Hope this helps.
https://learn.microsoft.com/en-us/search/?terms=networking%20in%20azure
Suppose I have an Azure function on Consumption plan hosted in VNET, if my function calls are restricted to the App Service Instance in the VNET, do I still need to ensure my function is only accessible with Function/Admin keys?
My view is that, if the endpoints are secured in VNET, then I do not need to implement access keys right?
I doubt we will be able to answer this question, it depends on your workload and security requirements.
One factor (network firewall) might be enough for your use case, others may want/need a second factor (authorization key).
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.
I was able to find that Google Cloud makes sure that any requests which move out of its physical environment undergo mandatory encryption, refer to (pg6 under heading Virtual Machine to Virtual Machine of) this link
Do Azure (and AWS) follow a similar procedure? I would appreciate if someone can point me to an official link. I was not able to find it in Azure docs.
Thanks
Azure supports various encryption models, including server-side encryption, client-side encryption, Azure disk encryption and so on. Read Azure encryption overview.
For data in transit, you will see that Azure always encrypt traffic between your cloud-hosted resources and external networks or the public internet.
Data in transit is data moving between resources on the internal,
between datacenters or external networks, or over the internet.
Data in transit is usually encrypted by requiring SSL/TLS protocols
for network traffic. Always encrypt traffic between your cloud-hosted
resources and external networks or the public internet. PaaS resources
typically enforce SSL/TLS encryption by default. Your cloud adoption
teams and workload owners should consider enforcing encryption for
traffic between IaaS resources hosted inside your virtual networks.
Azure VM in Azure is not an individual resource. It must be deployed in an Azure virtual network, which is the fundamental building block for your private network in Azure. VNet enables Azure VMs, to securely communicate with each other, the internet, and on-premises networks. You also could secure VNet using the network security group. So, the internal traffic between two VMs in a VNet is secure. If the VMs in different VNets, you cloud peer two VNets with each other. The traffic between VMs in the peered virtual networks is routed through the Microsoft backbone infrastructure, much like traffic is routed between VMs in the same VNet, through private IP addresses only.
Even the traffic in an Azure VNet is secure but the HTTP request is not secure by default. HTTP requests and responses are sent in plaintext, which means that anyone can read them. HTTPS corrects this problem by using TLS/SSL encryption. You could also consider using HTTPS requests.
Hope this could help you.
Can we create a firewall rule in azure to allow connections from azure data centre ONLY?
Strictly speaking, this can't be done.
Fundamentally, Azure doesn't reside within a singe IP address range, nor does each Azure region. In fact, each region is broken into multiple address ranges which aren't necessarily concurrent. The ability to define a single firewall rule (which covers the entirety of Azure's infrastructure) would require some work in Azure to define, and maintain, a variable which holds all of these values.
It may be worth pointing out that Azure does already offer similar solutions for Internet and VirtualNetwork, which are applied in the default NSG rules. As the majority of infrastructure within Azure, but outside of your virtual network, is essentially the Internet, setting such a variable for all Azure IPs would give a user the option to, potentially unknowingly, open up their resources to any kind of malicious activity.
Depending upon what exactly it is you are attempting to achieve, Azure does offer workarounds in the form of Service Endpoints. This functionality has recently left the preview phase, and allows a user to create a security rule between certain PaaS resources and your virtual network. Currently, this functionality is restricted to Azure Storage, Azure SQL Database and Azure SQL Data Warehouse.
An extremely sloppy way of implementing firewall rules for all Azure IP ranges would be to manually enter the address ranges from the region(s) you require, which can be downloaded here. However, doing this would be highly discouraged due to security flaws previously mentioned, plus these IP ranges are not entirely static, therefore it would be easy to get caught out if Microsoft was to edit certain address ranges.