K8s-pki: различия между версиями
Материал из noname.com.ua
Перейти к навигацииПерейти к поискуSirmax (обсуждение | вклад) |
Sirmax (обсуждение | вклад) |
||
| Строка 49: | Строка 49: | ||
# <PRE>--etcd-certfile string</PRE>SSL certification file used to secure etcd communication. |
# <PRE>--etcd-certfile string</PRE>SSL certification file used to secure etcd communication. |
||
# <PRE>--etcd-keyfile string</PRE>SSL key file used to secure etcd communication. |
# <PRE>--etcd-keyfile string</PRE>SSL key file used to secure etcd communication. |
||
| ⚫ | |||
| ⚫ | |||
| ⚫ | |||
| ⚫ | |||
| ⚫ | # <PRE>--proxy-client-cert-file string</PRE> 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. |
||
| ⚫ | |||
| ⚫ | |||
| ⚫ | |||
| ⚫ | # <PRE>--service-account-key-file stringArray</PRE> 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. |
||
| ⚫ | |||
| ⚫ | |||
| ⚫ | # <PRE>--tls-cert-file string</PRE> 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. |
||
| ⚫ | |||
| ⚫ | |||
| − | |||
| − | |||
| ⚫ | |||
| ⚫ | |||
| ⚫ | |||
| ⚫ | |||
| ⚫ | --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. |
||
| ⚫ | |||
| ⚫ | |||
| ⚫ | |||
| ⚫ | --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. |
||
| ⚫ | |||
| ⚫ | |||
| ⚫ | --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. |
||
| ⚫ | |||
| ⚫ | |||
| − | </PRE> |
||
Отдельно радует именование, блять, параметров: <B>ca-file</B> или <B>cafile</B>???<BR> |
Отдельно радует именование, блять, параметров: <B>ca-file</B> или <B>cafile</B>???<BR> |
||
А может лучше <B>certificate-authority</B>. <BR> |
А может лучше <B>certificate-authority</B>. <BR> |
||
Версия 15:51, 27 октября 2021
Заметка о 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 (ШЕСТНАДЦАТЬ, КАРЛ) аргументов которые так или иначе относятся к шифрованию:
--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")--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.--etcd-certfile string
SSL certification file used to secure etcd communication.--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.
