TLS

• 1: Налаштування ротації сертифікатів для kubelet
• 2: Ручна ротація сертифікатів центру сертифікації (CA)

1 - Налаштування ротації сертифікатів для kubelet

На цій сторінці показано, як увімкнути й налаштувати ротацію сертифікатів для kubelet.

Перш ніж ви розпочнете

• Потрібна версія Kubernetes 1.8.0 або новіша

Огляд

kubelet використовує сертифікати для автентифікації в API Kubernetes. Стандартно ці сертифікати видаються на один рік, щоб їх не потрібно було оновлювати надто часто.

Kubernetes містить ротацію сертифікатів kubelet, яка автоматично генерує новий ключ і запитує новий сертифікат в API Kubernetes, коли строк дії поточного сертифіката наближається до завершення. Щойно новий сертифікат стане доступним, він використовуватиметься для автентифікації зʼєднань з API Kubernetes.

Увімкнення ротації клієнтських сертифікатів

Процес kubelet приймає аргумент --rotate-certificates, який визначає, чи автоматично kubelet запитуватиме новий сертифікат, коли наближається завершення строку дії поточного сертифіката.

Процес kube-controller-manager приймає аргумент --cluster-signing-duration (--experimental-cluster-signing-duration до версії 1.19), який визначає, на який строк видаватимуться сертифікати.

Розуміння налаштувань ротації сертифікатів

Якщо під час запуску kubelet налаштований на початкове завантаження (за допомогою прапорця --bootstrap-kubeconfig), він використає свій початковий сертифікат, щоб підʼєднатися до API Kubernetes і надіслати запит на підписання сертифіката. Переглянути стан запитів на підписання сертифікатів можна за допомогою:

kubectl get csr

Спочатку запит на підписання сертифіката від kubelet на вузлі матиме статус Pending. Якщо запит відповідає певним критеріям, менеджер контролерів автоматично схвалить його, і він матиме статус Approved. Далі менеджер контролерів підпише сертифікат, виданий на строк, вказаний параметром --cluster-signing-duration, і підписаний сертифікат буде прикріплено до запиту на підписання сертифіката.

kubelet отримає підписаний сертифікат з API Kubernetes і запише його на диск у місце, вказане в --cert-dir. Потім kubelet використовуватиме новий сертифікат для підʼєднання до API Kubernetes.

Коли наближається завершення строку дії підписаного сертифіката, kubelet автоматично надсилає новий запит на підписання сертифіката через API Kubernetes. Це може статися в будь-який момент, коли лишається від 30% до 10% строку дії сертифіката. Менеджер контролерів знову автоматично схвалює запит на сертифікат і прикріплює підписаний сертифікат до запиту на підписання сертифіката. kubelet отримує новий підписаний сертифікат з API Kubernetes і записує його на диск. Потім він оновлює свої зʼєднання з API Kubernetes, щоб перепідʼєднатися з новим сертифікатом.

2 - Ручна ротація сертифікатів центру сертифікації (CA)

На цій сторінці показано, як вручну виконати ротацію сертифікатів центру сертифікації (CA).

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

• iximiuz Labs
• Killercoda
• KodeKloud

• Докладніше про автентифікацію в Kubernetes дивіться в розділі Автентифікація.
• Докладніше про рекомендації щодо сертифікатів CA дивіться в розділі Один кореневий CA.

Ручна ротація сертифікатів CA

1. Розподіліть нові сертифікати CA й приватні ключі (наприклад, ca.crt, ca.key, front-proxy-ca.crt і front-proxy-ca.key) на всі вузли панелі управління в теку сертифікатів Kubernetes.

2. Оновіть прапорець --root-ca-file для kube-controller-manager, щоб він містив і старий, і новий CA, а потім перезапустіть kube-controller-manager.

   Будь-який ServiceAccount, створений після цього, отримає Secrets, що містять і старий, і новий CA.

   Примітка:

   Файли, вказані у прапорцях kube-controller-manager --client-ca-file і --cluster-signing-cert-file, не можуть бути наборами CA. Якщо ці прапорці та --root-ca-file вказують на той самий файл ca.crt, який тепер є набором (містить і старий, і новий CA), ви отримаєте помилку. Щоб обійти цю проблему, скопіюйте новий CA в окремий файл і вкажіть цю копію в прапорцях --client-ca-file і --cluster-signing-cert-file. Коли ca.crt більше не буде набором, ви зможете знову вказати ca.crt у цих прапорцях і видалити копію.

   Issue 1350 для kubeadm відстежує помилку, через яку kube-controller-manager не може прийняти набір CA.

3. Зачекайте, поки менеджер контролерів оновить ca.crt у Secrets для ServiceAccount, щоб вони містили і старі, і нові сертифікати CA.

   Якщо якісь Podʼи запускаються до того, як API-сервери почнуть використовувати новий CA, нові Podʼи отримають це оновлення й довірятимуть і старим, і новим CA.

4. Перезапустіть усі Podʼи, що використовують конфігурації всередині кластера (наприклад, kube-proxy, CoreDNS тощо), щоб вони могли використовувати оновлені дані центру сертифікації із Secrets, повʼязаних із ServiceAccounts.

   • Переконайтеся, що CoreDNS, kube-proxy та інші Podʼи, які використовують конфігурації всередині кластера, працюють належним чином.

5. Додайте і старий, і новий CA до файлу, вказаного у прапорцях --client-ca-file і --kubelet-certificate-authority, у конфігурації kube-apiserver.

6. Додайте і старий, і новий CA до файлу, вказаного у прапорці --client-ca-file, у конфігурації kube-scheduler.

7. Оновіть сертифікати облікових записів користувачів, замінивши вміст client-certificate-data і client-key-data відповідно.

   Докладніше про створення сертифікатів для окремих облікових записів користувачів дивіться в розділі Налаштування сертифікатів для облікових записів користувачів.

   Крім того, оновіть розділ certificate-authority-data у файлах kubeconfig, вказавши відповідно закодовані в Base64 дані старого й нового центру сертифікації.

8. Оновіть прапорець --root-ca-file для Cloud Controller Manager, щоб він містив і старий, і новий CA, а потім перезапустіть cloud-controller-manager.

   Примітка:

   Якщо у вашому кластері немає cloud-controller-manager, цей крок можна пропустити.

9. Виконайте наведені нижче кроки поетапно.

   1. Перезапустіть усі інші агреговані API-сервери або обробники вебхуків, щоб вони довіряли новим сертифікатам CA.

   2. Перезапустіть kubelet, оновивши файл, вказаний у clientCAFile у конфігурації kubelet, і certificate-authority-data у kubelet.conf, щоб використовувати і старий, і новий CA на всіх вузлах.

      Якщо ваш kubelet не використовує ротацію клієнтських сертифікатів, оновіть client-certificate-data і client-key-data у kubelet.conf на всіх вузлах, а також файл клієнтського сертифіката kubelet, який зазвичай міститься в /var/lib/kubelet/pki.

   3. Перезапустіть API-сервери із сертифікатами (apiserver.crt, apiserver-kubelet-client.crt і front-proxy-client.crt), підписаними новим CA. Ви можете використовувати наявні або нові приватні ключі. Якщо ви змінили приватні ключі, оновіть їх і в теці сертифікатів Kubernetes.

      Оскільки Podʼи у вашому кластері довіряють і старим, і новим CA, буде короткочасне відʼєднання, після якого клієнти Kubernetes у Podʼах перепідʼєднаються до нового API-сервера. Новий API-сервер використовує сертифікат, підписаний новим CA.

      • Перезапустіть kube-scheduler, щоб він використовував нові CA й довіряв їм.
      • Переконайтеся, що логи компонентів панелі управління не містять помилок TLS.

      Примітка:

        Щоб згенерувати сертифікати й приватні ключі для вашого кластера за допомогою інструмента командного рядка `openssl`, дивіться [Сертифікати (`openssl`)](/docs/tasks/administer-cluster/certificates/#openssl). Також можна використовувати [`cfssl`](/docs/tasks/administer-cluster/certificates/#cfssl).
      

   4. Додайте анотації до DaemonSets і Deployments, щоб запустити заміну Podʼів безпечнішим поетапним способом.

      for namespace in $(kubectl get namespace -o jsonpath='{.items[*].metadata.name}'); do
          for name in $(kubectl get deployments -n $namespace -o jsonpath='{.items[*].metadata.name}'); do
              kubectl patch deployment -n ${namespace} ${name} -p '{"spec":{"template":{"metadata":{"annotations":{"ca-rotation": "1"}}}}}';
          done
          for name in $(kubectl get daemonset -n $namespace -o jsonpath='{.items[*].metadata.name}'); do
              kubectl patch daemonset -n ${namespace} ${name} -p '{"spec":{"template":{"metadata":{"annotations":{"ca-rotation": "1"}}}}}';
          done
      done
      

      Примітка:

        Щоб обмежити кількість одночасних порушень, яких зазнає ваш застосунок, дивіться [налаштування бюджету порушень Podʼів](/docs/tasks/run-application/configure-pdb/).
      

      Залежно від того, як ви використовуєте StatefulSets, вам також може знадобитися виконати подібну поетапну заміну.

10. Якщо ваш кластер використовує токени початкового завантаження для приєднання вузлів, оновіть ConfigMap cluster-info у просторі імен kube-public, додавши новий CA.

    base64_encoded_ca="$(base64 -w0 /etc/kubernetes/pki/ca.crt)"
    
    kubectl get cm/cluster-info --namespace kube-public -o yaml | \
        /bin/sed "s/\(certificate-authority-data:\).*/\1 ${base64_encoded_ca}/" | \
        kubectl apply -f -
    

11. Перевірте роботу кластера.

    1. Перевірте логи компонентів панелі управління, а також kubelet і kube-proxy. Переконайтеся, що ці компоненти не повідомляють про помилки TLS; докладніше дивіться в розділі перегляд логів.

    2. Перевірте логи агрегованих API-серверів і Podʼів, що використовують конфігурацію всередині кластера.

12. Після успішної перевірки роботи кластера:

    1. Оновіть усі токени ServiceAccount, щоб вони містили лише новий сертифікат CA.

       • Усі Podʼи, що використовують kubeconfig всередині кластера, зрештою потрібно буде перезапустити, щоб вони отримали новий Secret і жоден Pod не залежав від старого CA кластера.

    2. Перезапустіть компоненти панелі управління, вилучивши старий CA з файлів kubeconfig і файлів, вказаних у прапорцях --client-ca-file і --root-ca-file відповідно.

    3. На кожному вузлі перезапустіть kubelet, вилучивши старий CA з файлу, вказаного в прапорці clientCAFile, і з файлу kubeconfig kubelet. Виконуйте це як поетапне оновлення.

       Якщо ваш кластер дозволяє внести цю зміну, ви також можете розгорнути її заміною вузлів, а не їх переналаштуванням.