Secret — Kubernetes’da parol, token, sertifikat yoki kalit kabi maxfiy qiymatlarni workloadga yetkazish uchun mo‘ljallangan API obyekti. Secret konfiguratsiyani container image’dan ajratadi, lekin default manifestdagi base64 kodlash shifrlash emas. Maxfiylik RBAC, transport himoyasi, storage encryption va operatsion tartiblarning birgalikdagi natijasidir.
Ma’lumot shakli
Secret data maydonida base64 ko‘rinishidagi byte qiymatlarni, stringData maydonida esa yozish vaqtida oddiy matnni qabul qiladi. API stringDatani saqlashdan oldin dataga aylantiradi. Opaque umumiy tur, TLS va registry credential uchun esa ma’lum kalitlarni kutadigan maxsus turlar mavjud.
apiVersion: v1
kind: Secret
metadata:
name: database-auth
type: Opaque
stringData:
username: catalog_app
password: example-only
Bunday manifestni haqiqiy credential bilan Git repositoryga yozish mumkin emas. Misol faqat obyekt tuzilishini ko‘rsatadi.
Workloadga uzatish
Secret environment variable yoki read-only volume fayli sifatida podga beriladi. Environment qiymati process boshlanishida nusxalanadi va process listing, crash dump yoki diagnostik endpoint orqali oshkor bo‘lishi mumkin. Volume yangilanishi mumkin, ammo application faylni qayta yuklashi kerak.
| Usul | Afzallik | Xavf yoki cheklov |
|---|---|---|
| Environment | Ilovalar uchun sodda | Restart va process muhitida ko‘rinish |
| Volume fayli | Permission va rotationga qulay | Ilova fayl o‘zgarishini kuzatishi kerak |
| CSI driver | Tashqi vault bilan integratsiya | Qo‘shimcha provider va availability |
Secret faqat uni reference qilgan pod node’iga yuborilishi kerak. Pod ichidagi barcha containerlar bir xil secretni avtomatik olmaydi; mount va env har container uchun aniq ko‘rsatiladi.
Storage himoyasi
API server bilan aloqa TLS orqali shifrlanadi. Control-plane store’da encryption at rest yoqilmasa Secret byte’lari boshqa API obyektlari kabi saqlanishi mumkin. Encryption provider va key rotation sozlanadi; eski yozuvlar yangi kalit bilan qayta shifrlanishi ham talab qilinadi.
Etcd backupi Secretlarni o‘z ichiga oladi. Backup production ma’lumoti kabi shifrlanadi, access cheklanadi va retention boshqariladi. Faqat cluster obyektini o‘chirish backupdagi nusxani yo‘q qilmaydi.
Access nazorati
RBAC get, list va watch huquqlarini minimal service account’larga beradi. list huquqi namespace’dagi ko‘p secretni chiqarishi mumkin. Pod yaratish huquqi ham bilvosita xavfli: foydalanuvchi ruxsat etilgan secretni podga mount qilib o‘qishi ehtimoli bor.
Audit log Secret obyektiga murojaatni qayd etadi, lekin qiymatni logga yozmasligi kerak. Debug output, templating vositasi va CI loglarida secret masking qo‘llanadi; masking barcha encoding variantlarini avtomatik topishiga kafolat yo‘q.
Rotation
Credential muddati cheklangan bo‘lsa o‘g‘irlangan qiymatning foydali davri qisqaradi. Rotation yangi qiymat yaratish, consumerlarga tarqatish, ular yangisini qabul qilganini tekshirish va eski qiymatni bekor qilish bosqichlaridan iborat. Bir zumda almashtirish barcha podlar yangilanmagan bo‘lsa uzilish keltiradi.
Ikki faol kalitli overlap yoki dinamik qisqa muddatli token uzluksiz rotationga yordam beradi. Sertifikatda private key, certificate chain va trust store yangilanish tartibi bir-biriga mos bo‘lishi kerak.
Tashqi secret boshqaruvi
Cloud secret manager yoki vault markaziy audit, dynamic credential va rotation beradi. Operator tashqi qiymatni Kubernetes Secretga sinxronlashi yoki CSI orqali podga bevosita mount qilishi mumkin. Sinxronlash nusxa sonini ko‘paytiradi; bevosita ulash esa tashqi xizmat availability’siga bog‘laydi.
Secret reference manifestda saqlanadi, haqiqiy qiymat esa tashqi tizimda qoladi. Bootstrap identity masalasi baribir mavjud: workload tashqi vaultga o‘zini xavfsiz tanitishi kerak. Static “vault paroli”ni boshqa Secretda saqlash muammoni faqat ko‘chiradi.
Bog‘liq tushunchalar
Kubernetes, ConfigMap, RBAC, Encryption at rest, Secret manager, Credential rotation, Service account