Secure Admin UI on Docker (for mac)

docker
(Chris White) #1

The official docs for running within docker don’t mention running a secure cluster, so i had a stab as trying to compose this, but the Admin UI fails to login, with errors in the logs about a missing cookie.

cockroach:
    image: cockroachdb/cockroach:v2.1.4
    container_name: cockroach
    ports:
      - '127.0.0.1:26257:26257'
      - '127.0.0.1:8080:8080'
    command: start --certs-dir=/cockroach/certs --listen-addr=cockroach
    volumes:
      - './certs/crdb:/cockroach/certs'
    healthcheck:
      test: /cockroach/cockroach node status --certs-dir=/cockroach/certs
      interval: 10s
      timeout: 10s
      retries: 6

Container logs (from stdout via docker-compose logs):

cockroach                 | *
cockroach                 | * WARNING: [n?] listen address "172.19.0.2" not in node certificate (IP=127.0.0.1; DNS=localhost,cockroach; CN=node)
cockroach                 | * Secure node-node and SQL connections are likely to fail.
cockroach                 | * Consider extending the node certificate or tweak --listen-addr/--advertise-addr.
cockroach                 | *
cockroach                 | CockroachDB node starting at 2019-01-29 05:49:22.1300077 +0000 UTC (took 1.0s)
cockroach                 | build:               CCL v2.1.4 @ 2019/01/16 16:05:40 (go1.10.7)
cockroach                 | webui:               https://cockroach:8080
cockroach                 | sql:                 postgresql://root@cockroach:26257?sslcert=%2Fcockroach%2Fcerts%2Fclient.root.crt&sslkey=%2Fcockroach%2Fcerts%2Fclient.root.key&sslmode=verify-full&sslrootcert=%2Fcockroach%2Fcerts%2Fca.crt
cockroach                 | client flags:        /cockroach/cockroach <client cmd> --host=cockroach:26257 --certs-dir=/cockroach/certs
cockroach                 | logs:                /cockroach/cockroach-data/logs
cockroach                 | temp dir:            /cockroach/cockroach-data/cockroach-temp141164548
cockroach                 | external I/O path:   /cockroach/cockroach-data/extern
cockroach                 | store[0]:            path=/cockroach/cockroach-data
cockroach                 | status:              initialized new cluster
cockroach                 | clusterID:           6296c5c6-57e0-4e09-896e-952fd56868da
cockroach                 | nodeID:              1

Logs from within the container (not visible from docker-compose -logs -f cockroach)

I190129 05:51:21.826570 776 server/authentication.go:374  Web session error: http: named cookie not present

Attempting to login with a user (who has a password) always fails (HTTP:401), i’m assuming it’s related to the Cookie error msg.

Any thoughts or pointers on running single node in secure mode (in my case docker for mac)?

As a sidenote, i understand that I could just run in insecure mode, but i want to run integration tests and ensure that connecting to a secure cluster works as part of this integration test phase.

(Tim O'Brien) #2

Hey @chriswhite199,

I think the clue is at the head of the log:

cockroach                 | *
cockroach                 | * WARNING: [n?] listen address "172.19.0.2" not in node certificate (IP=127.0.0.1; DNS=localhost,cockroach; CN=node)
cockroach                 | * Secure node-node and SQL connections are likely to fail.
cockroach                 | * Consider extending the node certificate or tweak --listen-addr/--advertise-addr.
cockroach                 | *

You’ll want to double check that each node’s address is listed in the node certificate - this could be because docker’s using a different internal address.

(Chris White) #3

And so without creating a network in docker and hard setting the IP address, there’s no way within CockroachDB to tell the web admin UI to just plain ignore tls issues (is this an SNI issue in this case)?

Granted this is an edge case purely for development - I understand that this isn’t something you’d actively want to do in production, but is there anyway to make this work?

(Chris White) #4

Even using a dedicated IP address / network i’m running into the same issue.

I think the fact that i’m using https://localhost:8080 to get to the container via docker networking means that the Server HTTP header doesn’t match up - but i’m not familiar enough with go to delve into the source and confirm this.

Next port of call to try is a reverse proxy with some serious re-writing rules…