3 ms·

Or there is middle ground "Allow easy access with no password or username, but only from localhost" Not foolproof, but as far as I know both this and mongo di

Or there is middle ground "Allow easy access with no password or username, but only from localhost" Not foolproof, but as far as I know both this and mongo did the "bind to all ports AND allow access with no password". It was the combo that really killed it.

makmanalp 9y ago
It's easier than that - just allow two setup options that generate different config files: "development (insecure)" and "production". First one is quick and easy and relatively more unsafe, second one is fully secured based on whatever best practices. "People will find and set all the configuration options correctly" is what got us into this mess.
- brazzledazzle 9y ago
  I believe this is how Hashicorp's Vault does it.
Joeri 9y ago
That only works on a single server, so it's not an option for hdfs in anything but a toy configuration. The nodes in a hdfs cluster must be able to communicate securely, and the way you do that is to set up TLS between the nodes, with Kerberos as authentication, which is quite bothersome to get running.
dspillett 9y ago
Or if you feel you have to allow less secure defaults for initial setup (a distributed system needs to bind to something other than localhost so in those cases using that as the key won't work) make sure that a warning is displayed everywhere that an insecure default is still in operation, where "everywhere" includes to stdout when starting/refreshing services, or perhaps stderr, to log files, to the UI if you have one (on all displays not just those exposed to admin users). The warnings don't stop the initial trial of a service, but are in-your-face enough that any self respecting admin will review the matter before making the service available on a public network (at least with real data and/or on machines/accounts with access to other securables). Your users may request (in fact, some of them will demand) a setting that turns such warnings off without addressing the issues covered/ You might chose to include such a setting (at least then they make a conscious decision to not address the issues instead of later complaining your product was insecure without warning) or take the high ground and tell people who say "unless you let me get away with an insecure setup I'll use something else" that you;d rather they go use something else instead of potentially tarnishing your product by association when something goes wrong. Of course like providing good documentation, this is extra work that you may find hard to get by your paymasters at crunch time...

makmanalp 9y ago

It's easier than that - just allow two setup options that generate different config files: "development (insecure)" and "production". First one is quick and easy and relatively more unsafe, second one is fully secured based on whatever best practices. "People will find and set all the configuration options correctly" is what got us into this mess.

brazzledazzle 9y ago
I believe this is how Hashicorp's Vault does it.

Joeri 9y ago

That only works on a single server, so it's not an option for hdfs in anything but a toy configuration. The nodes in a hdfs cluster must be able to communicate securely, and the way you do that is to set up TLS between the nodes, with Kerberos as authentication, which is quite bothersome to get running.

dspillett 9y ago

Or if you feel you have to allow less secure defaults for initial setup (a distributed system needs to bind to something other than localhost so in those cases using that as the key won't work) make sure that a warning is displayed everywhere that an insecure default is still in operation, where "everywhere" includes to stdout when starting/refreshing services, or perhaps stderr, to log files, to the UI if you have one (on all displays not just those exposed to admin users). The warnings don't stop the initial trial of a service, but are in-your-face enough that any self respecting admin will review the matter before making the service available on a public network (at least with real data and/or on machines/accounts with access to other securables). Your users may request (in fact, some of them will demand) a setting that turns such warnings off without addressing the issues covered/ You might chose to include such a setting (at least then they make a conscious decision to not address the issues instead of later complaining your product was insecure without warning) or take the high ground and tell people who say "unless you let me get away with an insecure setup I'll use something else" that you;d rather they go use something else instead of potentially tarnishing your product by association when something goes wrong. Of course like providing good documentation, this is extra work that you may find hard to get by your paymasters at crunch time...