Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

security: maybe enable password auth in insecure mode #16188

Open
mberhault opened this issue May 27, 2017 · 10 comments

Comments

8 participants
@mberhault
Copy link
Contributor

commented May 27, 2017

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?

@mberhault mberhault self-assigned this May 27, 2017

@bdarnell

This comment has been minimized.

Copy link
Member

commented May 27, 2017

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 #15724 (comment)

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

This comment has been minimized.

Copy link
Contributor Author

commented May 27, 2017

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

This comment has been minimized.

Copy link
Member

commented May 27, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented May 27, 2017

Ok, fair enough. Closing.

@mberhault mberhault closed this May 27, 2017

@bladefist

This comment has been minimized.

Copy link

commented Feb 5, 2018

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 comment has been minimized.

Copy link
Member

commented Mar 20, 2018

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

@bdarnell bdarnell reopened this Mar 20, 2018

@knz knz added the A-cli label Apr 30, 2018

@knz knz added this to To do in Command Line Interface (CLI) via automation Apr 30, 2018

@knz knz added the C-enhancement label Apr 30, 2018

@ivan

This comment has been minimized.

Copy link
Contributor

commented Jul 10, 2018

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

@Samusername

This comment has been minimized.

Copy link

commented Apr 10, 2019

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

This comment has been minimized.

Copy link

commented May 20, 2019

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

This comment has been minimized.

Copy link

commented May 23, 2019

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.