Всем привет. Меня зовут Добрый Кот.
Хочу поделиться с вами некоторым мыслями на тему сертификатов в кубе.
** Будет серия статей в которой постараюсь расписать опыт перехода от самоподписных сертификатов, в сторону централизованного выписывания и интеграцией с Vault.
*** В этой статье будет затронута тема организации сертификатов.
Думаю многие уже не раз разворачивали k8s кластера разными инструментами (kubespray, kubeadm, hardway, или просто брали менедж куб от облачных провайдеров) и все эти решения делаю за вас ряд итераций, которые когда-то кто-то делал руками — как ни как в эпоху автоматизаций живем. Но кто из вас на память вспомнит из скольки сертификатов состоит куб, сколько CA, у кого какой CN, Organization, Usage и т.п.
Сколько из вас с первой попытки соберет пазл с сертификатами через путь джедая?)
Итак. Начну сразу с картинки то как выглядят сертификаты сверху.
Если сильно не накосячил то должно получиться в среднем 13 сертификатов и 3 CA и 3 kubeconfig-a которые имеют доступ к k8s-api. (kube-proxy — вместо него использую cilium )
Замечу несколько интересных наблюдений:
-
Все CA используют только публичные сертификаты в конфигах control-plane (пригодится информация чуть позже)
-
kube-controller-manager использует root-ca-key для выпуска сертификатов
-
Сертификат etcd-health-check-client — не используется ни в одной конфигурации (для etcdctl)*
И давайте заглянем внутрь сертификатов — посмотрим, что у них внутри.
|
Компонент |
key |
name |
CN |
Organization |
Usages |
CA |
|
etcd |
—trusted-ca-file |
etcd-ca |
(any) |
(any) |
CA |
etcd-ca |
|
|
—cert-file |
etcd-server |
(any) |
(any) |
DigitalSignature,KeyEncipherment,ServerAuth |
etcd-ca |
|
|
-key-file |
etcd-server-key |
— |
— |
— |
— |
|
|
—peer-trusted-ca-file |
etcd-peer |
(any) |
(any) |
DigitalSignature,KeyEncipherment,ServerAuth,ClientAuth |
etcd-ca |
|
|
—peer-key-file |
etcd-peer-key |
— |
— |
— |
— |
|
|
|
|
|
|
|
|
|
etcdctl |
—cert |
etcd-health-check-client |
(any) |
DigitalSignature,KeyEncipherment,ClientAuth |
etcd-ca |
|
|
|
—key |
etcd-health-check-client-key |
— |
— |
— |
— |
|
|
|
|
|
|
|
|
|
kube-apiserver |
—client-ca-file |
root-ca |
(any) |
(any) |
CA |
root-ca |
|
|
—tls-cert-file |
kube-apiserver-server |
(any) |
(any) |
DigitalSignature,KeyEncipherment,ServerAuth |
root-ca |
|
|
—tls-private-key-file |
kube-apiserver-server-key |
— |
— |
— |
|
|
|
—etcd-cafile |
etcd-ca |
(any) |
(any) |
CA |
etcd-ca |
|
|
—etcd-certfile |
kube-apiserver-etcd-client |
(any) |
(any) |
DigitalSignature,KeyEncipherment,ClientAuth |
etcd-ca |
|
|
—etcd-keyfile |
kube-apiserver-etcd-client-key |
— |
— |
— |
— |
|
|
—kubelet-client-certificate |
kube-apiserver-kubelet-client |
(any) |
system:masters |
DigitalSignature,KeyEncipherment,ClientAuth |
root-ca |
|
|
—kubelet-client-key |
kube-apiserver-kubelet-client-key |
— |
— |
— |
— |
|
|
—proxy-client-cert-file |
front-proxy-client |
(any) |
(any) |
DigitalSignature,KeyEncipherment,ClientAuth |
front-proxy-ca |
|
|
—requestheader-client-ca-file |
front-proxy-ca |
(any) |
(any) |
CA |
fron-proxy-ca |
|
|
—service-account-key-file |
SA*-pub |
— |
— |
— |
— |
|
|
—service-account-signing-key-file |
SA*-key |
— |
— |
— |
— |
|
|
|
|
|
|
|
|
|
kube-controller-manager |
—root-ca-file |
root-ca |
(any) |
(any) |
CA |
root-ca |
|
|
—client-ca-file |
root-ca |
(any) |
(any) |
CA |
root-ca |
|
|
—requestheader-client-ca-file |
frot-proxy-ca |
(any) |
(any) |
CA |
frot-proxy-ca |
|
|
—tls-cert-file |
kube-controller-manager-server |
(any) |
(any) |
DigitalSignature,KeyEncipherment,ServerAuth |
root-ca |
|
|
—tls-private-key-file |
kube-controller-manager-server-key |
— |
— |
— |
— |
|
|
—cluster-signing-cert-file |
root-ca |
(any) |
(any) |
CA |
root-ca |
|
|
—cluster-signing-key-file |
root-ca-key |
— |
— |
— |
— |
|
|
—service-account-private-key-file |
SA*-key |
— |
— |
— |
— |
|
|
kubeconfig |
kube-controller-manager-client |
system:kube-controller-manager |
(any) |
DigitalSignature,KeyEncipherment,ClientAuth |
root-ca |
|
|
|
|
|
|
|
|
|
kube-scheduler |
—client-ca-file |
root-ca |
(any) |
(any) |
CA |
root-ca |
|
|
—requestheader-client-ca-file |
fron-proxy-ca |
(any) |
(any) |
CA |
fron-proxy-ca |
|
|
—tls-cert-file |
kube-scheduler-server |
(any) |
(any) |
DigitalSignature,KeyEncipherment,ServerAuth |
root-ca |
|
|
—tls-private-key-file |
kube-scheduler-server-key |
|
|
|
|
|
|
kubeconfig |
kube-scheduler-client |
system:kube-scheduler |
(any) |
DigitalSignature,KeyEncipherment,ClientAuth |
root-ca |
|
kubelet |
kubeconfig |
kubelet-client |
system:node:{hostname} |
system:node |
DigitalSignature,KeyEncipherment,ClientAuth |
root-ca |
|
CN |
Organization |
Cluster Role |
type |
|
system:kube-scheduler |
|
system:volume-scheduler |
User |
|
system:kube-scheduler |
|
system:kube-scheduler |
User |
|
|
|
|
|
|
system:kube-controller-manager |
|
system:kube-controller-manager |
User |
|
|
|
|
|
|
|
system:node |
system:node |
Group |
|
|
system:masters |
cluster-admin |
Group |
*(any) — можно указывать любое значение кроме system:* если не хотите случайно навесить лишние права в k8s
Резюмируя хотел бы сказать: Разобрав визуально и детально мы видим какие сертификаты +- безопасны, а какие рискованные.
К КРИТ я бы отнес: CA.key , Client [ou=system:masters]. В базовой конфигурации, кража этих сертификатов влечет за собой компрометацию и долгое время реагирования (сменить все сертификаты в кластере, в том числе и рут это не тривиал задача)
P.S Все выше написанное ИМХО и может отличаться от вашего мнения, по неточностям в статье, буду рад услышать комментарии и разумную критику. Всем пис.
полезное чтиво:
https://kubernetes.io/docs/setup/best-practices/certificates/
https://etcd.io/docs/v3.2/op-guide/security/
https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/
https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/
https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/
ссылка на оригинал статьи https://habr.com/ru/post/673730/
Добавить комментарий