Сертифікати PKI та вимоги
Kubernetes вимагає наявності сертифікатів PKI для автентифікації за допомогою TLS. Якщо ви встановлюєте Kubernetes за допомогою kubeadm, сертифікати, необхідні для вашого кластера, генеруються автоматично. Ви також можете створити свої власні сертифікати, наприклад, щоб зберігати ваші приватні ключі більш безпечно, не зберігаючи їх на сервері API. Ця сторінка пояснює, які сертифікати необхідні для вашого кластера.
Як кластер використовує сертифікати
Kubernetes вимагає PKI для наступних операцій:
- Сертифікати клієнта для kubelet для автентифікації на сервері API
- Сертифікати сервера kubelet для спілкування сервера API з kubelet
- Сертифікат для точки доступу сервера API
- Сертифікати клієнта для адміністраторів кластера для автентифікації на сервері API
- Сертифікати клієнта для сервера API для спілкування з kubelet
- Сертифікат клієнта для сервера API для спілкування з etcd
- Сертифікат клієнта/kubeconfig для менеджера контролера для спілкування з сервером API
- Сертифікат клієнта/kubeconfig для планувальника для спілкування з сервером API.
- Сертифікати клієнта та сервера для проксі-сервера
Примітка:
Сертифікатиfront-proxy потрібні лише в разі використання kube-proxy для підтримки
розширеного API-сервера.etcd також реалізує взаємну аутентифікацію TLS для автентифікації клієнтів.
Де зберігаються сертифікати
Якщо ви встановлюєте Kubernetes за допомогою kubeadm, більшість сертифікатів зберігається в /etc/kubernetes/pki. Усі шляхи в цьому документі стосуються цієї теки, за винятком сертифікатів облікових записів користувачів, які kubeadm розміщує в /etc/kubernetes.
Налаштування сертифікатів вручну
Якщо ви не хочете, щоб kubeadm генерував необхідні сертифікати, ви можете створити їх за допомогою одного кореневого ЦС або подавши всі сертифікати. Детальні відомості щодо створення власного центра сертифікації дивіться в Сертифікати. Додаткові відомості знаходяться в розділі Certificate Management з kubeadm.
Один кореневий ЦС
Ви можете створити один кореневий ЦС, яким керує адміністратор. Цей кореневий ЦС може створювати кілька проміжних ЦС та делегувати весь подальший процес створення Kubernetes.
Необхідні ЦС:
| шлях | Типовий CN | опис |
|---|---|---|
| ca.crt,key | kubernetes-ca | Загальний ЦС Kubernetes |
| etcd/ca.crt,key | etcd-ca | Для всіх функцій, повʼязаних з etcd |
| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | Для проксі-сервера |
На додачу до цих ЦС також необхідно отримати пару ключ/сертифікат для управління обліковими записами служби, sa.key та sa.pub. Наведений нижче приклад ілюструє файли ключа та сертифіката ЦС, показані в попередній таблиці:
/etc/kubernetes/pki/ca.crt
/etc/kubernetes/pki/ca.key
/etc/kubernetes/pki/etcd/ca.crt
/etc/kubernetes/pki/etcd/ca.key
/etc/kubernetes/pki/front-proxy-ca.crt
/etc/kubernetes/pki/front-proxy-ca.key
Усі сертифікати
Якщо ви не хочете копіювати приватні ключі ЦС до свого кластера, ви можете створити всі сертифікати самостійно.
Необхідні сертифікати:
| Типовий CN | Батьківський ЦС | O (в обʼєкті) | вид | hosts (SAN) |
|---|---|---|---|---|
| kube-etcd | etcd-ca | server, client | <hostname>, <Host_IP>, localhost, 127.0.0.1 | |
| kube-etcd-peer | etcd-ca | server, client | <hostname>, <Host_IP>, localhost, 127.0.0.1 | |
| kube-etcd-healthcheck-client | etcd-ca | client | ||
| kube-apiserver-etcd-client | etcd-ca | client | ||
| kube-apiserver | kubernetes-ca | server | <hostname>, <Host_IP>, <advertise_IP>, [1] | |
| kube-apiserver-kubelet-client | kubernetes-ca | system:masters | client | |
| front-proxy-client | kubernetes-front-proxy-ca | client |
Примітка:
Замість використання групи суперкористувачаsystem:masters для kube-apiserver-kubelet-client, може бути використана менш привілейована група. kubeadm використовує групу kubeadm:cluster-admins для цієї мети.[1]: будь-яка інша IP-адреса чи DNS-імʼя, за яким ви звертаєтеся до свого кластера (що використовується kubeadm для стабільної IP-адреси або DNS-імені балансування навантаження, kubernetes, kubernetes.default, kubernetes.default.svc, kubernetes.default.svc.cluster, kubernetes.default.svc.cluster.local)
де kind посилається на один або кілька ключів x509, які також документовані в .spec.usages типу CertificateSigningRequest:
| kind | Використання ключа |
|---|---|
| server | цифровий підпис, шифрування ключа, автентифікація сервера |
| client | цифровий підпис, шифрування ключа, автентифікація клієнта |
Примітка:
Hosts/SAN, наведені вище, є рекомендованими для отримання робочого кластера; якщо вимагається для конкретного налаштування, можливе додавання додаткових SAN до всіх сертифікатів сервера.Примітка:
Лише для користувачів kubeadm:
- Сценарій, коли ви копіюєте сертифікати ЦС до свого кластера без приватних ключів, називається зовнішнім ЦС у документації kubeadm.
- Якщо ви порівнюєте цей список зі згенерованим kubeadm PKI, слід мати на увазі, що сертифікати
kube-etcd,kube-etcd-peerтаkube-etcd-healthcheck-clientне генеруються в разі зовнішнього etcd.
Шляхи до сертифікатів
Сертифікати повинні бути розміщені в рекомендованому шляху (який використовує kubeadm). Шляхи повинні бути вказані за вказаним аргументом незалежно від місця розташування.
| Типовий CN | рекомендований шлях до ключа | рекомендований шлях до сертифіката | команда | аргумент ключа | аргумент сертифіката |
|---|---|---|---|---|---|
| etcd-ca | etcd/ca.key | etcd/ca.crt | kube-apiserver | --etcd-cafile | |
| kube-apiserver-etcd-client | apiserver-etcd-client.key | apiserver-etcd-client.crt | kube-apiserver | --etcd-keyfile | --etcd-certfile |
| kubernetes-ca | ca.key | ca.crt | kube-apiserver | --client-ca-file | |
| kubernetes-ca | ca.key | ca.crt | kube-controller-manager | --cluster-signing-key-file | --client-ca-file, --root-ca-file, --cluster-signing-cert-file |
| kube-apiserver | apiserver.key | apiserver.crt | kube-apiserver | --tls-private-key-file | --tls-cert-file |
| kube-apiserver-kubelet-client | apiserver-kubelet-client.key | apiserver-kubelet-client.crt | kube-apiserver | --kubelet-client-key | --kubelet-client-certificate |
| front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-apiserver | --requestheader-client-ca-file | |
| front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-controller-manager | --requestheader-client-ca-file | |
| front-proxy-client | front-proxy-client.key | front-proxy-client.crt | kube-apiserver | --proxy-client-key-file | --proxy-client-cert-file |
| etcd-ca | etcd/ca.key | etcd/ca.crt | etcd | --trusted-ca-file, --peer-trusted-ca-file | |
| kube-etcd | etcd/server.key | etcd/server.crt | etcd | --key-file | --cert-file |
| kube-etcd-peer | etcd/peer.key | etcd/peer.crt | etcd | --peer-key-file | --peer-cert-file |
| etcd-ca | etcd/ca.crt | etcdctl | --cacert | ||
| kube-etcd-healthcheck-client | etcd/healthcheck-client.key | etcd/healthcheck-client.crt | etcdctl | --key | --cert |
Ті ж самі вимоги стосуються пари ключів облікових записів служби:
| Шлях приватного ключа | Шлях публічного ключа | команда | аргумент |
|---|---|---|---|
| sa.key | kube-controller-manager | --service-account-private-key-file | |
| sa.pub | kube-apiserver | --service-account-key-file |
Наведений нижче приклад ілюструє повні шляхи до файлів, перерахованих в попередній таблиці:
/etc/kubernetes/pki/etcd/ca.key
/etc/kubernetes/pki/etcd/ca.crt
/etc/kubernetes/pki/apiserver-etcd-client.key
/etc/kubernetes/pki/apiserver-etcd-client.crt
/etc/kubernetes/pki/ca.key
/etc/kubernetes/pki/ca.crt
/etc/kubernetes/pki/apiserver.key
/etc/kubernetes/pki/apiserver.crt
/etc/kubernetes/pki/apiserver-kubelet-client.key
/etc/kubernetes/pki/apiserver-kubelet-client.crt
/etc/kubernetes/pki/front-proxy-ca.key
/etc/kubernetes/pki/front-proxy-ca.crt
/etc/kubernetes/pki/front-proxy-client.key
/etc/kubernetes/pki/front-proxy-client.crt
/etc/kubernetes/pki/etcd/server.key
/etc/kubernetes/pki/etcd/server.crt
/etc/kubernetes/pki/etcd/peer.key
/etc/kubernetes/pki/etcd/peer.crt
/etc/kubernetes/pki/etcd/healthcheck-client.key
/etc/kubernetes/pki/etcd/healthcheck-client.crt
/etc/kubernetes/pki/sa.key
/etc/kubernetes/pki/sa.pub
Налаштування сертифікатів для облікових записів користувачів
Ви повинні вручну налаштувати ці облікові записи адміністратора та службові облікові записи:
| ім'я файлу | ім'я облікового запису | Типовий CN | O (в обʼєкті) |
|---|---|---|---|
| admin.conf | default-admin | kubernetes-admin | <admin-group> |
| super-admin.conf | default-super-admin | kubernetes-super-admin | system:masters |
| kubelet.conf | default-auth | system:node:<nodeName> (див. примітку) | system:nodes |
| controller-manager.conf | default-controller-manager | system:kube-controller-manager | |
| scheduler.conf | default-scheduler | system:kube-scheduler |
Примітка:
Значення<nodeName> для kubelet.conf має точно відповідати значенню імені вузла, наданому kubeadm, оскільки він реєструється з apiserver. Докладніше див. Авторизація вузлів.Примітка:
В вищенаведеному прикладі <admin-group> є специфічним для реалізації. Деякі інструменти підписують сертифікат у типовий конфігурації admin.conf, щоб він став частиною групи system:masters. system:masters — це привілейована група, яка може обходити рівень авторизації Kubernetes, такий як RBAC. Також деякі інструменти не генерують окремий super-admin.conf із сертифікатом, повʼязаним із цією групою суперкористувачів.
kubeadm генерує два окремих сертифікати адміністратора у файлах kubeconfig. Один у файлі admin.conf і має Subject: O = kubeadm:cluster-admins, CN = kubernetes-admin. kubeadm:cluster-admins — це власна група, повʼязана з роллю кластера cluster-admin. Цей файл генерується на всіх машинах панелі управління під контролем kubeadm.
Інший у файлі super-admin.conf із Subject: O = system:masters, CN = kubernetes-super-admin. Цей файл генерується лише на вузлі, де було викликано kubeadm init.
Для кожної конфігурації створіть пару ключ/сертифікат x509 із зазначеними CN та O.
Виконайте команду
kubectlдля кожної конфігурації наступним чином:
KUBECONFIG=<filename> kubectl config set-cluster default-cluster --server=https://<host ip>:6443 --certificate-authority <path-to-kubernetes-ca> --embed-certs
KUBECONFIG=<filename> kubectl config set-credentials <credential-name> --client-key <path-to-key>.pem --client-certificate <path-to-cert>.pem --embed-certs
KUBECONFIG=<filename> kubectl config set-context default-system --cluster default-cluster --user <credential-name>
KUBECONFIG=<filename> kubectl config use-context default-system
Ці файли використовуються наступним чином:
| Ім'я файлу | Команда | Коментар |
|---|---|---|
| admin.conf | kubectl | Налаштовує користувача-адміністратора для кластера |
| super-admin.conf | kubectl | Налаштовує користувача-суперадміністратора для кластера |
| kubelet.conf | kubelet | Один обовʼязковий для кожного вузла в кластері |
| controller-manager.conf | kube-controller-manager | Має бути доданий до manifests/kube-controller-manager.yaml |
| scheduler.conf | kube-scheduler | Має бути доданий до manifests/kube-scheduler.yaml |
Наведені нижче файли ілюструють повні шляхи до файлів, перерахованих у попередній таблиці:
/etc/kubernetes/admin.conf
/etc/kubernetes/super-admin.conf
/etc/kubernetes/kubelet.conf
/etc/kubernetes/controller-manager.conf
/etc/kubernetes/scheduler.conf