TLS

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

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

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

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

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

Огляд

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

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

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

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

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

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

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

kubectl get csr

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

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

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

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

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

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

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

• Killercoda
• Play with Kubernetes

• Для отримання додаткової інформації про автентифікацію в 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, створений після цього, отримає Secretʼи, що містять як старий, так і новий 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 у Secretʼах облікових записів сервісів, щоб включити як старі, так і нові сертифікати CA.

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

4. Перезавантажте всі Podʼи, що використовують внутрішні конфігурації (наприклад: kube-proxy, CoreDNS тощо), щоб вони могли використовувати оновлені дані сертифікату центру сертифікації із Secretʼів, що повʼязані з 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`)](/uk/docs/tasks/administer-cluster/certificates/#openssl). Ви також можете використовувати [`cfssl`](/uk/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ʼів](/uk/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. Оновіть всі токени службових облікових записів, щоб включити лише новий сертифікат CA.

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

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

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

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

3 - Управління TLS сертифікатами в кластері

Kubernetes надає API certificates.k8s.io, який дозволяє вам отримувати TLS сертифікати, підписані Центром Сертифікації (CA), який ви контролюєте. Ці CA та сертифікати можуть використовуватися вашими робочими навантаженнями для встановлення довіри.

API certificates.k8s.io використовує протокол, подібний до чернетки ACME.

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

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

• Killercoda
• Play with Kubernetes

Вам потрібен інструмент cfssl. Ви можете завантажити cfssl з https://github.com/cloudflare/cfssl/releases.

Деякі кроки на цій сторінці використовують інструмент jq. Якщо у вас його немає, ви можете встановити його через джерела програмного забезпечення вашої операційної системи або завантажити з https://jqlang.github.io/jq/.

Довіра до TLS в кластері

Довіра до власного CA з боку застосунків, що працюють як Podʼи, зазвичай вимагає додаткової конфігурації. Вам потрібно додати пакет сертифікатів CA до списку сертифікатів CA, яким довіряє TLS клієнт або сервер. Наприклад, ви можете зробити це за допомогою налаштування TLS в Golang, проаналізувавши ланцюжок сертифікатів і додавши проаналізовані сертифікати до поля RootCAs в структурі tls.Config.

Запит сертифіката

Наступний розділ демонструє, як створити TLS сертифікат для Kubernetes сервісу, до якого звертаються через DNS.

Створення запиту на підписання сертифіката

Згенеруйте приватний ключ і запит на підписання сертифіката (або CSR), виконавши наступну команду:

cat <<EOF | cfssl genkey - | cfssljson -bare server
{
  "hosts": [
    "my-svc.my-namespace.svc.cluster.local",
    "my-pod.my-namespace.pod.cluster.local",
    "192.0.2.24",
    "10.0.34.2"
  ],
  "CN": "my-pod.my-namespace.pod.cluster.local",
  "key": {
    "algo": "ecdsa",
    "size": 256
  }
}
EOF

Де 192.0.2.24 — це кластерний IP Serviceʼу, my-svc.my-namespace.svc.cluster.local — це DNS-імʼя Serviceʼу, 10.0.34.2 —це IP Podʼа, а my-pod.my-namespace.pod.cluster.local — це DNS-імʼя Podʼа. Ви повинні побачити вивід подібний до:

2022/02/01 11:45:32 [INFO] generate received request
2022/02/01 11:45:32 [INFO] received CSR
2022/02/01 11:45:32 [INFO] generating key: ecdsa-256
2022/02/01 11:45:32 [INFO] encoded CSR

Ця команда генерує два файли; server.csr, що містить PEM закодований PKCS#10 запит на сертифікат, і server-key.pem, що містить PEM закодований ключ до сертифіката, який ще потрібно створити.

Створення обʼєкта CertificateSigningRequest для надсилання до Kubernetes API

Згенеруйте маніфест CSR (у форматі YAML) і надішліть його на сервер API. Ви можете зробити це, виконавши наступну команду:

cat <<EOF | kubectl apply -f -
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: my-svc.my-namespace
spec:
  request: $(cat server.csr | base64 | tr -d '\n')
  signerName: example.com/serving
  usages:
  - digital signature
  - key encipherment
  - server auth
EOF

Зверніть увагу, що файл server.csr, створений на кроці 1, кодується base64 та зберігається в полі .spec.request. Ви також запитуєте сертифікат з використанням ключів "digital signature", "key encipherment" і "server auth", підписаний підписувачем example.com/serving. Повинен бути запитаний конкретний signerName. Перегляньте документацію для підтримуваних імен підписувачів для отримання додаткової інформації.

CSR тепер має бути видимий з API у стані Pending. Ви можете побачити це, виконавши:

kubectl describe csr my-svc.my-namespace

Name:                   my-svc.my-namespace
Labels:                 <none>
Annotations:            <none>
CreationTimestamp:      Tue, 01 Feb 2022 11:49:15 -0500
Requesting User:        yourname@example.com
Signer:                 example.com/serving
Status:                 Pending
Subject:
        Common Name:    my-pod.my-namespace.pod.cluster.local
        Serial Number:
Subject Alternative Names:
        DNS Names:      my-pod.my-namespace.pod.cluster.local
                        my-svc.my-namespace.svc.cluster.local
        IP Addresses:   192.0.2.24
                        10.0.34.2
Events: <none>

Отримання схвалення CertificateSigningRequest

Схвалення запиту на підписання сертифіката виконується або автоматичною процедурою схвалення, або одноразово адміністратором кластера. Якщо у вас є дозвіл на схвалення запиту на сертифікат, ви можете зробити це вручну за допомогою kubectl; наприклад:

kubectl certificate approve my-svc.my-namespace

certificatesigningrequest.certificates.k8s.io/my-svc.my-namespace approved

Ви тепер повинні побачити наступне:

kubectl get csr

NAME                  AGE   SIGNERNAME            REQUEST

OR              REQUESTEDDURATION   CONDITION
my-svc.my-namespace   10m   example.com/serving   yourname@example.com   <none>              Approved

Це означає, що запит на сертифікат був схвалений і чекає на підписання запрошеним підписувачем.

Підписання CertificateSigningRequest

Далі ви зіграєте роль підписувача сертифікатів, видасте сертифікат і завантажите його в API.

Підписувач зазвичай спостерігає за API CertificateSigningRequest для обʼєктів з його signerName, перевіряє, що вони були схвалені, підписує сертифікати для цих запитів, і оновлює статус обʼєкта API з виданим сертифікатом.

Створення Центру Сертифікації

Вам потрібен центр сертифікації, щоб забезпечити цифровий підпис нового сертифікату.

Спочатку створіть підписний сертифікат, виконавши наступне:

cat <<EOF | cfssl gencert -initca - | cfssljson -bare ca
{
  "CN": "My Example Signer",
  "key": {
    "algo": "rsa",
    "size": 2048
  }
}
EOF

Ви повинні побачити вивід подібний до:

2022/02/01 11:50:39 [INFO] generating a new CA key and certificate from CSR
2022/02/01 11:50:39 [INFO] generate received request
2022/02/01 11:50:39 [INFO] received CSR
2022/02/01 11:50:39 [INFO] generating key: rsa-2048
2022/02/01 11:50:39 [INFO] encoded CSR
2022/02/01 11:50:39 [INFO] signed certificate with serial number 263983151013686720899716354349605500797834580472

Це створює файл ключа центру сертифікації (ca-key.pem) і сертифікат (ca.pem).

Видача сертифіката

tls/server-signing-config.json

{
    "signing": {
        "default": {
            "usages": [
                "digital signature",
                "key encipherment",
                "server auth"
            ],
            "expiry": "876000h",
            "ca_constraint": {
                "is_ca": false
            }
        }
    }
}

Використовуйте конфігурацію для підпису server-signing-config.json та файл ключа центру сертифікації та сертифікат для підпису запиту на сертифікат:

kubectl get csr my-svc.my-namespace -o jsonpath='{.spec.request}' | \
  base64 --decode | \
  cfssl sign -ca ca.pem -ca-key ca-key.pem -config server-signing-config.json - | \
  cfssljson -bare ca-signed-server

Ви повинні побачити вивід подібний до:

2022/02/01 11:52:26 [INFO] signed certificate with serial number 576048928624926584381415936700914530534472870337

Це створює файл підписаного серверного сертифіката, ca-signed-server.pem.

Завантаження підписаного сертифіката

Нарешті, вкажіть підписаний сертифікат у статусі обʼєкта API:

kubectl get csr my-svc.my-namespace -o json | \
  jq '.status.certificate = "'$(base64 ca-signed-server.pem | tr -d '\n')'"' | \
  kubectl replace --raw /apis/certificates.k8s.io/v1/certificatesigningrequests/my-svc.my-namespace/status -f -

Після схвалення CSR і завантаження підписаного сертифіката, виконайте:

kubectl get csr

Вивід буде подібним до:

NAME                  AGE   SIGNERNAME            REQUESTOR              REQUESTEDDURATION   CONDITION
my-svc.my-namespace   20m   example.com/serving   yourname@example.com   <none>              Approved,Issued

Завантаження сертифіката та його використання

Тепер, як запитувач, ви можете завантажити виданий сертифікат і зберегти його у файл server.crt, виконавши наступне:

kubectl get csr my-svc.my-namespace -o jsonpath='{.status.certificate}' \
    | base64 --decode > server.crt

Тепер ви можете заповнити server.crt і server-key.pem у Секрет, який ви можете пізніше монтувати в Pod (наприклад, для використання з вебсервером, який обслуговує HTTPS).

kubectl create secret tls server --cert server.crt --key server-key.pem

secret/server created

Нарешті, ви можете заповнити ca.pem у ConfigMap і використовувати його як кореневий довірчий сертифікат для перевірки серверного сертифіката:

kubectl create configmap example-serving-ca --from-file ca.crt=ca.pem

configmap/example-serving-ca created

Схвалення CertificateSigningRequests

Адміністратор Kubernetes (з відповідними дозволами) може вручну схвалювати (або відхиляти) CertificateSigningRequests за допомогою команд kubectl certificate approve та kubectl certificate deny. Однак, якщо ви плануєте активно використовувати цей API, варто розглянути можливість написання автоматизованого контролера сертифікатів.

Чи це буде машина або людина, яка використовує kubectl, роль схвалювача полягає у перевірці, що CSR відповідає двом вимогам:

1. Субʼєкт CSR контролює приватний ключ, який використовується для підписання CSR. Це зменшує ризик того, що є третя сторона, яка видає себе за авторизованого субʼєкта. У вищезазначеному прикладі цей крок передбачає перевірку того, що Pod контролює приватний ключ, який використовується для створення CSR.
2. Субʼєкт CSR має право діяти в запитуваному контексті. Це зменшує ризик появи небажаного субʼєкта, який приєднується до кластера. У вищезазначеному прикладі цей крок передбачає перевірку того, що Pod має дозвіл на участь у запитуваному сервісі.

Якщо і тільки якщо ці дві вимоги виконані, схвалювач повинен схвалити CSR інакше він повинен відхилити CSR.

Для отримання додаткової інформації про схвалення сертифікатів та контроль доступу, прочитайте сторінку довідника Запити на підписання сертифікатів.

Налаштування вашого кластера для виконання накладання підписів

Ця сторінка припускає, що підписувач налаштований для обслуговування API сертифікатів. Менеджер контролерів Kubernetes надає стандартну реалізацію підписувача. Щоб увімкнути його, передайте параметри --cluster-signing-cert-file та --cluster-signing-key-file до менеджера контролерів з шляхами до пари ключів вашого центру сертифікації.