How to create worker cert for Coreos kubernetes aws cluster

8/25/2016

Ok, So I am defiantly not a security expert and battling with this for a few days now,

I am using the Coreos kube-aws cloud-formation template maker, and i want to deploy my cluster to production but because of this little comment:

PRODUCTION NOTE: the TLS keys and certificates generated by kube-aws should not be used to deploy a production Kubernetes cluster. Each component certificate is only valid for 90 days, while the CA is valid for 365 days. If deploying a production Kubernetes cluster, consider establishing PKI independently of this tool first

I need to generate my own keys, but I don't seem to understand how to do that, their documentation (IMHO as someone who's not an expert) is seriously outrageous if you are not a familiar with.

So my requirements are like so:

  1. I would like to cert/keys to last for X years (long time)
  2. I would like them to be valid for the entire domain *.company.com (I dont care for the internals just for the admin key for kubectl)
  3. I would like to repeat the process 2 times (once for production, and once for QA/Staging) and eventually have 2 sets of credentials
  4. override the default credentials and use kube-aws up --export to get the userdata i need for my cluster

My problems are:

  1. how to make the admin cert valid for *.company.com
  2. In the documentation they say that you need to create a key-pair for each node in the cluster... WHAT! kube-aws render generates only 1 worker key-pair so whats up with that!

Well now for the "fun" part:

$ openssl genrsa -out ca-key.pem 2048
$ openssl req -x509 -new -nodes -key ca-key.pem -days 10000 -out ca.pem -subj "/CN=kube-ca"

I guess that the -days 10000 solves my first problem with the expiration. cool

API-SERVER key pair

openssl.cnf

  [req]
    req_extensions = v3_req
    distinguished_name = req_distinguished_name
    [req_distinguished_name]
    [ v3_req ]
    basicConstraints = CA:FALSE
    keyUsage = nonRepudiation, digitalSignature, keyEncipherment
    subjectAltName = @alt_names
    [alt_names]
    DNS.1 = kubernetes
    DNS.2 = kubernetes.default
    DNS.3 = kubernetes.default.svc
    DNS.4 = kubernetes.default.svc.cluster.local
    is it
    DNS.5 = mycompany.com
    or
    DNS.5 = *.mycompany.com
    IP.1 = 10.3.0.1
    IP.2 = 10.0.0.50

and run the commands

$ openssl genrsa -out apiserver-key.pem 2048
$ openssl req -new -key apiserver-key.pem -out apiserver.csr -subj "/CN=kube-apiserver" -config openssl.cnf
$ openssl x509 -req -in apiserver.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out apiserver.pem -days 3650 -extensions v3_req -extfile openssl.cnf

Fine, besides the subjectAltName which I don't know how to use i could have made a few attempts to see what works its cool.

Worker Keypairs

Here is where I am really stuck, what am I supposed to do with this sentence:

This procedure generates a unique TLS certificate for every Kubernetes worker node in your cluster

Fine security and all but this is really unrealistic and overkill IMO on an amazon autoscaling group

So in case I don't want to have a key for each node but 1 key for all, how does my worker-openssl.cnf should look????

[req]
req_extensions = v3_req
distinguished_name = req_distinguished_name
[req_distinguished_name]
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
[alt_names]
IP.1 = $ENV::WORKER_IP <- what am i supposed to do here?

after this creating the admin key pair is straight forward.

please help!

-- Gleeb
amazon-web-services
coreos
kubernetes
ssl

2 Answers

8/25/2016

I believe that you should have *.mycompany.com in your alt-names. Or you can specify all possible variants like in this manual

Since you're running CoreOS you just need to configure cloud-config to generate your keys. You don't need to generate it manually for each node, and autoscalling should work fine.

I didn't do this on amazon, but I did deploy kubernetes manually on baremetal with all ssh keys and config. You can check out my blog post about it here. Hopefully it will help a bit.

-- lwolf
Source: StackOverflow

8/28/2016

I was able to get it to work with this worker-openssl.conf using the the same certificate for all workers. Probably not the most secure setup.

[req]
req_extensions = v3_req
distinguished_name = req_distinguished_name
[req_distinguished_name]
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = *.*.cluster.internal
-- Luca Martinetti
Source: StackOverflow