Модуль 2.4: PKI та сертифікати

Складність: [СЕРЕДНЯ] - Основні знання

Час на виконання: 25-30 хвилин

Передумови: Модуль 2.3: Мережева безпека

Що ви зможете робити

Після завершення цього модуля ви зможете:

Пояснити архітектуру PKI Kubernetes та які сертифікати потрібні кожному компоненту
Оцінити ризики безпеки сертифікатів: прострочені сертифікати, слабкі розміри ключів та відсутність ротації
Оцінити потоки автентифікації на основі сертифікатів між API server, kubelet та etcd
Визначити поширені помилки конфігурації PKI, що призводять до збоїв автентифікації або прогалин безпеки

Чому цей модуль важливий

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

Неправильне управління сертифікатами є поширеним джерелом як вразливостей безпеки, так і операційних проблем.

Архітектура PKI Kubernetes

┌─────────────────────────────────────────────────────────────┐
│              PKI KUBERNETES                                  │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│                      CA КЛАСТЕРА                            │
│                          │                                  │
│            ┌─────────────┼─────────────┐                   │
│            │             │             │                    │
│            ▼             ▼             ▼                    │
│      ┌─────────┐   ┌─────────┐   ┌─────────┐              │
│      │ API     │   │ etcd    │   │ Front   │              │
│      │ Server  │   │ CA      │   │ Proxy   │              │
│      │ серт.   │   │         │   │ CA      │              │
│      └─────────┘   └─────────┘   └─────────┘              │
│            │                                                │
│            ├── клієнтські сертифікати kubelet              │
│            ├── клієнтський сертифікат controller-manager   │
│            ├── клієнтський сертифікат scheduler            │
│            └── клієнтські сертифікати admin/user           │
│                                                             │
│  ОКРЕМІ CA:                                                │
│  • CA кластера - підписує більшість сертифікатів           │
│  • CA etcd - може бути окремим для ізоляції                │
│  • CA Front Proxy - для рівня агрегації                    │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Типи сертифікатів у Kubernetes

Серверні сертифікати

Компонент	Призначення сертифіката
API Server	Підтверджує ідентифікацію клієнтам
etcd	Підтверджує ідентифікацію API server
kubelet	Підтверджує ідентифікацію для свого серверного API

Клієнтські сертифікати

Клієнт	З’єднується з	CN (Common Name)	O (Organization/Groups)
kubelet	API Server	system:node:nodename	system:nodes
controller-manager	API Server	system:kube-controller-manager
scheduler	API Server	system:kube-scheduler
admin	API Server	kubernetes-admin	system:masters

Поля CN та O

Поля сертифіката відображаються на ідентифікацію Kubernetes:

┌─────────────────────────────────────────────────────────────┐
│              СЕРТИФІКАТ → ІДЕНТИФІКАЦІЯ KUBERNETES           │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  СЕРТИФІКАТ X.509                                          │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  Subject:                                           │   │
│  │    CN = system:node:worker-1                        │   │
│  │    O  = system:nodes                                │   │
│  └─────────────────────────────────────────────────────┘   │
│                         │                                   │
│                         ▼                                   │
│  ІДЕНТИФІКАЦІЯ KUBERNETES                                  │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  Username: system:node:worker-1                     │   │
│  │  Groups:   ["system:nodes"]                         │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  CN (Common Name) → ім'я користувача Kubernetes            │
│  O  (Organization) → групи Kubernetes (може бути кілька)   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Життєвий цикл сертифікатів

Термін дії

┌─────────────────────────────────────────────────────────────┐
│              ЗАКІНЧЕННЯ СЕРТИФІКАТІВ                         │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ТИПОВІ ПЕРІОДИ ДІЇ:                                      │
│  • CA кластера: 10 років (за замовчуванням kubeadm)        │
│  • Сертифікати компонентів: 1 рік (за замовчуванням)       │
│  • Клієнтські сертифікати kubelet: 1 рік                   │
│                                                             │
│  КОЛИ СЕРТИФІКАТИ ЗАКІНЧУЮТЬСЯ:                            │
│  • Компонент не може автентифікуватися                     │
│  • TLS-з'єднання не вдаються                              │
│  • Операції кластера ламаються                             │
│                                                             │
│  РОТАЦІЯ СЕРТИФІКАТІВ:                                     │
│  • Автоматична: авто-ротація kubelet (якщо увімкнено)     │
│  • Ручна: kubeadm certs renew                             │
│  • Керований K8s: Провайдер забезпечує                    │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Перевірка терміну дії сертифікатів

# Кластери kubeadm
kubeadm certs check-expiration

# Ручна перевірка з openssl
openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -dates

Токени Service Account

Service accounts використовують інший механізм, ніж сертифікати:

┌─────────────────────────────────────────────────────────────┐
│              ТОКЕНИ SERVICE ACCOUNT                          │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ЗАСТАРІЛІ ТОКЕНИ (до 1.24)                                │
│  • Зберігаються у Secrets                                  │
│  • Ніколи не закінчуються                                  │
│  • Монтуються до всіх подів автоматично                    │
│  • Ризик безпеки!                                          │
│                                                             │
│  ПРИВ'ЯЗАНІ ТОКЕНИ (1.24+)                                 │
│  • JWT, підписані API server                               │
│  • Обмежені за часом (за замовчуванням 1 година)            │
│  • Прив'язані до аудиторії                                 │
│  • Автоматично ротуються                                   │
│  • Проєктуються у поди через том                           │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Переваги прив’язаних токенів

Застарілі токени	Прив’язані токени
Ніколи не закінчуються	Обмежені за часом
Будь-яка аудиторія	Прив’язані до аудиторії
Зберігаються в Secret	Проєктований том
Ручна ротація	Авто-ротація
Зберігаються після видалення поду	Недійсні з подом

Чи знали ви?

Kubernetes не може відкликати сертифікати - немає вбудованого CRL або OCSP. Скомпрометований сертифікат дійсний до закінчення терміну. Тому короткотривалі сертифікати важливі.
Група system:masters надає доступ cluster-admin. Будь-який сертифікат з O=system:masters має повний контроль кластера.
Проєкція токенів service account була впроваджена для виправлення давньої проблеми безпеки безстрокових токенів у Secrets.
У керованому Kubernetes ви зазвичай ніколи не бачите приватний ключ CA. Провайдер управляє PKI, що є більш безпечним для більшості організацій.

Поширені помилки

Помилка	Чому це шкодить	Рішення
Ключ CA доступний багатьом	Повна компрометація кластера при витоку	Обмежити до мінімального доступу
Ігнорування терміну сертифікатів	Кластер перестає працювати	Моніторити та ротувати проактивно
Вільне використання O=system:masters	Занадто багато повних адмінів	Використовуйте відповідні групи
Застарілі токени service account	Ніколи не закінчуються	Прив’язані токени (1.24+)
Один CA для кількох кластерів	Компрометація впливає на всі	Окремі CA для кластера

Тест

Що відбувається, коли CN сертифіката встановлено “system:node:worker-1”, а O - “system:nodes”?

Відповідь
Сертифікат автентифікується як ім'я користувача "system:node:worker-1" у групі "system:nodes". Це стандартний формат ідентифікації для сертифікатів kubelet.
Чому Kubernetes не може відкликати сертифікати?

Відповідь
Kubernetes не має вбудованої підтримки CRL або OCSP. Після підписання сертифікат залишається дійсним до закінчення терміну. Тому важливі короткотривалі сертифікати та ротація.
Яке призначення TLS bootstrap?

Відповідь
TLS bootstrap дозволяє новим вузлам безпечно приєднуватися до кластера. Вузол використовує bootstrap-токен для запиту підписання сертифіката, і після затвердження отримує належний сертифікат для подальшої комунікації з API server.
Яка ключова відмінність між застарілими та прив’язаними токенами service account?

Відповідь
Застарілі токени ніколи не закінчуються та зберігаються у Secrets. Прив'язані токени обмежені за часом (зазвичай 1 година), прив'язані до аудиторії та проєктуються у поди через томи. Прив'язані токени більш безпечні.
Яка група надає повний доступ cluster-admin через автентифікацію сертифікатом?

Відповідь
system:masters. Будь-який сертифікат з O=system:masters у subject має повний адміністративний доступ до кластера.

Підсумок

PKI Kubernetes є фундаментом безпеки кластера:

Концепція	Ключові моменти
CA кластера	Корінь довіри - захищайте приватний ключ
Ідентифікація сертифіката	CN = ім’я користувача, O = групи
Термін дії	Сертифікати закінчуються - моніторте та ротуйте
Токени Service Account	Використовуйте прив’язані токени (1.24+)
TLS Bootstrap	Безпечний спосіб приєднання нових вузлів

Наступний модуль

Модуль 3.1: Безпека подів - SecurityContext, Pod Security Standards та безпека на рівні контейнерів.