Cockroach: security: maybe enable password auth in insecure mode

[mberhault]

We have a pretty sizable discrepancy between secure and insecure mode. Specifically: in insecure mode anyone can do anything without any sort of authentication.

I think we should consider allowing password auth in insecure mode. This would allow people to run insecure mode if they are sufficiently confident that they are in a "secure" environment while still providing user authentication.

We would also need to allow password authentication for root. We can probably keep it disabled in secure mode.

We should still warn loudly when running under insecure mode as there's no encryption.

@bdarnell, @petermattis: thoughts?

edit feb 2020: issue subsumed by #44842.

[bdarnell]

Even if we used password auth in the pgwire protocol in insecure mode, anyone would still be able to do anything they wanted to without authentication by using the intra-node GRPC interfaces.

From https://github.com/cockroachdb/cockroach/pull/15724#issuecomment-301512716

Even if we supported a better mode of authentication for pgwire, the bigger problem is that the inter-node GRPC connections are secured only by TLS certs, allowing for trivial root/node-level access when TLS is disabled. We would need non-TLS authentication for GRPC in addition to better pgwire password authentication to allow --insecure to provide even partial security. Until we change the GRPC auth, adding passwords to --insecure mode just gives a false sense of security.

[mberhault]

Agreed, but this wouldn't be for security purposes. Any bad actors with sufficient access to the network/machines could do anything anyway. As would someone willing to use the grpc connections.

Authentication is not always about preventing bad actors, but often about logical separation of users. If root is permissionless, people will run everything under that and risk accidentally destroying their database (like the good old days of everyone using gfsuser=gfsroot).

[bdarnell]

That may be how you would think of passwords in insecure mode, but I think it would be more common for users to think of them as a real security mechanism. I think we want users to be frightened by the lack of passwords to motivate them to set up certificates properly.

[mberhault]

Ok, fair enough. Closing.

[bladefist]

It seems like there is no wiggle room on this, but I'll throw my opinion in the ring...

We run our database behind strict firewall rules. If you can ping our database server, you probably already have our passwords and certs.

I'd like a cert-free mode with user/password authentication like every other database out there.

Thanks.

[bdarnell]

This came up again in #24061; reopening this to preserve context instead.

[ivan]

+1 because I would prefer to secure traffic between my nodes with WireGuard and skip the extra TLS layer and cert deployment.

[Samusername]

In a k8s system (in a product), all traffic between nodes will be encrypted by other means. It is the official way to encrypt traffic there.
So, when CockroachDB forces to use additional unneccessary encryption, then things start to slow down. How does it work with CockroachDB, to avoid double encryption? Is it able to detect / avoid double encryption. If not, then it should be possible to turn off encrypted traffic mode from CockroachDB?

[Bessonov]

Any news on this? With istio its not necessary to encrypt on CRDB level. See old blog post:
https://istio.io/blog/2017/0.1-auth/

[Samusername]

Following is not a solution, I think.

It is possible to set sslmode to "disable".
https://www.cockroachlabs.com/docs/stable/connection-parameters.html

jdbc:postgresql://[ip]:[port]/[dbschema]?sslmode=disable

CockroachDB can be started in insecure mode. Connection strings can use the above setting. certs should not be needed in that case.

But now passwords are not mandatory? So, it is not a solution?

[mberhault]

@rolandcrosby for triage. This would be the "make insecure mode more sane, or introduce something in-between". Not a small ask.

[MichaelHudgins]

Would love to have the option of insecure mode with usernames and passwords.
I would like to be able to run cockroachdb in kubernetes with istio or another service mesh handling the encryption and network configuration rules, but with the current insecure mode I can't limit any service communicating with cockroach from getting root privileges.

[knz]

We have a path forward on this now.
Starting with 20.1, CockroachDB supports non-TLS connections via the local unix socket in secure mode and will authenticate using passwords.

This can be exploited to create insecure network listeners with password auth, for example using a TCP-to-unix socket proxy (including plain nc).

[knz]

Given that we now have a solution I am going to close this issue.

@jseldess my previous comment with the solution needs to be propagated to docs. If you were to create an issue for it, I could send a docs PR.
(I would take that opportunity to audit the other auth changes in 20.1.)

[jseldess]

Added your comment to https://github.com/cockroachdb/docs/issues/5957, which is the relevant docs issue. Please sync with @Amruta-Ranade on this. I'd prefer that you enable her to write this up, if possible.

[karlseguin]

This still isn't ideal. Given an already secure network, the option to get passwords is either to run in secure mode and deal with the certificate stuff, or "exploit" this new feature and add another moving piece (a proxy).

What's the deal with letting --insecure use passwords? Is the concern that people setting up cockroachdb and specify an --insecure flag are somehow still under the illusion that the password is secure?

This seems like a good intention that (a) probably doesn't do anything except annoy users and (b) misaligned with modern security best practices (encryption at the network, not application, layer) and (c) misaligned with how other database vendors do this.

[knz]

What's the deal with letting --insecure use passwords? Is the concern that people setting up cockroachdb and specify an --insecure flag are somehow still under the illusion that the password is secure?

--insecure disables _all_ security checks internally inside CockroachDB:

• node-to-node connections
• access to internal privileged APIs
• access to administrative APIs
• access to the admin UI
• shutting down the cluster etc

The reason why this is available at all is to enable unit tests to operate a cluster without having to deal with security.

Availability to users was envisioned as a second thought to enable an "escape hatch" in case users painted themselves in a corner by locking themselves out of administrating their cluster.

I think what you want is the ability to create a non-TLS client listener on TCP in secure mode, subject to the HBA configuration rules (hostssl vs hostnossl). That would be a reasonable feature ask but a separate issue.

I'll file it for you