add --cert-principal-map #7104

Amruta-Ranade · 2020-04-08T23:33:32Z

cc @piyush-singh for visibility: The docs and the review comments might help guide your acceptance testing efforts :)

cockroach-teamcity · 2020-04-08T23:33:40Z

This change is

cockroach-teamcity · 2020-04-08T23:41:34Z

Online preview: http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/33ca546f67f13ba4ae4f74011a9e38c4bd6e081f/

Edited pages:

v20.1/create-security-certificates-openssl.md

petermattis

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @Amruta-Ranade)

v20.1/create-security-certificates-openssl.md, line 77 at r1 (raw file):

    {% include copy-clipboard.html %}
    ~~~ shell
    $ mkdir node-certs client-certs my-safe-directory

Is there a reason for using separate directories for the node and client certs? @dbist needed to do this in testing because of limitations in the cockroach cert commands, but it shouldn't be necessary for the instructions here.

v20.1/create-security-certificates-openssl.md, line 189 at r1 (raw file):

    [ distinguished_name ]
    organizationName = Cockroach
    commonName = DNS:<node-hostname>,DNS:<node-domain>,IP:<IP Address>

My understanding is that the commonName field is but a single field. If you specify multiple names like this, the first is stored in the commonName field and the others are stored in the subjectAltName fields. I'm not sure how this actually plays out with the OpenSSL configuration file, though. So what you have may actually be correct, though it is a bit strange to have to specify the same fields in both commonName and subjectAltName. That is incompatible with my mental model.

Cc @aaron-crl for confirmation.

v20.1/create-security-certificates-openssl.md, line 345 at r1 (raw file):

    {% include copy-clipboard.html %}
    ~~~ shell
    $ cockroach start-single-node --certs-dir=node-certs --cert-principal-map=node.crdb.io:node --background

The value of node.crdb.io is dependent on how the cert was created. Perhaps this should be <node-domain>.

Amruta-Ranade

TFTR, @petermattis ! Does the overall approach make sense? Is it okay to document only the principal mapping approach and not to document the commonName=node approach?

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @aaron-crl, @dbist, and @petermattis)

v20.1/create-security-certificates-openssl.md, line 77 at r1 (raw file):

Previously, petermattis (Peter Mattis) wrote…

Is there a reason for using separate directories for the node and client certs? @dbist needed to do this in testing because of limitations in the cockroach cert commands, but it shouldn't be necessary for the instructions here.

IIRC, we ran into the same issues with openssl commands as well. Will retry the steps without separate directories and report back.

v20.1/create-security-certificates-openssl.md, line 189 at r1 (raw file):

Previously, petermattis (Peter Mattis) wrote…

My understanding is that the commonName field is but a single field. If you specify multiple names like this, the first is stored in the commonName field and the others are stored in the subjectAltName fields. I'm not sure how this actually plays out with the OpenSSL configuration file, though. So what you have may actually be correct, though it is a bit strange to have to specify the same fields in both commonName and subjectAltName. That is incompatible with my mental model.

Cc @aaron-crl for confirmation.

Yeah, I am not sure of this either. I was under the impression that commonName is a single-value field, but couldn't figure out which value should it have and what should go in the subjectAltName. Should <node-domain> be in the commonName field and everything else in subjectAltName?

v20.1/create-security-certificates-openssl.md, line 345 at r1 (raw file):

Previously, petermattis (Peter Mattis) wrote…

The value of node.crdb.io is dependent on how the cert was created. Perhaps this should be <node-domain>.

Yep. Sorry. Fixing now.

Amruta-Ranade

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @aaron-crl, @dbist, and @petermattis)

v20.1/create-security-certificates-openssl.md, line 77 at r1 (raw file):

Previously, Amruta-Ranade (Amruta Ranade) wrote…

IIRC, we ran into the same issues with openssl commands as well. Will retry the steps without separate directories and report back.

Update: Single directory didn't work :(
Retried with separate directories and it worked!

v20.1/create-security-certificates-openssl.md, line 189 at r1 (raw file):

Previously, Amruta-Ranade (Amruta Ranade) wrote…

Yeah, I am not sure of this either. I was under the impression that commonName is a single-value field, but couldn't figure out which value should it have and what should go in the subjectAltName. Should <node-domain> be in the commonName field and everything else in subjectAltName?

Update: Tried <node-domain> in the commonName field and everything else in subjectAltName and it didn't work.
Tried <node-domain> be in the commonName field and everything (including <node-domain>) in subjectAltName and that worked!

commonName = DNS:node.crdb.io

[ extensions ]
subjectAltName = DNS:node.crdb.io,DNS:localhost,IP:127.0.0.1

cockroach-teamcity · 2020-04-09T00:47:52Z

Online preview: http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/951e3db58504cc0b1680b93d5007d008a74052ad/

Edited pages:

Amruta-Ranade · 2020-04-09T01:51:49Z

@dbist via Slack:
Maybe adding example of first client with root and second client with maxroach user is useful? Just the fact you need create user maxroach; not to be forgotten

Update: Done.

aaron-crl

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @dbist and @petermattis)

v20.1/create-security-certificates-openssl.md, line 189 at r1 (raw file):

Previously, Amruta-Ranade (Amruta Ranade) wrote…

Update: Tried <node-domain> in the commonName field and everything else in subjectAltName and it didn't work.
Tried <node-domain> be in the commonName field and everything (including <node-domain>) in subjectAltName and that worked!
commonName = DNS:node.crdb.io

[ extensions ]
subjectAltName = DNS:node.crdb.io,DNS:localhost,IP:127.0.0.1

After poking at this, I think this is borne out of how certificate use changed per RFC 5280.

commonName used to be is expected to represent the dns hostname or IP of a server but ultimately it's just a printable string.

The subjectAltName extension is meant to eventually replace commonName because it adds typing to the subject value.

Today, it is incumbent on the consumer to check both fields as the RFC states "The subject name MAY be
carried in the subject field and/or the subjectAltName extension."

We know that CRDB now can do this courtesy of cockroachdb/cockroach#45819 meaning that the value of the commonName field doesn't actually matter as long as the correct value(s) appear in the subjectAltName(s).

The configuration immediately above would result in the commonName being set to "DNS:node.crdb.io" which isn't a valid URL, but because it is correctly represented as a DNS entry in subjectAltName as node.crdb.io it doesn't matter.

It doesn't hurt anything to have it in both places today but it doesn't help either.

On an aside according to RFC 5280 "If subject naming information is present only in the subjectAltName extension (e.g., a key bound only to an email address or URI), then the subject name MUST be an empty sequence and the subjectAltName extension MUST be critical."

I was able to get OpenSSL to generate a certificate that matches this pattern with the below modifications but haven't yet had time to test it against the database.

In ca.cnf replace "commonName = supplied" with "commonName = optional"

For 'node.cnf' I removed the commonName from the distinguished_name section and set subjectAltName as critical.

# OpenSSL node configuration file
[ req ]
prompt=no
distinguished_name = distinguished_name
req_extensions = extensions

[ distinguished_name ]
organizationName = Cockroach

[ extensions ]
subjectAltName = critical,DNS:localhost,DNS:node,IP:0.0.0.0

Amruta-Ranade · 2020-04-09T17:22:29Z

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @dbist and @petermattis)

v20.1/create-security-certificates-openssl.md, line 189 at r1 (raw file):

Previously, Amruta-Ranade (Amruta Ranade) wrote…
After poking at this, I think this is borne out of how certificate use changed per RFC 5280.

commonName used to be is expected to represent the dns hostname or IP of a server but ultimately it's just a printable string.

The subjectAltName extension is meant to eventually replace commonName because it adds typing to the subject value.

Today, it is incumbent on the consumer to check both fields as the RFC states "The subject name MAY be carried in the subject field and/or the subjectAltName extension."

We know that CRDB now can do this courtesy of cockroachdb/cockroach#45819 meaning that the value of the commonName field doesn't actually matter as long as the correct value(s) appear in the subjectAltName(s).

The configuration immediately above would result in the commonName being set to "DNS:node.crdb.io" which isn't a valid URL, but because it is correctly represented as a DNS entry in subjectAltName as node.crdb.io it doesn't matter.

It doesn't hurt anything to have it in both places today but it doesn't help either.

On an aside according to RFC 5280 "If subject naming information is present only in the subjectAltName extension (e.g., a key bound only to an email address or URI), then the subject name MUST be an empty sequence and the subjectAltName extension MUST be critical."

I was able to get OpenSSL to generate a certificate that matches this pattern with the below modifications but haven't yet had time to test it against the database.

In ca.cnf replace "commonName = supplied" with "commonName = optional"

For 'node.cnf' I removed the commonName from the distinguished_name section and set subjectAltName as critical.
# OpenSSL node configuration file
[ req ]
prompt=no
distinguished_name = distinguished_name
req_extensions = extensions

[ distinguished_name ]
organizationName = Cockroach

[ extensions ]
subjectAltName = critical,DNS:localhost,DNS:node,IP:0.0.0.0

This is confusing :)
For now, I feel it's safer to recommend setting all values in both commonName and subjectAltName, especially since things seem to be in flux. Is that okay?

aaron-crl

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @dbist and @petermattis)

v20.1/create-security-certificates-openssl.md, line 189 at r1 (raw file):

Previously, Amruta-Ranade (Amruta Ranade) wrote…

This is confusing :) For now, I feel it's safer to recommend setting all values in both commonName and subjectAltName, especially since things seem to be in flux. Is that okay?

I think "in flux is relative" unfortunately. RFC 5280 is 12 years old now, but commonName is still widely used.

As for setting all values in both, we can't, at least not functionally. The best we can do is pick on to set in commonName and then either set it again with the others in subjectAltName or omit it there. Neither of which feel very satisfying to me.

I think moving all values to the subjectAltName extension is the "correct" security decision - and simpler in the long run. It's just not the way we've done things in the past. open to other thoughts though.

cockroach-teamcity · 2020-04-09T20:41:26Z

Online preview: http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/3086c5e5dd73a313d4248d6832ad258014d0e5b5/

Edited pages:

Amruta-Ranade

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @dbist and @petermattis)

v20.1/create-security-certificates-openssl.md, line 189 at r1 (raw file):

Previously, aaron-crl wrote…

I think "in flux is relative" unfortunately. RFC 5280 is 12 years old now, but commonName is still widely used.

As for setting all values in both, we can't, at least not functionally. The best we can do is pick on to set in commonName and then either set it again with the others in subjectAltName or omit it there. Neither of which feel very satisfying to me.

I think moving all values to the subjectAltName extension is the "correct" security decision - and simpler in the long run. It's just not the way we've done things in the past. open to other thoughts though.

Tried the steps we discussed and they worked! Updated the doc :)

dbist

I went through the steps without a hitch. I think the following nits will improve the overall document.

In the root client creation section, rephrase repeat steps 1-5 for each additional client to refer to step 5. creating cert for clients other than root.
rename Step 5 to say: create cert for client other than root.
In step 5.1, creating additional clients, rephrase create client.cnf to create or reuse the one used for root user. It is the same content, just note to change commonName for each additional user.
in the step to start cluster, I'd include <fqdn,nodename>. Check with others on the thoughts?
In Peter's document, he provided a step to introspect certificates, I think it's valuable to add here for both client and node certs at the end of each respective certificate creation sections.
openssl x509 -in node-certs/node.crt -text | grep "X509v3 Subject Alternative Name" -A 1

            X509v3 Subject Alternative Name: critical
                DNS:localhost, DNS:node.example.com, IP Address:127.0.0.1

openssl x509 -in client-certs/client.root.crt -text | grep CN=

        Issuer: O=Cockroach, CN=Cockroach CA
        Subject: O=Cockroach, CN=root

openssl x509 -in client-certs/client.roach.crt -text | grep CN=

        Issuer: O=Cockroach, CN=Cockroach CA
        Subject: O=Cockroach, CN=roach

finally, add a step to use the client cert in the very last step
cockroach sql --certs-dir=client-certs --user=roach

Amruta-Ranade · 2020-04-10T16:55:34Z

I went through the steps without a hitch. I think the following nits will improve the overall document.

In the root client creation section, rephrase repeat steps 1-5 for each additional client to refer to step 5. creating cert for clients other than root.

Oh, I had a question about this as I was writing it and forgot to ask it in the channel: Should I just delete steps 5 and 6 from the "create certs for root" section? We expect the users to connect to the cluster using their local machine using the root cert, right? Not upload the cert anywhere?

rename Step 5 to say: create cert for client other than root.

Done. Renamed to "Create the certificate and key pair for a non-root client"

In step 5.1, creating additional clients, rephrase create client.cnf to create or reuse the one used for root user. It is the same content, just note to change commonName for each additional user.

Good catch. I meant to say "edit" instead of "create". Is that the right way though? Should they reuse the file or create a new one for each client?

in the step to start cluster, I'd include <fqdn,nodename>. Check with others on the thoughts?

cc @aaron-crl for thoughts

In Peter's document, he provided a step to introspect certificates, I think it's valuable to add here for both client and node certs at the end of each respective certificate creation sections.
openssl x509 -in node-certs/node.crt -text | grep "X509v3 Subject Alternative Name" -A 1
            X509v3 Subject Alternative Name: critical
                DNS:localhost, DNS:node.example.com, IP Address:127.0.0.1
openssl x509 -in client-certs/client.root.crt -text | grep CN=
        Issuer: O=Cockroach, CN=Cockroach CA
        Subject: O=Cockroach, CN=root
openssl x509 -in client-certs/client.roach.crt -text | grep CN=
        Issuer: O=Cockroach, CN=Cockroach CA
        Subject: O=Cockroach, CN=roach

Oooh...That's a great idea! Added!

finally, add a step to use the client cert in the very last step
cockroach sql --certs-dir=client-certs --user=roach

Done.

cockroach-teamcity · 2020-04-10T17:02:23Z

Online preview: http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/5f35157a2d108b867dcba808e5e778071132df8d/

Edited pages:

Amruta-Ranade · 2020-04-10T17:03:49Z

since we're using placeholders, perhaps --user=roach should say --user=<username>

Yes..sorry. Fixed.

cockroach-teamcity · 2020-04-10T17:07:43Z

Online preview: http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/cbc5f56cea296d17239ff2dff99e7e1456a49c41/

Edited pages:

petermattis

I didn't scrutinize all of the step-by-step instructions. So glad that we provide these, though. They are somewhat onerous to create.

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @Amruta-Ranade, @dbist, and @petermattis)

v20.1/cockroach-start.md, line 89 at r5 (raw file):

`--certs-dir` | The path to the [certificate directory](cockroach-cert.html). The directory must contain valid certificates if running in secure mode.<br><br>**Default:** `${HOME}/.cockroach-certs/`
`--insecure` | Run in insecure mode. If this flag is not set, the `--certs-dir` flag must point to valid certificates.<br><br><strong>Note the following risks:</strong> An insecure cluster is open to any client that can access any node's IP addresses; any user, even `root`, can log in without providing a password; any user, connecting as `root`, can read or write any data in your cluster; and there is no network encryption or authentication, and thus no confidentiality.<br><br>**Default:** `false`
`--cert-principal-map` | A comma-separated list of `cert-principal:db-principal` mappings used to map the certificate principals to IP addresses, DNS names, and SQL users. This allows the use of certificates generated by Certificate Authorities that place restrictions on the contents of the `commonName` field. For usage information, see [Create Security Certificates using Openssl](create-security-certificates-openssl.html#examples)

The first sentence here is confusing to me. Specifically this part: used to map the certificate principals to IP addresses, DNS names, and SQL users. The flag is used to map certificate principals to DB principals such as SQL users or the special "root" and "node" users. What are we trying to convey with the mention of IP addresses and DNS names?

v20.1/create-security-certificates-openssl.md, line 77 at r1 (raw file):

Previously, Amruta-Ranade (Amruta Ranade) wrote…

Update: Single directory didn't work :(
Retried with separate directories and it worked!

I wonder why a single directory didn't work. With openssl it should work. I don't mind the extra directory, just curious.

dbist · 2020-04-10T17:35:33Z

@petermattis in my tests with openssl, single directory did not work either. The error was similar to

ERROR: failed to generate client certificate and key: client/server node certificate has principals ["node.crdb.io" "localhost" "Artems-MBP" "*.local" "127.0.0.1::1"], expected "node"
Failed running "cert create-client"

Amruta-Ranade

No worries! Aaron and Artem tried out the steps, so I feel pretty confident about the instructions :)

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @dbist and @petermattis)

v20.1/cockroach-start.md, line 89 at r5 (raw file):

Previously, petermattis (Peter Mattis) wrote…

The first sentence here is confusing to me. Specifically this part: used to map the certificate principals to IP addresses, DNS names, and SQL users. The flag is used to map certificate principals to DB principals such as SQL users or the special "root" and "node" users. What are we trying to convey with the mention of IP addresses and DNS names?

This is confusing 😕I thought "node" and "root" were certificate principals.
Is this right: "used to map certificate principals (IP addresses and DNS names) to database principals (SQL users, node, root)"

v20.1/create-security-certificates-openssl.md, line 77 at r1 (raw file):

Previously, petermattis (Peter Mattis) wrote…

I wonder why a single directory didn't work. With openssl it should work. I don't mind the extra directory, just curious.

I don't know :( I got a client certificate error when I tried with a single directory.

aaron-crl · 2020-04-13T13:49:45Z

We may want to change the default certificate lifespans to bring usage in line with what OSX and Chrome expect per: #6946 (comment)

Namely:

In ca.cnf change default_days to 365
Change lifespan for the CA from 3660 to 365 days
Remove -days 1830 override from the cert generation code leaving the default 365 to propigate from the CA config.

aaron-crl

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @Amruta-Ranade, @dbist, and @petermattis)

v20.1/create-security-certificates-openssl.md, line 77 at r1 (raw file):

Previously, Amruta-Ranade (Amruta Ranade) wrote…

I don't know :( I got a client certificate error when I tried with a single directory.

I'd like to see that error if you can generate it? It doesn't make sense to me that it should fail.

v20.1/create-security-certificates-openssl.md, line 250 at r1 (raw file):

    $ scp node-certs/ca.crt \
    node-certs/node.crt \
    Node-certs/node.key \

Does this break something? Node vs node?

Amruta-Ranade · 2020-04-13T14:24:25Z

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @Amruta-Ranade, @dbist, and @petermattis)

v20.1/create-security-certificates-openssl.md, line 77 at r1 (raw file):

Previously, Amruta-Ranade (Amruta Ranade) wrote…
I'd like to see that error if you can generate it? It doesn't make sense to me that it should fail.

Same error as Artem's:

ERROR: failed to generate client certificate and key: client/server node certificate has principals ["node.crdb.io" "localhost" "Artems-MBP" "*.local" "127.0.0.1::1"], expected "node"
Failed running "cert create-client"

v20.1/create-security-certificates-openssl.md, line 250 at r1 (raw file):
    $ scp node-certs/ca.crt \
    node-certs/node.crt \
    Node-certs/node.key \
Does this break something? Node vs node?

Fixed :)

cockroach-teamcity · 2020-04-14T18:43:32Z

Online preview: http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/5f4794c45ca2db9ac78b9f629ded71045c176287/

Edited pages:

dbist · 2020-04-14T18:55:21Z

@Amruta-Ranade here's my write-up with single directory and --url instead.

mkdir certs my-safe-directory
openssl genrsa -out my-safe-directory/ca.key 2048
chmod 400 my-safe-directory/ca.key
openssl req -new -x509 -config ca.cnf -key my-safe-directory/ca.key -out certs/ca.crt -days 365 -batch
rm -f index.txt serial.txt
touch index.txt
echo '01' > serial.txt
openssl genrsa -out certs/node.key 2048
chmod 400 certs/node.key
openssl req -new -config node.cnf -key certs/node.key -out node.csr -batch
openssl ca -config ca.cnf -keyfile my-safe-directory/ca.key -cert certs/ca.crt -policy signing_policy -extensions signing_node_req -out certs/node.crt -outdir certs/ -in node.csr -batch
openssl x509 -in certs/node.crt -text | grep "X509v3 Subject Alternative Name" -A 1
openssl genrsa -out certs/client.root.key 2048
chmod 400 certs/client.root.key
openssl req -new -config client.cnf -key certs/client.root.key -out client.root.csr -batch
openssl ca -config ca.cnf -keyfile my-safe-directory/ca.key -cert certs/ca.crt -policy signing_policy -extensions signing_client_req -out certs/client.root.crt -outdir certs/ -in client.root.csr -batch
openssl x509 -in certs/client.root.crt -text | grep CN=
# removing .pem files is only required once with a single directory
rm -rf certs/*.pem
cockroach start-single-node --certs-dir=certs --cert-principal-map=node.example.com:node,user.example.com:root --background
cockroach sql --url 'postgresql://root@node.example.com:26257?sslcert=certs%2Fclient.root.crt&sslkey=certs%2Fclient.root.key&sslmode=verify-full&sslrootcert=certs%2Fca.crt'

# create another user called `user2.example.com` as that's what's it's called in client.cnf `DNS:user2.example.com`, you can use another name like user2 but you have to strip `.example.com` from every step including file names.

# in sql shell
create user 'user2.example.com';
\q
openssl genrsa -out certs/client.user2.example.com.key 2048
chmod 400 certs/client.user2.example.com.key
openssl req -new -config client.cnf -key certs/client.user2.example.com.key -out client.user2.example.com.csr -batch
openssl ca -config ca.cnf -keyfile my-safe-directory/ca.key -cert certs/ca.crt -policy signing_policy -extensions signing_client_req -out certs/client.user2.example.com.crt -outdir certs/ -in client.user2.example.com.csr -batch
openssl x509 -in certs/client.user2.example.com.crt -text | grep CN=
cockroach sql --url 'postgresql://user2.example.com@node.example.com:26257?sslcert=certs%2Fclient.user2.example.com.crt&sslkey=certs%2Fclient.user2.example.com.key&sslmode=verify-full&sslrootcert=certs%2Fca.crt'

Amruta-Ranade · 2020-04-14T18:57:12Z

Updated the instructions to use the connection URL instead of cockroach sql. This takes care of the single/separate directory issue as well as the cert mapping issue 🎉

cc @aaron-crl @dbist @petermattis for final checks/approvals.
@jseldess ready for your review (pending technical approvals)

cockroach-teamcity · 2020-04-14T19:01:23Z

Online preview: http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/4f1c3f157b912a08db4c50e1d115e5a71c8423ff/

Edited pages:

dbist

aside from mentioning to remove .pem file once because all of them will reside in the single certs dir, this looks good to me. The client.cnf file for additional users is missing SAN but it's not a deal breaker. Mine looks like so

[ extensions ]
subjectAltName = email:user2@example.com,DNS:user2.example.com,DNS:user2

which demonstrates this user is not root and also referenced by short name user2. Again not major. This is long and painful, great job, thank you for sticking with it! LGTM after removing .pem.

Amruta-Ranade · 2020-04-14T19:34:18Z

aside from mentioning to remove .pem file once because all of them will reside in the single certs dir, this looks good to me.

Updated as discussed on Slack.

The client.cnf file for additional users is missing SAN but it's not a deal breaker. Mine looks like so
[ extensions ]
subjectAltName = email:user2@example.com,DNS:user2.example.com,DNS:user2

The reason I didn't include SAN in the second user's conf is that we aren't mapping the second user to a DB principal, whereas in the first user's conf, we are mapping the user to root. It makes things clearer to me to see what's mapped and what isn't. But I might be mistaken. cc @aaron-crl for input.

which demonstrates this user is not root and also referenced by short name user2. Again not major. This is long and painful, great job, thank you for sticking with it! LGTM after removing .pem.

jseldess

Few suggestions and got an error when running through the steps.

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @aaron-crl, @Amruta-Ranade, @dbist, @jseldess, and @petermattis)

v20.1/cockroach-start.md, line 89 at r10 (raw file):

`--certs-dir` | The path to the [certificate directory](cockroach-cert.html). The directory must contain valid certificates if running in secure mode.<br><br>**Default:** `${HOME}/.cockroach-certs/`
`--insecure` | Run in insecure mode. If this flag is not set, the `--certs-dir` flag must point to valid certificates.<br><br><strong>Note the following risks:</strong> An insecure cluster is open to any client that can access any node's IP addresses; any user, even `root`, can log in without providing a password; any user, connecting as `root`, can read or write any data in your cluster; and there is no network encryption or authentication, and thus no confidentiality.<br><br>**Default:** `false`
`--cert-principal-map` | A comma-separated list of `cert-principal:db-principal` mappings used to map the certificate principals to IP addresses, DNS names, and SQL users. This allows the use of certificates generated by Certificate Authorities that place restrictions on the contents of the `commonName` field. For usage information, see [Create Security Certificates using Openssl](create-security-certificates-openssl.html#examples)

Add a "new in v20.1" callout:

`--cert-principal-map` | <span class="version-tag">New in v20.1:</span> A comma-separated list of...

Add a period at end of paragarph.

Also, I think we need to add this flag to the cockroach start-single-node docs as well? Not sure about cockroach demo?

v20.1/create-security-certificates-openssl.md, line 157 at r10 (raw file):

    ~~~

6. Reset database and index files.

Replace period with colon.

v20.1/create-security-certificates-openssl.md, line 193 at r10 (raw file):

    ~~~

    {{site.data.alerts.callout_danger}}The <code>subjectAltName</code> parameter is vital for CockroachDB functions. You can modify or omit other parameters as per your preferred OpenSSL configuration, but do not omit the <code>subjectAltName</code> parameter.  {{site.data.alerts.end}}

nit: While you're here, you could convert the formatting in the callout to markdown.

v20.1/create-security-certificates-openssl.md, line 206 at r10 (raw file):

    ~~~

3. Create the CSR for the first node using the [`openssl req`](https://www.openssl.org/docs/manmaster/man1/req.html) command:

This step fails for me now:

~$ openssl req -new -config node.cnf -key certs/node.key -out node.csr -batch
Error Loading request extension section extensions
4705336940:error:22FFF076:X509 V3 routines:func(4095):bad ip address:/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-47.100.4/libressl-2.8/crypto/x509v3/v3_alt.c:529:value=<IP Address>
4705336940:error:22FFF080:X509 V3 routines:func(4095):error in extension:/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-47.100.4/libressl-2.8/crypto/x509v3/v3_conf.c:100:name=subjectAltName, value=DNS:<node-hostname>,DNS:<node-domain>,IP:<IP Address>

Amruta-Ranade

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @aaron-crl, @Amruta-Ranade, @dbist, @jseldess, and @petermattis)

v20.1/create-security-certificates-openssl.md, line 206 at r10 (raw file):

Previously, jseldess (Jesse Seldess) wrote…

This step fails for me now:

~$ openssl req -new -config node.cnf -key certs/node.key -out node.csr -batch
Error Loading request extension section extensions
4705336940:error:22FFF076:X509 V3 routines:func(4095):bad ip address:/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-47.100.4/libressl-2.8/crypto/x509v3/v3_alt.c:529:value=<IP Address>
4705336940:error:22FFF080:X509 V3 routines:func(4095):error in extension:/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-47.100.4/libressl-2.8/crypto/x509v3/v3_conf.c:100:name=subjectAltName, value=DNS:<node-hostname>,DNS:<node-domain>,IP:<IP Address>

Oh, the user has to replace the placeholders in the .cnf file with their values. I use "DNS:localhost,DNS:node.crdb.io,IP:127.0.0.1" for testing.

jseldess

Got through it well. LGTM with a few suggestions.

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @aaron-crl, @Amruta-Ranade, @dbist, @jseldess, and @petermattis)

v20.1/create-security-certificates-openssl.md, line 250 at r10 (raw file):

6. Remove the `.pem` files in the `certs` directory. These files are unnecessary duplicates of the `.crt` files that CockroachDB requires.

### Step 3. Create the certificate and key pair for the first user

Probably want an intro about placeholders, like you have for step 2.

Amruta-Ranade

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @aaron-crl, @Amruta-Ranade, @dbist, @jseldess, and @petermattis)

v20.1/create-security-certificates-openssl.md, line 157 at r10 (raw file):

Previously, jseldess (Jesse Seldess) wrote…

Replace period with colon.

Done.

v20.1/create-security-certificates-openssl.md, line 250 at r10 (raw file):

Previously, jseldess (Jesse Seldess) wrote…

Probably want an intro about placeholders, like you have for step 2.

Done.

cockroach-teamcity · 2020-04-15T15:54:59Z

Online preview: http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/41cea8f6f8415cf01cbdf20e0b92a0f895e2d6b7/

Edited pages:

aaron-crl

Thanks for all the hard work on this!

dbist · 2020-04-15T17:46:25Z

I noticed a difference in the first and second url, for the root user, you didn't include place holder <username_1> in cockroach sql --url='postgres://root@node.example.com:26257/?sslmode=verify-full&sslrootcert=certs/ca.crt&sslcert=certs/client.user.crt&sslkey=certs/client.user.key&sslmode=verify-full' and cockroach sql --url='postgres://node.example.com:26257/?sslmode=verify-full&sslrootcert=certs/ca.crt&sslcert=certs/client.user.crt&sslkey=certs/client.user.key&sslmode=verify-full' both work but it's probably best to be explicit. I noticed it because my url did not include username for root so I just copied that for user2 and got tripped up, only after I explicitly added user@node then it worked cockroach sql --url='postgres://user2@node.example.com:26257/?sslmode=verify-full&sslrootcert=certs/ca.crt&sslcert=certs/client.user2.crt&sslkey=certs/client.user2.key&sslmode=verify-full'. It is not a big deal but maybe for consistency sake I suggest to add `<username_1>@ to the first mention of url.
Otherwise LGTM!

petermattis

regarding using sql --url instead of sql --certs-dir. Glad that approach could get rid of the separate client-certs and node-certs directories. I didn't actually walk through the examples step by step, but I trust you and others did.

Reviewable status: complete! 2 of 0 LGTMs obtained (waiting on @aaron-crl, @Amruta-Ranade, @dbist, @jseldess, and @petermattis)

Amruta-Ranade · 2020-04-15T18:55:50Z

I noticed a difference in the first and second url, for the root user, you didn't include place holder <username_1> in cockroach sql --url='postgres://root@node.example.com:26257/?sslmode=verify-full&sslrootcert=certs/ca.crt&sslcert=certs/client.user.crt&sslkey=certs/client.user.key&sslmode=verify-full' and cockroach sql --url='postgres://node.example.com:26257/?sslmode=verify-full&sslrootcert=certs/ca.crt&sslcert=certs/client.user.crt&sslkey=certs/client.user.key&sslmode=verify-full' both work but it's probably best to be explicit. I noticed it because my url did not include username for root so I just copied that for user2 and got tripped up, only after I explicitly added user@node then it worked cockroach sql --url='postgres://user2@node.example.com:26257/?sslmode=verify-full&sslrootcert=certs/ca.crt&sslcert=certs/client.user2.crt&sslkey=certs/client.user2.key&sslmode=verify-full'. It is not a big deal but maybe for consistency sake I suggest to add `<username_1>@ to the first mention of url.
Otherwise LGTM!

I didn't add <username_1> for the first URL because it doesn't work 😕It gives the following error: ERROR: password authentication failed for user maxroach Failed running "sql"

It works without the username because it assumes root, which I believe is a safer way than specifying root@. Pls correct me if I am wrong.

Amruta-Ranade

Reviewable status: complete! 2 of 0 LGTMs obtained (waiting on @aaron-crl, @dbist, @jseldess, and @petermattis)

v20.1/cockroach-start.md, line 89 at r10 (raw file):

Previously, jseldess (Jesse Seldess) wrote…

Add a "new in v20.1" callout:
`--cert-principal-map` | <span class="version-tag">New in v20.1:</span> A comma-separated list of...
Add a period at end of paragarph.

Also, I think we need to add this flag to the cockroach start-single-node docs as well? Not sure about cockroach demo?

Added the callout and period and updated the cockroach start-single-node doc. Checking if the flag works for demo.

cockroach-teamcity · 2020-04-15T19:04:13Z

Online preview: http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/14eddb9edf07a4433e870f880a1e5e0a366297cb/

Edited pages:

dbist · 2020-04-15T19:39:55Z

it works with the following configuration file

[ req ]
prompt=no
distinguished_name = distinguished_name
req_extensions = extensions

[ distinguished_name ]
organizationName = ExampleCorp
commonName = user@example.com

[ extensions ]
subjectAltName = email:user@example.com,DNS:user.example.com,DNS:user,DNS:root

my user2 client.cnf file is like so:

[ req ]
prompt=no
distinguished_name = distinguished_name
req_extensions = extensions

[ distinguished_name ]
organizationName = ExampleCorp
commonName = user2@example.com

[ extensions ]
subjectAltName = email:user2@example.com,DNS:user2.example.com,DNS:user2

my command to start the cluster
start-single-node --certs-dir=certs --cert-principal-map=node.example.com:node,user@example.com:root --background

Again, it's a matter of preference but at least we know the reasoning was intentional.

LGTM!

Updated the openssl doc

33ca546

petermattis reviewed Apr 9, 2020

View reviewed changes

Amruta-Ranade commented Apr 9, 2020

View reviewed changes

Working on Peter's comments + updated cockroach start doc

951e3db

aaron-crl reviewed Apr 9, 2020

View reviewed changes

Amruta-Ranade requested a review from dbist April 9, 2020 17:23

aaron-crl reviewed Apr 9, 2020

View reviewed changes

Worked on Aaron and Artem's review comments

3086c5e

Amruta-Ranade commented Apr 9, 2020

View reviewed changes

dbist reviewed Apr 10, 2020

View reviewed changes

Worked on Artem's comments

5f35157

nit

cbc5f56

dbist approved these changes Apr 10, 2020

View reviewed changes

petermattis reviewed Apr 10, 2020

View reviewed changes

Amruta-Ranade commented Apr 10, 2020

View reviewed changes

aaron-crl reviewed Apr 13, 2020

View reviewed changes

wip url change

5f4794c

single directory updates

4f1c3f1

Amruta-Ranade requested a review from jseldess April 14, 2020 19:02

dbist reviewed Apr 14, 2020

View reviewed changes

jseldess suggested changes Apr 14, 2020

View reviewed changes

Amruta-Ranade commented Apr 14, 2020

View reviewed changes

jseldess approved these changes Apr 14, 2020

View reviewed changes

Worked on Jesse's comments

41cea8f

Amruta-Ranade commented Apr 15, 2020

View reviewed changes

Amruta-Ranade changed the title ~~[WIP] add --cert-principal-map~~ add --cert-principal-map Apr 15, 2020

aaron-crl approved these changes Apr 15, 2020

View reviewed changes

petermattis approved these changes Apr 15, 2020

View reviewed changes

Worked on Jesse's comments

14eddb9

Amruta-Ranade commented Apr 15, 2020

View reviewed changes

Amruta-Ranade merged commit dbca296 into master Apr 15, 2020

Amruta-Ranade deleted the authentication_updates branch April 15, 2020 19:43

This was referenced Apr 21, 2020

[WIP] Security updates [Pls ignore this PR for now] #6991

Closed

customizable/required fields in certificate #6807

Closed

"Security Work for 20.1" doc #6792

Closed

dbist mentioned this pull request Apr 27, 2020

clarify requirement of -keyfile in signing of CSR #7228

Closed

add --cert-principal-map #7104

add --cert-principal-map #7104

Conversation

Amruta-Ranade commented Apr 8, 2020 • edited Loading

cockroach-teamcity commented Apr 8, 2020

cockroach-teamcity commented Apr 8, 2020

petermattis left a comment

Choose a reason for hiding this comment

Amruta-Ranade left a comment • edited Loading

Choose a reason for hiding this comment

Amruta-Ranade left a comment

Choose a reason for hiding this comment

cockroach-teamcity commented Apr 9, 2020

Amruta-Ranade commented Apr 9, 2020 • edited Loading

aaron-crl left a comment

Choose a reason for hiding this comment

Amruta-Ranade commented Apr 9, 2020

aaron-crl left a comment

Choose a reason for hiding this comment

cockroach-teamcity commented Apr 9, 2020

Amruta-Ranade left a comment

Choose a reason for hiding this comment

dbist left a comment

Choose a reason for hiding this comment

Amruta-Ranade commented Apr 10, 2020

cockroach-teamcity commented Apr 10, 2020

Amruta-Ranade commented Apr 10, 2020

cockroach-teamcity commented Apr 10, 2020

petermattis left a comment

Choose a reason for hiding this comment

dbist commented Apr 10, 2020 • edited Loading

Amruta-Ranade left a comment

Choose a reason for hiding this comment

aaron-crl commented Apr 13, 2020

aaron-crl left a comment

Choose a reason for hiding this comment

Amruta-Ranade commented Apr 13, 2020 • edited Loading

cockroach-teamcity commented Apr 14, 2020

dbist commented Apr 14, 2020

Amruta-Ranade commented Apr 14, 2020 • edited Loading

cockroach-teamcity commented Apr 14, 2020

dbist left a comment

Choose a reason for hiding this comment

Amruta-Ranade commented Apr 14, 2020

jseldess left a comment

Choose a reason for hiding this comment

Amruta-Ranade left a comment

Choose a reason for hiding this comment

jseldess left a comment

Choose a reason for hiding this comment

Amruta-Ranade left a comment

Choose a reason for hiding this comment

cockroach-teamcity commented Apr 15, 2020

aaron-crl left a comment • edited by andreimatei Loading

Choose a reason for hiding this comment

dbist commented Apr 15, 2020 • edited Loading

petermattis left a comment

Choose a reason for hiding this comment

Amruta-Ranade commented Apr 15, 2020

Amruta-Ranade left a comment

Choose a reason for hiding this comment

cockroach-teamcity commented Apr 15, 2020

dbist commented Apr 15, 2020 • edited Loading

Amruta-Ranade commented Apr 8, 2020 •

edited

Loading

Amruta-Ranade left a comment •

edited

Loading

Amruta-Ranade commented Apr 9, 2020 •

edited

Loading

dbist commented Apr 10, 2020 •

edited

Loading

Amruta-Ranade commented Apr 13, 2020 •

edited

Loading

Amruta-Ranade commented Apr 14, 2020 •

edited

Loading

aaron-crl left a comment •

edited by andreimatei

Loading

dbist commented Apr 15, 2020 •

edited

Loading

dbist commented Apr 15, 2020 •

edited

Loading