Hacker News new | ask | show | jobs
by jiggawatts 1892 days ago
Years and years ago I saw an advertisement by a SAN array vendor where their gimmick was that they supported very cheap read/write snapshots of very large datasets, in combination with a set of transforms such as data masking or anonymisation.

Their target market was same as the OP: developers that need rapid like-for-like clones of production. The SAN could create a full VM server pool with a logical clone of hundreds of terabytes of data in seconds, spin it up, and blow it away.

The idea was that instead of the typical "DEV/TST/PRD" environments, you'd have potentially dozens of numbered test environments. It was cheap enough to deploy a full cluster of something as complex as SAP or a multi-tier Oracle application for a CI/CD integration test!

Meanwhile, in the Azure cloud: Practically nothing has a "copy" option. Deploying basic resources such as SQL Virtual Machines or App Service environments can take hours. Snapshotting a VM takes a full copy. Etc...

It's like the public cloud is in a weird way ahead of the curve, yet living with 1990s limitations.

Speaking of limitations: One reason cheap cloning is "hard" is because of IPv4 addressing. There are few enough addresses (even in the 10.0.0.0/8 private range) that subnets have to be manually preallocated to avoid conflicts, addresses have to be "managed" and carefully "doled out". This makes it completely impossible to deploy many copies of complex multi-tier applications.

The public cloud vendors had their opportunity to use a flat IPv6 address space for everything. It would have made hundreds points of complexity simply vanish. The programming analogy is like going from 16-bit addressing with the complexity of near & far pointers to a flat 64-bit virtual address space. It's not just about more memory! The programming paradigms are different. Same thing with networking. IPv6 simply eliminates entire categories of networking configuration and complexity.

PS: Azure's network team decided to unnecessarily use NAT for IPv6, making it exactly (100%!) as complex as IPv4...

7 comments

Your comment makes me realize how lucky I am at my job: we do this production environment replication via “SAN magic” and it is so insanely useful.
How do you deal with replicating customer data / data the developer / tester should not have access to?

Do you copy that into the ephemeral test environment as well? How are permissions managd for accessing that data? Does it have the same restrictions as in prod? (i.e. even in this env the developer / tester has no access to systems / data they would not have in prod).

Unfortunately I don't have a good answer for you - I work for a trading firm so there is no customer data. The minimal data that developers aren't allowed to see is restricted in both environments, but in practice the software we build doesn't touch this data anyway.
You know how you can build an app's tests to generate new tests based on a schema, to test all possible permutations of a data structure using all possible data inputs? That, but for databases.

In Security this is known as "fuzzing", but instead of looking for security vulnerabilities, you're generating test data for databases. Your test data should cover all possible customer data inputs. Then you not only don't need real customer data for testing, you catch bugs before a customer does.

That isn't useful when you have a reported bug and need to investigate and debug. Which is the scenario I am assuming this "quickly and easily copy prod to ephemeral test environment at the press of a button" setup is designed to make easy.
Using real person-related data for testing was made illegal in Europe by GDPR. Even with explicit consent of each affected person, the tester needs to make sure that the test really requires real person-related data, otherwise it would violate the principle of "privacy by design" from GDPR. Without consent it is entirely forbidden, as of my understanding of the GDPR.

Due to GDPR I had to implement an anonymization feature for the production database anyway. So I am able to clone the production database for testing and run the anonymization function on every entry in the test database before using it.

This sounds like a needlessly strict interpretation of GDPR. Taken from the UK regulator's site:

> The lawful bases for processing are set out in Article 6 of the UK GDPR. At least one of these must apply whenever you process personal data:

> (a) Consent: the individual has given clear consent for you to process their personal data for a specific purpose.

> (b) Contract: the processing is necessary for a contract you have with the individual, or because they have asked you to take specific steps before entering into a contract.

> (f) Legitimate interests: the processing is necessary for your legitimate interests or the legitimate interests of a third party, unless there is a good reason to protect the individual’s personal data which overrides those legitimate interests. (This cannot apply if you are a public authority processing data to perform your official tasks.)

...

> Legitimate interests is the most flexible lawful basis for processing, but you cannot assume it will always be the most appropriate. It is likely to be most appropriate where you use people’s data in ways they would reasonably expect and which have a minimal privacy impact, or where there is a compelling justification for the processing.

> The processing must be necessary. If you can reasonably achieve the same result in another less intrusive way, legitimate interests will not apply.

> You must include details of your legitimate interests in your privacy information.

I included the legitimate interests bits because they seem most relevant to testing, but even if testing is not considered "necessary" in a particular use case, there still remain at least two more criteria that might satisfy the use of live data in testing, including explicit user consent. Much of the focus of GDPR is on privacy-invasive intrusive processing and prevention of harm, I think a lot of fuss around it can be dispelled when viewed from this angle.

I admit that using real person-related data in a test database for ordinary software development (not considering fixing a production system here) might be legitimate according GDPR based on contract and consent. But the hurds are so high that I cannot think of any realistic use case that involves more than a couple of people at the maximum. Contract and consent are subject to specific requirements here. The constent must typically be voluntarily, i.e. without any pressure or coercion, it must not be coupled to another condition and it must be given for each specific purpose indivdually. And I doubt that it is permitted to completely exlude the principle of "privacy by design" in a contract. And even if this were the case, you need this consent from each customer whose data is in the database, while you must not make your service to the customer dependant on his consent.

As to legitimate interest, Recital 47 of GDPR states: "The legitimate interests of a controller, including those of a controller to which the personal data may be disclosed, or of a third party, may provide a legal basis for processing, provided that the interests or the fundamental rights and freedoms of the data subject are not overriding, taking into consideration the reasonable expectations of data subjects based on their relationship with the controller. Such legitimate interest could exist for example where there is a relevant and appropriate relationship between the data subject and the controller in situations such as where the data subject is a client or in the service of the controller. At any rate the existence of a legitimate interest would need careful assessment including whether a data subject can reasonably expect at the time and in the context of the collection of the personal data that processing for that purpose may take place. The interests and fundamental rights of the data subject could in particular override the interest of the data controller where personal data are processed in circumstances where data subjects do not reasonably expect further processing."[1]

Typically one does not have a contract about software development with a customer whose personal data is stored in a database, but about a specific service, such as for example selling something to him via a Web-shop. So if Uncle Joe is buying something from the Web-shop, can he reasonably expect that his personal data is used in developing the Web-shop software? Most likely not. Ergo, there is no legitimate interest to use his data for that pupose.

[1] https://gdpr-info.eu/recitals/no-47/

[Edit for clarity.]

This is an interesting question.

I've seen 1:1 copy of prod databases running in test environments. Very convenient from a dev perspective but a no-go for many customers.

I've also seen test envs using fixtures only. More privacy-compliant, but it makes it harder for in-depth testing or to uncover weird edge cases.

> Meanwhile, in the Azure cloud: Practically nothing has a "copy" option. Deploying basic resources such as SQL Virtual Machines or App Service environments can take hours. Snapshotting a VM takes a full copy. Etc...

To add to the list of etc, I can't query across two databases in azure SQL.

You can't even copy an Azure SQL Database across subscriptions! This is something that comes up regularly at my day job: there's an Enterprise Agreement production subscription, and an Enterprise Dev/Test subscription for non-production that's much cheaper. This would be great, except for stupid limitations like this.
I believe you can now query across DBs in Azure via a Linked Server. It still feels a little clunky to me though.

https://docs.microsoft.com/en-us/sql/relational-databases/li...

gcp doesn’t even give you ipv6 at all. Talk about limitations...
> There are few enough addresses (even in the 10.0.0.0/8 private range) that subnets have to be manually preallocated to avoid conflicts

I hate to be that guy, but it's 2021 and we should start deploying stuff on ivp6 networks to avoid this kind of problems (beside other kind of problems)...

edit: ok I just saw the PS about ipv6 and Azure... sorry.

Do you remember the name of the original SAN array provider?
It could be NetApp, they had a huge marketing wave 2-3 years ago. In fairness, their appliances are very good, I've seen them in action both on-prem and in the cloud (on AWS). The pricing however... They're very expensive, particularly so in the cloud (since you're paying licensing on top of cloud resources).
OnTAP Cloud? That's what their system was called.
Yup, we were beta testers or something the time
I still have the 8.1 manuals laying around here. Nifty technology but pricey, indeed.
I want to a copy of our Azure SQL database dumped to my local dev MS SQL instance very often. At the moment I do this by using SSMS, where I generate a script of the Azure SQL database and use sqlcmd to import that script. It is a really painful process, and sqlcmd sometimes just hang and becomes unresponsive.

Why is there no simple export/import functionality?

You can export Azure SQL Databases to a "BACPAC" file, which is much faster. This can then be restored onto on-prem SQL equally fast.

It's about 20-30 lines of PowerShell to do this, and then you can just double-click the script and drink a coffee.

Alternatively, for data-only changes you can use Azure SQL Sync, but I've found that it's primitive and a bit useless for anything complicated...

> Azure's network team decided to unnecessarily use NAT for IPv6, making it exactly (100%!) as complex as IPv4...

People like the NAT. It's a feature, not a bug. If your selling point for IPv6 is "no more NAT" then no wonder it never went anywhere!

P.S. No, "you're doing it wrong" and "you're not allowed to like the NAT" are not valid responses to user needs.

> "you're not allowed to like the NAT"

Well, the bigger question might be why do they like NAT?

If it's about having a single /128 address so they can do ACLs then that's easily fixed by just lowering the CIDR number. (unless you have an ancient version of fortigate on prem, which likely doesn't work with ipv6 anyway).

If it's about not having things poking at your servers through the NAT then the "NAT" really isn't helping anything, it's the stateful firewall doing _all_ the work there and those things are entirely independent systems. -- They're just sold to consumers as a single package.

Again: "you're doing it wrong" and "you're not allowed to like the NAT" are not valid criticisms.

People like NAT because it's an easy batteries-included way to manage, secure and understand your LAN.

Taking it away and forcing them to migrate to an incompatible zoo of firewall technologies for no benefit is asinine.

> They're just sold to consumers as a single package.

Exactly. How in the world is this a bad thing now? Do we really want to make network security for the average do-it-yourself home LAN harder?

It's less of a "you're doing it wrong" or "you're not allowed to like the NAT" and a more complex "you've incorrectly attributed your protection to NAT"
Trying to separate "NAT" from "stateful firewall" is pointless and only causes pain to the end user.
If this helps you understand, NAT and stateful firewalling are often the same code base. NAT is basically just a sub-feature, purely for translation, that is it.

The NAT feature solves the problem of:

  - public ipv4 exhaustion
You get in return:

  - higher latency

  - higher user & administrator mental overhead

  - limited public ports

  - protocol breakage (TCP & IPSec)
If you _remove_ NAT:

  - users no longer have to figure out why they can’t connect to their local web/minecraft server using the public address/domain even after a port forward (the very common NAT hairpin problem)

  - do not need to google “what’s my IP” as the machine knows its address in any context

  - do not have to tunnel to a VPS, or use a VPN in cases of CGNAT (ISP provided double-NAT) to expose a server
 
  - no longer have to maintain a split DNS zone for public/private addresses of a *public* server

  - no longer have to google “how do in enable NAT traversal for this VPN”

  - no longer have to learn what addresses are OK and not OK to use locally (rfc1918)

  - no longer get confused into thinking NAT is a hard-requirement for any and all routing (ex: green admins whos only experiance is a basic pfsense install adding 3 layers deep of NAT in labs) 
These are all problems I’ve either been paid to help figure out, or done for free on forums/discord, regularly.

Removal of NAT requires no user interface change, the same “port forward” terminology AND user interfaces can remain. There can still be a port forward tab where you enter an address and port. SOHO firewalls/routers that use stuff like iptables ALREADY add both NAT and normal firewall rules, and hide that fact. The security of user devices with a proper firewall/router does not change, the exposed interfaces do not need to change, everything gets simpler. I repeat, the basic abstraction presented to users does not need to change. The only reason to insist on NAT is ignorance; removal of NAT is removal of complexity.

Nothing changes; the firewall instead says "do you want this port open to this device" [y/N]:

Personally I think this is much easier to reason about.

And all I'm saying is that the NAT part of it absolutely does nothing to defend you, it's trivially defeated, people just conflate the two.

> the firewall instead says "do you want this port open to this device" [y/N]

That's exactly what I don't want to do. I have over 20 devices in the home LAN at any given point in time; why do you want to make my life difficult for no good reason?

then don't click the "I want to open this device to incoming traffic" button?

Honestly I think you don't understand what NAT is.

Stateful firewalls basically work by watching your connections and then allowing the return traffic through. All firewalls are stateful, there are "stateless ACLS" in networking which are stupid and don't watch things; we're not talking about those ... in fact 99% of internet users will never interact with a stateless ACL.

What happens when you make a connection is that your router adds your state to it's "state table" _and_ pops open a port on your gateway to allow return traffic through, if you did not have a stateful firewall in place then the whole internet would be able to poke that port.

If you remove the NAT the only thing that happens is that your router doesn't have to pop open a port and route traffic from that port to your device, the stateful firewall stays in place, meaning that random devices on the internet CANNOT TALK to your internal network at all, unless you manually allow that, which is the same as what happens with port forwarding today.

The only thing you "lose" is that your whole house looks like one device.

You gain a significant reduction in latency, online games will work better and p2p networking (such as voip) will have significantly fewer problems, because the whole internet was designed without NAT in mind, because NAT is genuinely a terrible hack.

What do people like about NAT? I am guessing that the perceived increase in security. But perhaps there are more real or perceived advantages.
What I find common is people conflate NAT with stateful firewalling, and believe that if you lose NAT you lose all forms of edge/perimeter network security. They don't understand that you can still filter and prevent unwanted packets from reaching hosts without NAT.
Of course you can. But why would you? You're replacing something that is simple, easy to understand and works perfectly well with a nebulous something that invites user error and security nightmares.

For example, my (modest) home LAN is five routers, a NAS/media server, a media player, two "smart TVs" and dozens of notebooks and phones connected via Wi-Fi.

What do you propose? Manage a firewall on each of those devices?

I suppose you mean setting up a firewall on the WAN link to block all incoming traffic? How is that different from a NAT? Merely a lack of 'masquerade' setting on the firewall rule? What's the benefit to me and why should I care?

Or do you propose some sort of hybrid scheme to intelligently block traffic while making all my countless devices pingable from the Internet? Not in this timeline, sorry.

Your home network and a cloud datacenter aren’t comparable. Many clouds have host level firewall policies as a core feature, and anyone competent is managing them profile-style using Terraform or an equivalent. It’s really quite easy from that perspective.
> Your home network and a cloud datacenter aren’t comparable.

Of course they are. I didn't need to think about firewall automation before, and now I do. For what gain?

> anyone competent

Not an option for most people. Let's make networking and security things more foolproof, not less, okay?

Nothing new needs to be proposed. Nothing is being replaced. The current state of things is that whatever your edge device is provides actual security with stateful firewalling and translation with NAT, already. It's simple to understand because most home router products and projects like pfsense make them look like inseparable things that perform the same function. Removal of NAT won't even require a UI change for consumers because all these port forwarding UIs add both a DNAT/PNAT rule and a firewall rule already. You can keep the exact same user interfaces and "port forward" terminology when removing NAT.
> What do people like about NAT?

NAT allows people to be very dumb about networking. Either you "open a port" or you don't.

It works very well as long somebody else is managing the network for you and you just ask for stuff to happen and then that somebody else has to actually make it work.

Replace the word NAT with Firewall and all security-related statements are the same.
At home I really appreciate the NAT. I'm glad not every device has a public IP and gets hammered with attacks 24/7. It's not fail-safe but it definitely adds some security..

As for cloud, no idea what the benefit should be there.

This is what a firewall is for.
Most people use ISP provided routers at home, firewalls in those aren't necessarily great.
It would be literally the EXACT SAME firewall with IPv6 as with IPv4 NAT.

Most IPv6 routers are also IPv4 routers and behave exactly the same for both. They share the same router code, the same firewall, etc...