Примітка:
Це завдання охоплює шифрування даних ресурсів, збережених за допомогою Kubernetes API. Наприклад, ви можете шифрувати обʼєкти Secret, включаючи дані у формі ключ-значення.
Якщо ви хочете зашифрувати дані в файлових системах, які підключаються до контейнерів, вам замість цього потрібно або:
- використовуйте інтеграцію зберігання, яка забезпечує шифровані томи
- шифрувати дані всередині вашого власного застосунку
Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:
`', щоб зашифрувати всі ресурси у групі (наприклад, '`*.apps`' у вищезазначеному прикладі) або '`*.*`' для шифрування всіх ресурсів. '`*.`' може бути використаний для шифрування всіх ресурсів у групі ядра. '`*.*`' зашифрує всі ресурси, навіть власні ресурси, які додаються після запуску сервера API.
Примітка:
Використання символів підстановки, які перекриваються в тому ж списку ресурсів або між кількома елементами, не дозволяється, оскільки частина конфігурації буде неефективною. Порядок обробки та пріоритет списку resources визначаються порядком його вказання в конфігурації.
Якщо у вас є символ підстановки, який охоплює ресурси, і ви хочете відмовитися від шифрування у спокої певного типу ресурсу, ви можете досягати цього, додавши окремий елемент масиву `resources` з іменем ресурсу, який ви хочете виключити, за яким слідує елемент масиву `providers`, де ви вказуєте постачальника `identity`. Ви додаєте цей елемент до списку так, щоб він зʼявився раніше, ніж конфігурація, де ви вказуєте шифрування (постачальник, який не є `identity`).
Наприклад, якщо ввімкнено '`*.*`', і ви хочете відмовитися від шифрування для Events та ConfigMaps, додайте новий **раніший** елемент до `resources`, за яким слідує елемент масиву постачальників з `identity` як постачальник. Більш конкретний запис повинен зʼявитися перед записом з символом підстановки.
Новий елемент буде схожий на:
```yaml
...
- resources:
- configmaps. # спеціально з ядра API групи,
# через крапку в кінці
- events
providers:
- identity: {}
# а потім інші записи в resources
```
Переконайтеся, що виключення перераховане _до_ позначки символу підстановки '`*.*`' в масиві ресурсів, щоб надати йому пріоритет.
Для отримання більш детальної інформації про структуру `EncryptionConfiguration`, зверніться до [API конфігурації шифрування](/docs/reference/config-api/apiserver-config.v1/).
Увага:
Якщо будь-який ресурс не може бути прочитаний через конфігурацію шифрування (через зміну ключів) та ви не можете відновити робочу конфігурацію, єдиним виходом буде видалити цей ключ безпосередньо з підтримуваного etcd.
Будь-які виклики до API Kubernetes, які намагаються прочитати цей ресурс, завершаться невдачею, поки він не буде видалений або надано дійсний ключ для розшифрування.
Постачальники для шифрування у спокої Kubernetes
| Назва |
Шифрування |
Стійкість |
Швидкість |
Довжина ключа |
| identity |
Відсутнє |
Н/Д |
Н/Д |
Н/Д |
| Ресурси зберігаються як є без шифрування. Коли встановлено як перший постачальник, ресурс буде розшифрований при записі нових значень. Існуючі зашифровані ресурси автоматично не перезаписуються даними у відкритому тексті. Постачальник `identity` є типовим, якщо ви не вказали інше. |
| aescbc |
AES-CBC з використанням padding PKCS#7 |
Слабка |
Швидка |
16, 24 або 32 байти |
| Не рекомендується через вразливість CBC до атаки padding oracle attacks. Вміст ключа доступний з хоста панелі управління. |
| aesgcm |
AES-GCM з випадковим нонсом |
Потрібно оновлювати через кожні 200,000 записів |
Найшвидший |
16, 24 або 32 байти |
| Не рекомендується для використання, крім як у випадку, коли реалізована автоматизована схема оновлення ключів. Вміст ключа доступний з хоста панелі управління. |
| kms v1 (застарілий з Kubernetes v1.28) |
Використовує схему шифрування конвертів із DEK для кожного ресурсу. |
Найміцніший |
Повільний (порівняно з kms версією 2) |
32 байти |
Дані шифруються за допомогою ключів шифрування даних (DEK) з використанням AES-GCM;
DEK шифруються ключами шифрування ключів (KEKs) згідно з
конфігурацією в Службі управління ключами (KMS).
Просте оновлення ключа, з новим DEK, що генерується для кожного шифрування, та
оновлення KEK, контрольоване користувачем.
Прочитайте, як налаштувати постачальника KMS V1.
|
| kms v2 |
Використовує схему шифрування конвертів із DEK для кожного сервера API. |
Найміцніший |
Швидкий |
32 байти |
Дані шифруються за допомогою ключів шифрування даних (DEKs) з використанням AES-GCM; DEKs
шифруються ключами шифрування ключів (KEKs) згідно з конфігурацією
в Службі управління ключами (KMS).
Kubernetes генерує новий DEK для кожного шифрування з секретного насіння.
Насіння змінюється кожного разу, коли змінюється KEK.
Добрий вибір, якщо використовується сторонній інструмент для управління ключами.
Доступний як стабільний з Kubernetes v1.29.
Прочитайте, як налаштувати постачальника KMS V2.
|
| secretbox |
XSalsa20 і Poly1305 |
Найміцніший |
Швидший |
32 байти |
| Використовує відносно нові технології шифрування, які можуть не бути прийнятними в середовищах, які вимагають високого рівня перегляду. Вміст ключа доступний з хоста панелі управління. |
Постачальник `identity` є типовим, якщо ви не вказали інше. **Постачальник `identity` не шифрує збережені дані та не надає _жодного_ додаткового захисту конфіденційності.**
### Зберігання ключів {#key-storage}
#### Локальне зберігання ключів {#local-key-storage}
Шифрування конфіденційних даних за допомогою локально керованих ключів захищає від компрометації etcd, але не забезпечує захисту від компрометації хосту. Оскільки ключі шифрування зберігаються на хості у файлі EncryptionConfiguration YAML, кваліфікований зловмисник може отримати доступ до цього файлу і витягнути ключі шифрування.
#### Зберігання ключів сервісом KMS {#kms-key-storage}
Постачальник KMS використовує _шифрування конвертів_: Kubernetes шифрує ресурси за допомогою ключа даних, а потім шифрує цей ключ даних за допомогою служби керування шифруванням. Kubernetes генерує унікальний ключ даних для кожного ресурсу. API-сервер зберігає зашифровану версію ключа даних в etcd поряд із шифротекстом; при читанні ресурсу API-сервер викликає служби керування шифруванням і надає як шифротекст, так і (зашифрований) ключ даних. У межах служби керування шифруванням, постачальник використовує _ключ шифрування ключа_, щоб розшифрувати ключ даних, розшифровує ключ даних і, нарешті, відновлює звичайний текст. Комунікація між панеллю управління та KMS вимагає захисту під час передачі, такого як TLS.
Використання шифрування конвертів створює залежність від ключа шифрування ключа, який не зберігається в Kubernetes. У випадку KMS зловмиснику, який намагається отримати несанкціонований доступ до значень у відкритому тексті, необхідно скомпрометувати etcd **та** стороннього постачальника KMS.
### Захист для ключів шифрування {#protecting-encryption-keys}
Вам слід прийняти належні заходи для захисту конфіденційної інформації, що дозволяє розшифрування, чи то це локальний ключ шифрування, чи то токен автентифікації, який дозволяє API-серверу викликати KMS.
Навіть коли ви покладаєтесь на постачальника для керування використанням та життєвим циклом основного ключа шифрування (або ключів), ви все одно відповідаєте за те, щоб контроль доступу та інші заходи безпеки для служби керування шифруванням були відповідними для ваших потреб у безпеці.
### Зашифруйте ваші дані {#encrypting-your-data}
### Згенеруйте ключ шифрування {#generate-key-no-kms}
Наступні кроки передбачають, що ви не використовуєте KMS, тому кроки також передбачають, що вам потрібно згенерувати ключ шифрування. Якщо у вас вже є ключ шифрування, перейдіть до [Написання файлу конфігурації шифрування](#write-an-encryption-configuration-file).
Увага:
Зберігання сирого ключа шифрування у конфігурації шифрування забезпечує помірний рівень безпеки, порівняно з відсутністю шифрування.
Для додаткової секретності розгляньте використання постачальника kms, оскільки це ґрунтується на ключах, що зберігаються поза вашим кластером Kubernetes. Реалізації kms можуть працювати з модулями апаратного забезпечення для збереження ключів або з службами шифрування, які керуються вашим постачальником хмарних послуг.
Щоб дізнатися, як налаштувати шифрування в стані спокою з використанням KMS, див. Використання постачальника KMS для шифрування даних. Втулок постачальника KMS, який ви використовуєте, також може постачатися з додатковою конкретною документацією.
Згенеруйте випадковий ключ з 32 байтів і закодуйте його у форматі base64. Ви можете використовувати цю команду:
head -c 32 /dev/urandom | base64
Ви можете використовувати /dev/hwrng замість /dev/urandom, якщо ви хочете використовувати вбудований апаратний генератор ентропії вашого ПК. Не всі пристрої з Linux надають апаратний генератор випадкових чисел.
Згенеруйте випадковий ключ з 32 байтів і закодуйте його у форматі base64. Ви можете використовувати цю команду:
head -c 32 /dev/urandom | base64
Згенеруйте випадковий ключ з 32 байтів і закодуйте його у форматі base64. Ви можете використовувати цю команду:
# Не запускайте це в сесії, де ви встановили насіння генератора випадкових чисел.
[Convert]::ToBase64String((1..32|%{[byte](Get-Random -Max 256)}))
Примітка:
Зберігайте ключ шифрування конфіденційно, включаючи його час генерації та, якщо можливо, після того, як ви більше активно його не використовуєте.
### Реплікація ключа шифрування {#replicate-the-encryption-key}
Використовуючи безпечний механізм передачі файлів, зробіть копію цього ключа шифрування доступною кожному іншому вузлу керування.
Як мінімум використовуйте шифрування під час передачі даних — наприклад, захищену оболонку (SSH). Для більшої безпеки використовуйте асиметричне шифрування між вузлами або змініть підхід, який ви використовуєте, щоб ви покладалися на шифрування KMS.
### Створіть файл конфігурації шифрування {#write-an-encryption-configuration-file}
Увага:
Файл конфігурації шифрування може містити ключі, які можуть розшифрувати вміст в etcd. Якщо файл конфігурації містить будь-який вміст ключа, вам слід належним чином обмежити дозволи на всіх ваших вузлах керування так, щоб лише користувач, який запускає kube-apiserver, міг читати цю конфігурацію.
Створіть новий файл конфігурації шифрування. Зміст повинен бути подібним до:
```yaml
---
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
- secrets
- configmaps
- pandas.awesome.bears.example
providers:
- aescbc:
keys:
- name: key1
# Див. наступний текст для отримання додаткової інформації про секретне значення
secret:
- identity: {} # цей резервний варіант дозволяє читати незашифровані секрети;
# наприклад, під час початкової міграції
```
Щоб створити новий ключ шифрування (який не використовує KMS), див. [Згенеруйте ключ шифрування](#generate-key-no-kms).
### Використовуйте новий файл конфігурації шифрування {#use-the-new-encryption-configuration-file}
Вам потрібно буде приєднати новий файл конфігурації шифрування до статичного Podʼа `kube-apiserver`. Ось приклад того, як це зробити:
1. Збережіть новий файл конфігурації шифрування у `/etc/kubernetes/enc/enc.yaml` на вузлі панелі управління.
1. Відредагуйте маніфест для статичного Podʼа `kube-apiserver`: `/etc/kubernetes/manifests/kube-apiserver.yaml`, щоб він був подібний до:
```yaml
---
#
# Це фрагмент маніфеста для статичного Podʼа.
# Перевірте, чи це правильно для вашого кластера та для вашого API-сервера.
#
apiVersion: v1
kind: Pod
metadata:
annotations:
kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: 10.20.30.40:443
creationTimestamp: null
labels:
app.kubernetes.io/component: kube-apiserver
tier: control-plane
name: kube-apiserver
namespace: kube-system
spec:
containers:
- command:
- kube-apiserver
...
- --encryption-provider-config=/etc/kubernetes/enc/enc.yaml # додайте цей рядок
volumeMounts:
...
- name: enc # додайте цей рядок
mountPath: /etc/kubernetes/enc # додайте цей рядок
readOnly: true # додайте цей рядок
...
volumes:
...
- name: enc # додайте цей рядок
hostPath: # додайте цей рядок
path: /etc/kubernetes/enc # додайте цей рядок
type: DirectoryOrCreate # додайте цей рядок
...
```
1. Перезапустіть свій API-сервер.
Увага:
Ваш файл конфігурації містить ключі, які можуть розшифрувати вміст в etcd, тому вам слід належним чином обмежити дозволи на вузлах керування так, щоб лише користувач, який запускає kube-apiserver, міг читати його.
Тепер у вас є шифрування для **одного** вузла панелі управління. У типовому кластері Kubernetes є кілька вузлів керування, тому зробіть це на інших вузлах.
### Переконфігуруйте інші вузли керування {#api-server-config-update-more}
Якщо у вашому кластері є кілька API-серверів, вам слід розгорнути зміни по черзі на кожному API-сервері.
Увага:
Для конфігурацій кластеру з двома або більше вузлами панелі управління, конфігурація шифрування повинна бути ідентичною на кожному вузлі панелі управління.
Якщо існує різниця в конфігурації постачальника шифрування між вузлами панелі управління, ця різниця може означати, що kube-apiserver не може розшифрувати дані.
Примітка:
Якщо виникає помилка через конфлікт запису, повторіть команду. Це безпечно виконати цю команду більше одного разу.
Для великих кластерів ви можете бажати розділити Secret за просторами імен або сценарію оновлення.
Попередження:
Ця зміна заважає API-серверу отримувати ресурси, які позначені як зашифровані в спокої, але насправді зберігаються у відкритому вигляді.
Коли ви налаштували шифрування у спокої для API (наприклад: вид API Secret, який представляє ресурси secrets в основній групі API), вам необхідно переконатися, що всі ці ресурси у цьому кластері дійсно зашифровані у спокої. Перевірте це, перш ніж продовжувати з наступними кроками.
---
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
- secrets
providers:
- aescbc:
keys:
- name: key1
secret: <BASE 64 ENCODED SECRET>
- identity: {} # ВИДАЛІТЬ ЦЮ СТРОКУ