# Поради використання Secretʼів в Kubernetes > Принципи та практики керування Secretʼами для адміністраторів кластера та розробників застосунків. --- LLMS index: [llms.txt](/llms.txt) ---

У Kubernetes, Secret — це обʼєкт, який зберігає конфіденційну інформацію, таку як паролі, токени OAuth та ключі SSH.

Секрети дають вам більше контролю над тим, як використовується конфіденційна інформація і зменшують ризик випадкового її розголошення. Значення Secret кодуються як рядки base64 і зазвичай зберігаються в незашифрованому вигляді, але можуть бути налаштовані для шифрування в стані покою.

Pod може посилатися на Secret різними способами, такими як монтування тому, чи як змінна середовища. Secretʼи призначені для конфіденційних даних, а ConfigMaps призначені для неконфіденційних даних.

Наведені нижче поради призначені як для адміністраторів кластера, так і для розробників застосунків. Використовуйте ці рекомендації, щоб підвищити безпеку вашої конфіденційної інформації у Secret, а також ефективніше керувати вашими Secretʼами. ## Адміністратори кластера {#cluster-administrators} У цьому розділі наведені кращі практики, які адміністратори кластера можуть використовувати для покращення безпеки конфіденційної інформації в кластері. ### Налаштування шифрування даних у спокої {#сonfigure-encryption-at-rest} Стандартно обʼєкти Secret зберігаються у кластері в у незашифрованому вигляді. Вам слід налаштувати шифрування конфіденційної інформації з Secret в `etcd`. Для отримання інструкцій дивіться [Шифрування конфіденційних даних у Secret у спокої](/docs/tasks/administer-cluster/encrypt-data/). ### Налаштування доступу з мінімальними привілеями до Secret {#least-privilege-secrets} Плануючи механізм керування доступом, такий як Kubernetes [(RBAC)](/docs/reference/access-authn-authz/rbac/), слід врахувати наступні рекомендації щодо доступу до обʼєктів `Secret`. Також слід дотримуватися [рекомендацій використання RBAC](/docs/concepts/security/rbac-good-practices). - **Компоненти**: Обмежте доступ до `watch` або `list` тільки для найпривілейованіших системних компонентів. Дозвольте доступ лише для отримання Secret, якщо це необхідно для звичайної роботи компонента. - **Люди**: Обмежте доступ до Secrets на рівні `get`, `watch` або `list`. Дозвольте адміністраторам кластера отримувати доступ до `etcd`. Це включає доступ тільки для читання. Для складнішого керування доступом, такого як обмеження доступу до Secrets з конкретними анотаціями, слід розглянути використання механізмів авторизації сторонніх постачальників.

Увага:

Надання доступу до list Secrets неявно дозволяє субʼєкту отримувати значення Secrets.

Користувач, який може створити Pod, який використовує Secret, також може побачити значення цього Secret. Навіть якщо політика кластера не дозволяє користувачу читати Secret безпосередньо, той же користувач може мати доступ до запуску Pod, який потім розкриває Secret. Ви можете виявити або обмежити вплив викриття даних Secret, як умисно, так і неумисно, користувачем з цим доступом. Деякі рекомендації включають: - Використовуйте Secret з коротким терміном дії - Реалізуйте правила аудиту, які сповіщають про певні події, такі як одночасне читання кількох Secret одним користувачем #### Обмеження доступу для Secrets {#restrict-access-for-secrets} Використовуйте окремі простори імен для ізоляції доступу до змонтованих секретів. ### Покращення політик управління etcd {#improve-etcd-management-policies} Розгляньте очищення або знищення надійного сховища, використаного `etcd`, якщо воно більше не використовується. Якщо є кілька екземплярів `etcd`, налаштуйте зашифровану SSL/TLS комунікацію між екземплярами для захисту конфіденційних даних Secret під час передачі. ### Налаштування доступу до зовнішніх Secrets {#configure-access-to-external-secrets}

Примітка: Цей розділ містить посилання на проєкти сторонніх розробників, які надають функціонал, необхідний для Kubernetes. Автори проєкту Kubernetes не несуть відповідальності за ці проєкти. Проєкти вказано в алфавітному порядку. Щоб додати проєкт до цього списку, ознайомтеся з посібником з контенту перед надсиланням змін. Докладніше.

Ви можете використовувати сторонніх постачальників систем збереження Secret, щоб зберігати вашу конфіденційну інформацію поза кластером, а потім налаштувати Podʼи для доступу до цієї інформації. [Драйвер Kubernetes Secrets Store CSI](https://secrets-store-csi-driver.sigs.k8s.io/) — це DaemonSet, який дозволяє kubelet отримувати Secrets з зовнішніх сховищ та монтувати Secretʼи як томи у певні Podʼи, які ви авторизуєте для доступу до даних. Для списку підтримуваних постачальників дивіться [Постачальники для драйвера сховища Secret Store CSI](https://secrets-store-csi-driver.sigs.k8s.io/concepts.html#provider-for-the-secrets-store-csi-driver). ## Поради щодо використання swap {#good-practices-for-using-swap-memory} Для отримання порад щодо налаштування памʼяті swap для вузлів Linux, будь ласка, зверніться до [управління памʼяттю swap](/docs/concepts/cluster-administration/swap-memory-management/#good-practice-for-using-swap-in-a-kubernetes-cluster). ## Розробники {#developers} У цьому розділі наведено рекомендації для розробників щодо покращення безпеки конфіденційних даних при створенні та розгортанні ресурсів Kubernetes. ### Обмежте доступ до Secret до певних контейнерів {#restrict-secret-access-to-specific-containers} Якщо ви визначаєте декілька контейнерів у Pod, і тільки один з цих контейнерів потребує доступу до Secret, визначте настройки монтування томів або змінних середовища так, щоб інші контейнери не мали доступ до цього Secret. ### Захист даних Secret після їх зчитування {#protect-secret-data-after-reading} Застосунки все ще повинні захищати значення конфіденційної інформації після їх зчитування зі змінної середовища або тому. Наприклад, вашому застосунку слід уникати логування конфіденційних даних у відкритому вигляді або передачі їх ненадійній стороні. ### Уникайте спільного використання маніфестів Secret {#avoid-sharing-secret-manifests} Якщо ви налаштовуєте Secret через , де дані Secret кодуються у base64, то обмінюючись цим файлом або включаючи його до репозиторію, цей Secret буде доступний всім, хто може читати маніфест.

Увага:

Кодування у base64 — це не метод шифрування, воно не надає додаткової конфіденційності порівняно зі звичайним текстом.