У Kubernetes Secret — це обʼєкт, який зберігає конфіденційну інформацію, таку як паролі, токени OAuth та ключі SSH.
Секрети дають вам більше контролю над тим, як використовується конфіденційна інформація і зменшують ризик випадкового її розголошення. Значення Secret кодуються як рядки base64 і зазвичай зберігаються в незашифрованому вигляді, але можуть бути налаштовані для шифрування в стані покою.
Pod може посилатися на Secret різними способами, такими як монтування тому, чи як змінна середовища. Secretʼи призначені для конфіденційних даних, а ConfigMaps призначені для неконфіденційних даних.
Наведені нижче рекомендації призначені як для адміністраторів кластера, так і для розробників застосунків. Використовуйте їх, щоб підвищити безпеку конфіденційної інформації в обʼєктах Secret і ефективніше керувати своїми Secrets.
У цьому розділі наведено рекомендації, які адміністратори кластера можуть використовувати для покращення безпеки конфіденційної інформації в кластері.
Стандартно обʼєкти Secret зберігаються в etcd у незашифрованому вигляді. Вам слід налаштувати шифрування даних Secret в etcd. Інструкції дивіться в розділі Шифрування даних Secret у стані спокою.
Плануючи механізм контролю доступу, такий як контроль доступу на основі ролей Kubernetes (RBAC), врахуйте наведені нижче рекомендації щодо доступу до обʼєктів Secret. Також дотримуйтеся інших настанов із рекомендацій щодо RBAC.
watch або list лише для найпривілейованіших системних компонентів. Надавайте доступ get до Secrets, лише якщо цього потребує звичайна робота компонента.get, watch або list до Secrets. Дозволяйте доступ до etcd лише адміністраторам кластера. Це стосується й доступу лише для читання. Для складнішого контролю доступу, наприклад обмеження доступу до Secrets із певними анотаціями, розгляньте сторонні механізми авторизації.list до Secrets неявно дозволяє субʼєкту отримувати вміст Secrets.Користувач, який може створити Pod, що використовує Secret, також може побачити значення цього Secret. Навіть якщо політики кластера не дозволяють користувачу читати Secret безпосередньо, той самий користувач може мати доступ до запуску Podʼа, який потім розкриє Secret. Ви можете виявляти або обмежувати вплив навмисного чи ненавмисного розкриття даних Secret користувачем із таким доступом. Ось деякі рекомендації:
Використовуйте окремі простори імен, щоб ізолювати доступ до змонтованих Secrets.
Розгляньте очищення або знищення постійного сховища, яке використовував etcd, коли воно більше не потрібне.
Якщо є кілька екземплярів etcd, налаштуйте зашифрований звʼязок SSL/TLS між ними, щоб захистити дані Secret під час передавання.
Ви можете використовувати сторонні сховища Secrets, щоб зберігати конфіденційні дані поза кластером, а потім налаштувати Podʼи на доступ до цієї інформації. Kubernetes Secrets Store CSI Driver — це DaemonSet, який дозволяє kubelet отримувати Secrets із зовнішніх сховищ і монтувати їх як томи в певні Podʼи, яким ви надали доступ до цих даних.
Перелік підтримуваних постачальників дивіться в розділі Providers for the Secret Store CSI Driver.
Рекомендації щодо налаштування своп-памʼяті для вузлів Linux дивіться в розділі Керування своп-памʼяттю.
У цьому розділі наведено рекомендації для розробників щодо покращення безпеки конфіденційних даних під час створення та розгортання ресурсів Kubernetes.
Якщо ви визначаєте кілька контейнерів у Podʼі, і лише одному з них потрібен доступ до Secret, налаштуйте монтування тому або змінні середовища так, щоб інші контейнери не мали доступу до цього Secret.
Застосунки все ще мають захищати значення конфіденційної інформації після її зчитування зі змінної середовища або тому. Наприклад, ваш застосунок не повинен записувати конфіденційні дані в логи у відкритому вигляді або передавати їх ненадійній стороні.
Якщо ви налаштовуєте Secret через маніфест, у якому конфіденційні дані закодовані в base64, то поширення цього файлу або його додавання до репозиторію коду означає, що Secret доступний усім, хто може читати маніфест.
Елементи на цій сторінці відносяться до сторонніх продуктів чи проєктів, які надають функціонал, необхідний для Kubernetes. Автори проєкту Kubernetes не несуть відповідальності за ці проєкти. Ознайомтесь з настановами на вебсайті CNCF для отримання докладної інформації.
Ознайомтесь з посібником з контенту перед тим, як пропонувати додавання посилання на стороні компоненти.