Day 18/#30daysofK8s
Generating private-public key pair and getting it signed by a CA be like —
# generate private key for k8s admin users
openssl genrsa -out admin.key 2048# generate public key(certificate) using the private key
openssl req -new -key admin.key -subj "/CN=kube-admin/O=systems:masters" -out admin.csr# getting the certificate signed by the CA
openssl x509 -req -in admin.csr -CA ca.crt -CAkey ca.key -out admin
To differentiate users, a group name must be mentioned in the certificate. For e.g. differentiating a kube-admin from a normal user would require the kube-admin to be a part of the admin group. This information can be added while creating the certificate and adding the information in -subj like -subj "/O=systems:masters where systems:masters is the admin group.
A component like kubeapi-server is quite popular since every component talks to it, every request passes through it, users communicate with it, and hence is known by many different aliases. Hence it makes sense for its certificate to have information about all the different aliases(names) of a component that it represents. This can be done by writing a config file and passing it to openssl while creating the certificate.
openssl.cnf
[alt_names]
DNS.1 = kubernetes
DNS.2 = kubernetes.default
DNS.3 = kubernetes.default.svc
DNS.4 = kubernetes.default.svc.cluster.local
IP.1 = 10.96.0.1
IP.2 = 172.17.0.87openssl x509 -req -in apiserver.csr -CA ca.cert -CAkey ca.key -out apiserver.crt --config openssl.cnf
For kubelets, their certificate name must indicate which node they are a part of. Nodes must also be added to a group so that right permissions can be given to every node. If group name is system:nodes , this can be mentioned in the cert by system:nodes:<node_name> .
