Concerns about using the common name "root" in our root client cert

[a-robinson]

As discussed at https://youtu.be/JMCCeAb9eY4?t=1h41s, using the common name "root" for the root client inside a Kubernetes cluster is a bad idea, because it could potentially give the certificate root access to the Kubernetes cluster itself (given that we're using the Kubernetes cluster's CA). We should try to scope this down using some other common name if possible.

@mberhault

[mberhault]

Given the fact that root is a hard-coded user in cockroach, I'm not entirely sure this is feasible. We could create a less common username and add it to the newly-introduced admin role (eg: crdb-root) and grant a certificate for that, but there's still nothing preventing you from creating a certificate for root and leaking it.

[bdarnell]

I think the point is that we should mark our user certificates in some way instead of just interpreting the common name on any cert from our CA as a username. (if this is an issue, it sounds like kubernetes may have made the same mistake).

[mberhault]

We have to use the CN with exactly the user name, or we're not longer pg compatible. see: https://www.postgresql.org/docs/10/static/auth-methods.html#AUTH-CERT

If k8s does the same, and only requires a valid certificate chain and the client auth capability, then there's not much we can do in the certificate itself.