Secure cockroachdb cluster on AWS EKS

Hi Andy Woods,

On AWS EKS cluster, using the default yaml scripts provided in docs
created cockroachdb cluster(secure). It asks for csr approval, after approaving the csr, when i see pods, they are in crashloopbackoff state

cluster-init-secure-vtjlg 0/1 CrashLoopBackOff 12 36m
cockroachdb-0 0/1 CrashLoopBackOff 29 1h
cockroachdb-1 0/1 Running 29 1h
cockroachdb-2 0/1 CrashLoopBackOff 29 1h

the pod logs shows:
I180711 13:38:33.142903 1 cli/start.go:789 using local environment variables: COCKROACH_CHANNEL=kubernetes-secure I180711 13:38:33.142941 1 cli/start.go:796 process identity: uid 0 euid 0 gid 0 egid 0 I180711 13:38:33.142978 1 cli/start.go:461 starting cockroach node I180711 13:38:33.145061 10 storage/engine/rocksdb.go:552 opening rocksdb instance at “/cockroach/cockroach-data/cockroach-temp107022697” I180711 13:38:33.168828 10 server/server.go:734 [n?] monitoring forward clock jumps based on server.clock.forward_jump_check_enabled I180711 13:38:33.169476 10 storage/engine/rocksdb.go:552 opening rocksdb instance at “/cockroach/cockroach-data” I180711 13:38:33.182480 10 server/config.go:538 [n?] 1 storage engine initialized I180711 13:38:33.182526 10 server/config.go:541 [n?] RocksDB cache size: 1.8 GiB I180711 13:38:33.182554 10 server/config.go:541 [n?] store 0: RocksDB, max size 0 B, max open file limit 60536 W180711 13:38:33.183018 10 gossip/gossip.go:1293 [n?] no incoming or outgoing connections I180711 13:38:33.183098 10 server/server.go:1306 [n?] no stores bootstrapped and --join flag specified, awaiting init command. W180711 13:38:33.191535 82 vendor/ grpc: Server.Serve failed to complete security handshake from “x.x.x.x:46044": remote error: tls: bad certificate W180711 13:38:33.191698 76 vendor/ Failed to dial cockroachdb-0.cockroachdb:26257: connection error: desc = “transport: authentication handshake failed: x509: certificate is valid for node, not cockroachdb-0.cockroachdb”; please retry. W180711 13:38:33.191849 72 gossip/client.go:123 [n?] failed to start gossip client to cockroachdb-0.cockroachdb:26257: initial connection heartbeat failed: rpc error: code = Unavailable desc = all SubConns are in TransientFailure W180711 13:38:34.195112 62

What do you see when you run kubectl describe csr default.node.cockroachdb-0?

And what’s the output of kubectl version?

Kubectl version

Client Version: version.Info{Major:“1”, Minor:“10”, GitVersion:“v1.10.3”, GitCommit:“2bba0127d85d5a46ab4b778548be28623b32d0b0”, GitTreeState:“clean”, BuildDate:“2018-05-28T20:03:09Z”, GoVersion:“go1.9.3”, Compiler:“gc”, Platform:“darwin/amd64”}
Server Version: version.Info{Major:“1”, Minor:“10”, GitVersion:“v1.10.3”, GitCommit:“2bba0127d85d5a46ab4b778548be28623b32d0b0”, GitTreeState:“clean”, BuildDate:“2018-05-28T20:13:43Z”, GoVersion:“go1.9.3”, Compiler:“gc”, Platform:“linux/amd64”}

Initialy, when i start nodes using kubectl create -f
i am able to see csr and approved them. After a while i am not seeing any csr’s when i give kubectl get csr.

kubectl describe csr default.node.cockroachdb-0

Error from server (NotFound): “default.node.cockroachdb-0” not found

Ugh, that’s frustrating. What I want to do is inspect the contents of the certificate, because it’s very wrong that the certificate is valid for “node” but not for “cockroachdb-0.cockroachdb”. We can get the same information out of the secret that now contains the certificate, but it’ll be a little more work than if the csr was still there.

  1. Run kubectl get secret default.node.cockroachdb-0 -o yaml
  2. You should see some key-value pairs in the resulting yaml. Grab the long string that appears next to the key cert
  3. Run that string through a base64 decoder (e.g.
  4. Run the resulting string through openssl, either using a site like or a command like openssl x509 -in <your-cert-file> -text -noout

Certificate Information:
Common Name: node
Organization: Cockroach
Valid From: July 12, 2018
Valid To: July 12, 2019
Serial Number: xxxxxxxxxx

Any solution to this issue please.

Sorry, @Sashanka, I thought I had responded to this yesterday. It’s really a bummer that the CSR is gone, since it would help confirm where the problem is coming from. The problem is that the certificate doesn’t have any Subject Alternative Names, which are what normally make the certificate valid at addresses like cockroachdb-0.cockroachdb.

Given that you say you haven’t changed anything about the provided config files, the only probable cause I can imagine is that there’s something wrong with the way EKS’s certificate signer handles alternative names. Googling hasn’t brought up any details on the subject, though, which could just mean that there aren’t many people using EKS yet, but would otherwise be pretty surprising.

Just to confirm, could you try deleting all the cockroach-related resources in the Kubernetes cluster as outlined at and trying again? Grab the contents of the CSRs as well as the logs from both the main cockroach container (kubectl logs cockroachdb-0 cockroachdb) and the container that asks for the certificates (kubectl logs cockroachdb-0 init-certs).

Thanks Alex.
The problem is EKS is not including Subject Alternative Names when it issues certificate.
Below is missing in EKS certificate:
X509v3 Subject Alternative Name:,, IP Address:x.x.x.x, IP Address:x.x.x.x

Are you aware of any issue trackers for EKS that have something about this? It’s pretty surprising, and I’d be interested in following up on it.


I haven’t seen any issue raised in their forums. I will create one.

Thank you

Thanks! If you’d like guidance on setting up certificates manually in the meantime, just let me know. It’s easier than you might expect.

Sure Alex. Thank you.

Could you please provide me the process or the steps to create certificates manually.

Try out the config file I’ve just posted to Instructions are in the comment at the top of the file.

Thank you Alex.It worked for me.

Hi Alex,

I got some feedback from AWS EKS service team regarding CSR approval and signing.It says that EKS has a custom certificate signer, which signs only certificates for kubelet and ignoring other internal names and SAN.

Thanks for the update, @Sashanka! We’ll get something like checked in and documented.

Could you be hitting this bug in golang?