I remember the heady early days of the cloud when AWS networking was simple.
Even then, I saw this coming, of course. There's no way to "be everything for everybody" without also duplicating the insanity that is legacy IPv4 data centre networking.
Just recently, I wanted to do something conceptually simple in Azure: NOT have the storage account with our database backups "on the Internet" for the world to poke and prod at will.
So simple! Just turn on the firewall... and oh boy...
You can whitelist only subnets. Individual subnets. One. At. A. Time. Not virtual networks. Definitely not "all" of your virtual networks, which works elsewhere perfectly fine.
Okay, fine, there's a Private Endpoint feature as well. Sure, it kills performance and costs extra, but there's nothing wrong with having this cost money, right? After all, flipping the address in some config of a software-defined-network (SDN) from "public" to "private" is hard work and the gremlins in the cloud need to be compensated.
Then, err... uh-oh. It doesn't actually work! You need to override DNS to make your clients discover it. So you plug it into your AD domain. Now your PaaS services can't access it.
Okay fine, you create a private DNS zone (which costs more money), link it to a hub network, link a DNS Resolver service to it (which costs more money), then set up a bazillion rules so that your AD domain still works, and then...
... where was I again? I started this a week ago.
Oh yeah, I just wanted to make sure Russian hackers can't access our backups if a storage key leaks.
Maybe next week I can update the subscription templates to re-deploy all the virtual networks with the updated DNS settings.
Not idempotent, you say? Maybe next year they'll have a preview?
Never mind, I hope the Russians won't get mad at us in the next few months...
You setup VNETs with private endpoints and then configure your and the azure DNS to talk together with magic, and you can do what it is you want to do. Then you can use public gateways or front doors for anything facing the public. I’m not a big fan, but it’s not like it wasn’t very complex before. It’s just that now developers are more exposed to the insane mess that is enterprise networking where before it was strictly an ops thing. It’s still mainly an ops thing, which is why I called the DNS setup magic because that’s the part of it I don’t ever touch. Of course you do need to plan ahead, especially if you’re using app services and multiple subscriptions as you can’t share subnets, and also don’t want to run out of IP address space I’d you use app slots.
What I don’t personally get with Azure is why the “default” settings for enterprise isn’t that everything is not on the internet. Then when you need to do something on the internet, you’d need to open up. You’re likely going to need to set up a bunch of things like load balancer a and what not anyway, so the process of putting something on the internet is complicated to begin with, but everything should just be off the internet by default. At least as some Enterprise setting or whatever.
But I guess part of it is that Microsoft sells Azure certifications and need it to be hard. But why would you want to worry about all this complexity in 2023? At least as the default. It’s fine that it’s very customisable.
> What I don’t personally get with Azure is why the “default” settings for enterprise isn’t that everything is not on the internet. Then when you need to do something on the internet, you’d need to open up.
Because every major cloud provider made the mistake of using IPv4 networking for backwards compatibility with their customer's software from the 1990s.[1]
What they should have done is used IPv6 by default, and provided each customer subscription/account with a /56 in each region sharing a common prefix, e.g.: /48.
All of the private networking complexity just evaporates and turns into trivial firewall rules.
The "allow our vnets only" rule becomes a single /48 subnet allow rule. Want to trust a foreign tenant? Add their single /48 prefix and done! No NAT!
Service Endpoints and Private Endpoints are required only because IPv6 RFC1918 private ranges are too small, and hence overlap between customers. Remove the overlap and you remove the need for any kind of tunnelling or SDN magic.
No more split DNS either: the AAAA records are always the same for every name, whether "inside" or "outside" the network. At most, you might need "private records" that resolve only if the request query comes from the customer's /48 prefix.
And on and on...
IPv4 ought to have been an optional compatibility add-on, a side show to secure-by-default IPv6.
[1] Sadly, there's still software being written today that doesn't work with IPv6.
Even then, I saw this coming, of course. There's no way to "be everything for everybody" without also duplicating the insanity that is legacy IPv4 data centre networking.
Just recently, I wanted to do something conceptually simple in Azure: NOT have the storage account with our database backups "on the Internet" for the world to poke and prod at will.
So simple! Just turn on the firewall... and oh boy...
You can whitelist only subnets. Individual subnets. One. At. A. Time. Not virtual networks. Definitely not "all" of your virtual networks, which works elsewhere perfectly fine.
Okay, fine, there's a Private Endpoint feature as well. Sure, it kills performance and costs extra, but there's nothing wrong with having this cost money, right? After all, flipping the address in some config of a software-defined-network (SDN) from "public" to "private" is hard work and the gremlins in the cloud need to be compensated.
Then, err... uh-oh. It doesn't actually work! You need to override DNS to make your clients discover it. So you plug it into your AD domain. Now your PaaS services can't access it.
Okay fine, you create a private DNS zone (which costs more money), link it to a hub network, link a DNS Resolver service to it (which costs more money), then set up a bazillion rules so that your AD domain still works, and then...
... where was I again? I started this a week ago.
Oh yeah, I just wanted to make sure Russian hackers can't access our backups if a storage key leaks.
Maybe next week I can update the subscription templates to re-deploy all the virtual networks with the updated DNS settings.
Not idempotent, you say? Maybe next year they'll have a preview?
Never mind, I hope the Russians won't get mad at us in the next few months...