Earlier quoted context omitted.
> "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…
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 n…
Software Infrastructure 2.0: A Wishlist
171–180 of 202 posts
Re: Software Infrastructure 2.0: A Wishlist
#172Earlier quoted context omitted.
Virtualization, no. A hypervisor running a Windows kernel and a Linux kernel side by side is not about capability-based security. You can even see it like cap-based security approach: VMs only see what the hypervisor gave them, and have no way to refer to anything that the hypervisor did not pass to them. Containers , yes. They are a pure namespacing trick, and can be replaces by cap-based security completely.
Emulation and API compatibility layers can be done in more ways than an hypervisor-based VM. And many of those other ways perform better.
Re: Software Infrastructure 2.0: A Wishlist
#173Virtualization eventually will be seen as the unnecessary layer added to make up for operating systems that lack capability based security. It's going to take a decade to refactor things to remove that layer. Once done, you'll be able to safely run a process against a list of resources.
It's not just security. There's incompatible dependencies. Virtualization allows you to run Windows and Linux on the same server, 40 different C libraries with potentially incompatible ABIs, across X time zones and Y locales, and they'll all work. You can provide the same level of replication and separation of dependencies in an OS, but at a certain point you're just creating the same thing as a hypervisor and callin…
Re: Software Infrastructure 2.0: A Wishlist
#174Earlier quoted context omitted.
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).
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 nee…
Re: Software Infrastructure 2.0: A Wishlist
#175Earlier quoted context omitted.
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 fe…
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…
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.]
Re: Software Infrastructure 2.0: A Wishlist
#176Earlier quoted context omitted.
Emulation and API compatibility layers can be done in more ways than an hypervisor-based VM. And many of those other ways perform better.
What are they? Why the hypervisor approach is the standard then?
Hypervisor is not the standard, it's one of the many ways people do it right now.
Re: Software Infrastructure 2.0: A Wishlist
#177Earlier quoted context omitted.
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).
Re: Software Infrastructure 2.0: A Wishlist
#178Earlier quoted context omitted.
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.
Re: Software Infrastructure 2.0: A Wishlist
#179Virtualization eventually will be seen as the unnecessary layer added to make up for operating systems that lack capability based security. It's going to take a decade to refactor things to remove that layer. Once done, you'll be able to safely run a process against a list of resources.
Virtualization, no. A hypervisor running a Windows kernel and a Linux kernel side by side is not about capability-based security. You can even see it like cap-based security approach: VMs only see what the hypervisor gave them, and have no way to refer to anything that the hypervisor did not pass to them. Containers , yes. They are a pure namespacing trick, and can be replaces by cap-based security completely.
It allows you to divide up physical computing power across multiple people/organizations etc.
Containers make this kind of distinction far more hazy.
Re: Software Infrastructure 2.0: A Wishlist
#180My biggest problem with modern infrastructure is how much resources they use for simple things. They scale upwards, but they don't scale down. I tried OpenFAAS in Kubernetes, to see if I could run simple lambda like loads. Default setup took north of 8 Gb of memory! I just want efficient and simple microservices infrastructure, that doesn't hog 8 Gb of memory to run a simple functions or small microservices.
Proper isolation that is battle tested, rock solid operating system that doesn't try to reinvent the wheel every 3 years and as an added bonus you get ZFS which makes development, upgrades and maintenance a breeze thanks to proper snapshotting.
We did this a simple side project, originally written in PHP, then python and now go and it has been rock solid and easily scalable for atleast a decade or more.
Heck, you can even run linux compatible binaries in linux compatible jails nowadays[0].