using the demo cluster from a different shell is not something demo was designed for -- we do not document it and we never intended this to be a thing. If you want a multi-session cluster, use cockroach start-single-node
.
there are too many features that are plainly disabled / broken in the insecure mode. That's the reason why We do not want the insecure mode, like, at all. The insecure should only be used by cockroachdb developers and not even become available in production builds shipped to users/customers.
Something else you should consider here is that if you have a multi-user system, or say some background apps running on the same machine as your demo
shell and it's insecure, it's possible for malware to (ab)use the crdb software and cause nefarious effects on your user account.
There's no track record of applications built to run on a personal laptop that start non-authenticated services over the network. This is just "not done" in the entire industry. FWIW this is exactly the kind of practice that makes people very critical of Zoom atm because of a similar flaw they had in their software a year or two ago. We don't want to be in the same reputation ball park.
--
You received this message because you are subscribed to the Google Groups "CockroachDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cockroach-db...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cockroach-db/CAJg57DiEjwqzPOL%2BRUwwhK0jQiQy4c%2B-EpJ5aBtbRW27dq39gg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cockroach-db/CACJj5QmwD6baB%3DgbXkoEqM-wpriLBR3SWxQ0q7A2_aJyoxq2vA%40mail.gmail.com.
As Marc’s residual echo in security-related matters, I need to warn against enabling IAM features (roles and privileges) in the insecure mode because he believed that it gives people the false sense of security about their clusters when in reality, the clusters aren’t really secure without TLS certs stuff.
FWIW, I like the idea of using `./cockroach demo --insecure=false` to learn about CRDB IAM features.
To view this discussion on the web visit https://groups.google.com/d/msgid/cockroach-db/CAPucRz7y1BPjw9DPzmPNX1RvcNM9d8phYrzxOTTVOMCdeOjESw%40mail.gmail.com.
As Marc’s residual echo in security-related matters, I need to warn against enabling IAM features (roles and privileges) in the insecure mode because he believed that it gives people the false sense of security about their clusters when in reality, the clusters aren’t really secure without TLS certs stuff.
-- Raphael 'kena' Poss
There's also an elephant in the room:
- YOU cockroachdb developers should have no issue creating a shell alias that aliases `cockroach demo` to `cockroach demo --insecure` (THIS WORKS TODAY)
- 99% of users exposed to 'cockroach demo' will only use it to
enter some SQL and try out the admin UI. That user journey works
PERFECTLY now.
-- Raphael 'kena' Poss
- YOU cockroachdb developers should have no issue creating a shell alias that aliases `cockroach demo` to `cockroach demo --insecure` (THIS WORKS TODAY)
or better yet put COCKROACH_INSECURE=1 in your shell config.
This works already like it always has.
-- Raphael 'kena' Poss
-- Raphael 'kena' Poss
--
You received this message because you are subscribed to the Google Groups "CockroachDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cockroach-db...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cockroach-db/f8fdd515-8181-a084-2aaf-f833a750b8cc%40cockroachlabs.com.
maybe we can put a token in the printed URI that logs you in directly (e.g. printing “Admin UI URL (automatically logged in as root)”
ooh I like that! that's doable.
Also heads up that Rohan has a PR in the pipeline to do exactly that with the SQL URLs too.
--Raphael 'kena' Poss
--
You received this message because you are subscribed to the Google Groups "CockroachDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cockroach-db...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cockroach-db/90b31a56-6ae9-d13f-14e3-35d5ba8bb710%40cockroachlabs.com.
I just went back through the demo and realized that I misunderstood that we are indeed already binding to localhost for the current insecure demo instructions. (So that doesn't represent a change from what we are already doing). Apologies for the confusion all.
Regarding local unix sockets. I'm fairly certain we already support this in 19.2 (at least) but Raphael can validate this.It sounds like the biggest complaint is that certificates are hard and a new user shouldn't have to fight with them. This is actively being addressed on the 20.2 roadmap where we will separate out different certificate usages so that the database can default to secure mode and behave near identically from a user standpoint to what today we have as insecure mode.Related and to what David Taylor raised, I've heard estimates that as high as 60% of our paying on-prem customers deploy in insecure mode because the certificate user experience is so bad. This is on our radar and we will make this better!Aaron
I just went back through the demo and realized that I misunderstood that we are indeed already binding to localhost for the current insecure demo instructions. (So that doesn't represent a change from what we are already doing). Apologies for the confusion all.
Well, so given that it's just localhost, where do you stand on the issue?
localhost + non-authenticated is what Zoom was doing and what got them in trouble.
The vulnerability is relative to other apps on the same system. They all have access to the localhost listeners.
Consider that a new user of a database is likely to enter data/values in their test database that are valuable to them: contacts, e-mail addresses, maybe passwords. If you allow concurrent apps to scrape things without friction, that data can make its way anywhere. That's the kind of risk I'm thinking about.
A small layer of authentication (even with a known password) reduces this risk. With a fixed password you're only vulnerable to malware designed specifically for cockroachdb.
The situation would be all-around better by providing the auth token in the URL, like suggested elsewhere. The SQL URLs will get their cert details embedded via https://github.com/cockroachdb/cockroach/pull/46913 thanks to Rohan.
If we combine that PR with Andrew's suggestion to place the certs
in a place that more nicely named (e.g. ~/.cockroach_certs) we can
get a lot of mileage this way.
-- Raphael 'kena' Poss
On 02-04-2020 18:10, Andrei Matei wrote:
I just went back through the demo and realized that I misunderstood that we are indeed already binding to localhost for the current insecure demo instructions. (So that doesn't represent a change from what we are already doing). Apologies for the confusion all.
Well, so given that it's just localhost, where do you stand on the issue?localhost + non-authenticated is what Zoom was doing and what got them in trouble.
The vulnerability is relative to other apps on the same system. They all have access to the localhost listeners.
Consider that a new user of a database is likely to enter data/values in their test database that are valuable to them: contacts, e-mail addresses, maybe passwords. If you allow concurrent apps to scrape things without friction, that data can make its way anywhere. That's the kind of risk I'm thinking about.
A small layer of authentication (even with a known password) reduces this risk. With a fixed password you're only vulnerable to malware designed specifically for cockroachdb.
--
You received this message because you are subscribed to the Google Groups "CockroachDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cockroach-db...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cockroach-db/d67a184e-2753-a44c-ccdf-3aacb2409937%40cockroachlabs.com.
Well, so given that it's just localhost, where do you stand on the issue?
That said, I still think we _should_ be running secure by default though, if not for the security of the user’s local machine so much as because the point of demo, and any other time we fire up nodes or clusters to try things, is to be representative of what the to expect, so the closer to the real thing it is, the better. Aside: IMO the only choice you should make at startup of a new node is if you want to provide your own certs or let the cluster configure TLS itself -- `—insecure` should be forgotten, relegated to some obscure flag for a raspberry pi which don’t have hardware AES or something and we should be use and experience the system the same way users in production do.
Security is the last thing I care about.
Regarding concerns about making the user environment less secure by running our demo. One of the fundamental assumptions I've heard repeatedly from our engineers is that "root" access to the database means you are also trusted as an administrator of the running system. We can discuss the merits of that assumption on another thread, but it is built into the way we currently handle and enforce permissions within CRDB.
You don't seem to be phased by the fact that the client certs are there for everybody to use. It's not like we're handing out certs from Consul or anything; the certs are right there on the owned machine. So can you please qualify even more than you did the risk that you're mitigating?
So here's the thing: file-based isolation between apps is
relatively good in the unix world.
Permissions have some issues, but your OS is good at preventing access to files when the ownership/perms don't match.
That's what's used in Android and macOS: different apps run "under" different system-level principals and can't blindly access each others _files_ without some disclaimer (or permission requests) upfront.
That's not true of networking though. An app running as user X can connect to the network services of user Y on the same machine. It's the responsibility of the network service to enforce authn/authz. TCP local listeners are "free for all" and public to every app on the local machine.
(Yes I know there is some nuance here but as always - unless we
are very careful at spelling out that nuance in our docs /
warnings, it's not good to expose our users to an element of
surprise.)
-- Raphael 'kena' Poss
I would caution against relying on docs/warnings to communicate security nuances. We already have a significantly complex UX that users have to piece together across the doc set. Adding nuanced warnings is more of a cover-all-bases strategy than one that can guarantee customer success.
--
You received this message because you are subscribed to the Google Groups "CockroachDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cockroach-db...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cockroach-db/9bbbcee5-b813-1967-bfa9-4c81745ab570%40cockroachlabs.com.
Well, so given that it's just localhost, where do you stand on the issue?David beat me to the send button.That said, I still think we _should_ be running secure by default though, if not for the security of the user’s local machine so much as because the point of demo, and any other time we fire up nodes or clusters to try things, is to be representative of what the to expect, so the closer to the real thing it is, the better. Aside: IMO the only choice you should make at startup of a new node is if you want to provide your own certs or let the cluster configure TLS itself -- `—insecure` should be forgotten, relegated to some obscure flag for a raspberry pi which don’t have hardware AES or something and we should be use and experience the system the same way users in production do.I also think we should dogfood secure mode during the 20.2 development process so we can experience, identify, and FIX the user experience here. As long as we internally dodge the usability nightmare around "Secure Mode" we will continue to underinvest in its UX.
My opinion on dogfooding is that the point of cockroach demo is not to be a place to dogfood production experience.
I think this thread has revealed there is a diversity of opinions on this particular point. Your opinion (and thus UX requirements) is valid; but the other opinion is valid too.
As a "demo", it's supposed to [...] remov[e] all the roadblocks that can be removed. I don't think that production considerations such as certificates should be part of it
Agreed. At least there shouldn't be anything for the user to even
think about -- even if they request the secure mode.
(That was top and foremost reason to remove TLS for the admin UI, regardless of whether secure mode is enabled or not.)
As we were discussing this thread, the following already happened:
1) the SQL URL printed out by the SQL shell when the secure mode is requested now embeds the cert details, so that you can point your concurrent SQL clients to the thing and get proper TLS auth.2) I'm investigating how to skip certs entirely by doing the thing with the unix socket instead (all client apps support that because it's standard with pg)
As far as us, developers, being driven to improve the usability of certs, or such, by having demo use them, I think that's not going to happen.
Given that you've not been earmarked to solve the UX problem,
your position on this is OK. :-)
Meanwhile there will be cert improvements throughout the
20.2 release cycle. It's important for folk to provide continuous
feedback on those improvements, so that we can tweak them towards
the best UX possible. Therefore we do have a collective incentive
to have at least some % of our team trying it out regularly.
Finally: my opinion is swayed by David's argument that we should proceed more conservatively for the 20.1 release regardless of our security roadmap, and thus I am now moderately in favor of flipping the default for 20.1.
Just for 20.1 though -- we do need to dogfood, and there's this
env var to move forward until we fix the brokenness.
-- Raphael 'kena' Poss