K8s-pki

Заметка о PKI/CA в kubernetes

Эта заметка появилась для того что бы раз и навсегда прояснить какие CA и сертификаты используются в control-plane, для чего они используются и почему именно такие.

Предполагается что у читающего есть базовое понимание TLS/SSL/CA/PKI/OpenSSL

Julia Evans - мой герой! https://jvns.ca/blog/2017/08/05/how-kubernetes-certificates-work/
Далее - частичный перевод а частично мои собственные мысли.

Почему возникла эта заметка

Официальная документация гласит:
Kubernetes requires PKI for the following operations:

• Client certificates for the kubelet to authenticate to the API server
• Server certificate for the API server endpoint
• Client certificates for administrators of the cluster to authenticate to the API server
• Client certificates for the API server to talk to the kubelets
• Client certificate for the API server to talk to etcd
• Client certificate/kubeconfig for the controller manager to talk to the API server
• Client certificate/kubeconfig for the scheduler to talk to the API server.
• Client and server certificates for the front-proxy

Note: front-proxy certificates are required only if you run kube-proxy to support an extension API server. etcd also implements mutual TLS to authenticate clients and peers.
При этом я не нашел никакой информации о том каким свойствами должны обладать сертификаты, должны ли они быть подписаны одним CA?

Вот что пишет по этому поводу Джулия (перевод мой):

В различных компонентах Kubernetes есть ТЫЩИ разных мест,
где вы можете разместить a certificate/certificate authority.
Когда мы настраивали кластер, я чувствовал, что существует 
около 10 миллиардов различных аргументов командной 
строки для сертификатов, ключей и центров сертификации, и 
я не понимал, как все они сочетаются друг с другом.

На самом деле нет 10 миллиардов аргументов командной строки, 
но их довольно много. Например! Давайте просто посмотрим на 
аргументы командной строки для сервера API.

У API сервера 16 (ШЕСТНАДЦАТЬ, КАРЛ) аргументов которые так или иначе относятся к шифрованию:

1. --cert-dir string

   The directory where the TLS certs are located. If --tls-cert-file and --tls-private-key-file are provided, this flag will be ignored. (default "/var/run/kubernetes")

2. --client-ca-file string

   If set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate.

3. --etcd-certfile string

   SSL certification file used to secure etcd communication.

4. --etcd-keyfile string

   SSL key file used to secure etcd communication.

--etcd-cafile string SSL Certificate Authority file used to secure etcd communication. --kubelet-certificate-authority string Path to a cert file for the certificate authority. --kubelet-client-certificate string Path to a client cert file for TLS. --kubelet-client-key string Path to a client key file for TLS. --proxy-client-cert-file string Client certificate used to prove the identity of the aggregator or kube-apiserver when it must call out during a request. This includes proxying requests to a user api-server and calling out to webhook admission plugins. It is expected that this cert includes a signature from the CA in the --requestheader-client-ca-file flag. That CA is published in the 'extension-apiserver-authentication' configmap in the kube-system namespace. Components recieving calls from kube-aggregator should use that CA to perform their half of the mutual TLS verification. --proxy-client-key-file string Private key for the client certificate used to prove the identity of the aggregator or kube-apiserver when it must call out during a request. This includes proxying requests to a user api-server and calling out to webhook admission plugins. --requestheader-allowed-names stringSlice List of client certificate common names to allow to provide usernames in headers specified by --requestheader-username-headers. If empty, any client certificate validated by the authorities in --requestheader-client-ca-file is allowed. --requestheader-client-ca-file string Root certificate bundle to use to verify client certificates on incoming requests before trusting usernames in headers specified by --requestheader-username-headers --service-account-key-file stringArray File containing PEM-encoded x509 RSA or ECDSA private or public keys, used to verify ServiceAccount tokens. If unspecified, --tls-private-key-file is used. The specified file can contain multiple keys, and the flag can be specified multiple times with different files. --ssh-keyfile string If non-empty, use secure SSH proxy to the nodes, using this user keyfile --tls-ca-file string If set, this certificate authority will used for secure access from Admission Controllers. This must be a valid PEM-encoded CA bundle. Alternatively, the certificate authority can be appended to the certificate provided by --tls-cert-file. --tls-cert-file string File containing the default x509 Certificate for HTTPS. (CA cert, if any, concatenated after server cert). If HTTPS serving is enabled, and --tls-cert-file and --tls-private-key-file are not provided, a self-signed certificate and key are generated for the public address and saved to /var/run/kubernetes. --tls-private-key-file string File containing the default x509 private key matching --tls-cert-file. --tls-sni-cert-key namedCertKey A pair of x509 certificate

Отдельно радует именование, блять, параметров: ca-file или cafile???
А может лучше certificate-authority.
Не можем решить и оставим все три варианта!
Четыреждыблядская ярость. На этом месте я подумал что может ну его нахуй и не так уж сильно я хочу изучить Kubernetes.

The API server’s TLS certificate (and certificate authority)

• --tls-cert-file string

File containing the default x509 Certificate for HTTPS. (CA cert, if any, concatenated after server cert). If HTTPS serving is enabled, and --tls-cert-file and --tls-private-key-file are not provided, a self-signed certificate and key are generated for the public address and saved to /var/run/kubernetes.

• --tls-private-key-filestring

File containing the default x509 private key matching --tls-cert-file.

Ссылки

• https://jvns.ca/blog/2017/08/05/how-kubernetes-certificates-work/
• https://kubernetes.io/docs/setup/best-practices/certificates/
• https://gist.github.com/detiber/81b515df272f5911959e81e39137a8bb