Admin UI Authentication

If I understand the docs correctly, there is currently no way to authorise access to the Admin UI? There is a mention of “authentication” in the introductory paragraph, but no further explanation down below.

This makes it impossible to use the Admin UI in a public cloud scenario.

Also, can I use “real” certificates for securing crdb or do I have to use the self-generated ones?

Ulrich

We are working on authentication for the admin UI for version 1.1; for now you’ll just have to firewall off the port.

In theory you should be able to use “real” certificates but I don’t think we’ve tried it. We have some required attributes on the certificates and I’m not sure if they are compatible with the way public certificates are issued.

Are there any other security considerations for 1.0 users? Perhaps it would be a good idea to have a page like that: https://docs.docker.com/engine/security/security/

Ulrich

Yeah, we could use some better documentation here. Some quick notes:

  • Prefer certificate-based authentication to passwords.
  • Configure your clients to verify the server’s certificate against the CA to prevent MITM attacks (do this whether you authenticate with passwords or client certs).
  • Be careful with your TLS keys because all the authentication rests on them. We do not yet support key revocation so the only remedy for a compromised key is to rotate to a whole new CA and replace all certs cluster-wide.
  • The admin UI is accessible by anyone who can access it on the network. It is currently read-only, but may leak sensitive data (primarily via the log viewer) so it may need to be firewalled off. This will change in version 1.1.
    • Passing --logtostderr has the side effect of disabling the log viewer, which may be worthwhile if you’re concerned about this leak.

It is possible to put a proxy in front of the Admin UI that requires authentication, so I would not call it impossible to use in a public cloud scenario.

Thanks for the pointers, much appreciated. I haven’t yet thought about how clients connect to crdb, but I’ll be using the JDBC driver from the PostgreSQL project and I believe that has all the security bells and whistles including cert verification.

I’m naturally a bit reluctant to run haproxy (or similar) just for the Admin UI on a $10 cloud host with 1G of RAM. It’ll be interesting enough to see whether I can get crdb to work with modest loads in that kind of environment :slight_smile:

Ulrich

I’m trying to figure out how authentication to the admin UI works and it’s driving me a little crazy now that it seems that anyone can access all of the information for a cluster, including the table schemas and lists of all the users, through the admin UI without any authentication. I feel like l must be missing something.

I started up a node in secure mode on a VM but the cluster’s information is publicly visible at https://the-vm-ip:8080

Yes, that’s true. The metadata you’ve described (but not any actual data) is available to anyone on the network. We recommend using firewall rules to ensure that this port is not publicly accessible.

In version 2.1 we will have a proper access control scheme to limit access to the admin UI.

Got it—looking forward to that improvement in v2.1.

Another feature (probably quite easy to implement) would be to disable the admin UI for a node when starting it up with a flag like “–no-admin-ui”

@bdarnell
Actually, a feature to start nodes without the admin UI server is something I’d really love to see. This would even help with efficiency (a little) on each node by not having to listen on a port and run an HTTP server.

A quick fix for this as @jlauro was saying is to use a proxy infront of your admin ui. I myself use nginx configured with basic http auth. or if you want something a bit more secure you can use cloudfare access, im currently tinkering with this option.