Kubernetes Secret base64-той ч нууц биш: etcd шифрлэлтийг тусад нь асаа

Secret-ийн base64 кодчилол нь шифрлэлт биш. Kubernetes-ийн Secret ашиглах зөвлөмж-д Secret анхдагчаар etcd-д шифрлэгдээгүй хадгалагддаг гэж тайлбарласан. Тиймээс кластерийн админ kube-apiserver-ийн хадгалах үеийн шифрлэлтийг тусад нь идэвхжүүлэх шаардлагатай.

Эхлээд API server-ийн ажиллаж буй тохиргоог шалгаж, Secret-д шифрлэгч provider-ийг эхэнд байрлуул. Дараа нь шинэ бичлэг etcd-д шифрлэгдэж буйг нягталж, өмнө хадгалсан Secret-үүдийг дахин бичүүл. Түлхүүрийг үе шаттай сольж, API-аар Secret унших RBAC эрхийг хязгаарласнаар тохиргоо өдөр тутмын ажиллагаанд хэрэгжинэ.

Ажиллаж буй API server шифрлэж байгаа эсэхийг тогтоо

Control plane дахь kube-apiserver-ийн бодит аргументаас --encryption-provider-config байгаа эсэхийг шалга. Static Pod ашигладаг кластерт manifest дахь аргумент, түүнд заасан файлын зам болон mount-ыг харж болно; өөр аргаар удирддаг орчинд API server-ийн ажиллаж буй тохиргоог шалгана. Энэ аргумент байхгүй бол Kubernetes API нөөцийн хадгалах үеийн шифрлэлт идэвхгүй.

Аргумент байгаа нь дангаараа Secret шифрлэгдэж байгааг батлахгүй. EncryptionConfiguration файлын resources хэсэгт secrets орсон эсэх, тухайн нөөцийн providers жагсаалтын эхэнд юу байгааг шалга. Эхний provider нь identity бол шинэ бичилт ил хэлбэрээр хадгалагдана; шифрлэгч provider эхэнд байвал шинэ бичилт шифрлэгдэнэ. Аль ч тохиолдолд энэ шалгалт өмнө хадгалсан Secret-үүдийн төлөвийг тогтоохгүй.

EncryptionConfiguration-д шифрлэгчийг эхэнд байрлуул

Kubernetes-ийн хадгалах үеийн шифрлэлтийн заавар-т Secret-ийг resources жагсаалтад сонгож, бичихэд эхний provider, уншихад тохирох provider-уудыг дарааллаар нь ашигладгийг тайлбарласан. Анхны шилжилтийн үед secretbox зэрэг шифрлэгчийг эхэнд, өмнөх ил бичлэгийг уншихад хэрэгтэй identity-г ард нь тавина. Identity-г санамсаргүй эхэнд үлдээвэл тохиргооны файл байсан ч шинэ Secret ил хэлбэрээр бичигдэнэ.

Локал secretbox түлхүүр ашиглах бол санамсаргүй 32 байт үүсгээд base64 болгон кодлож, keys хэсгийн secret утгад оруулж болно. Linux дээр түлхүүр үүсгэх жишээ команд нь head -c 32 /dev/urandom | base64. Энд base64 нь түлхүүрийг нууцалж байгаа хэрэг биш: EncryptionConfiguration файлыг зөвхөн kube-apiserver ажиллуулдаг хэрэглэгч уншихаар эрхийг нь хязгаарла. Локал түлхүүр control plane хост дээр хадгалагддаг учир тэр хостод халдсан этгээдээс дангаараа хамгаалахгүй; түлхүүрийг тусад нь удирдах шаардлагатай бол KMS v2 болон түүнд тохирох plugin-ийг сонгож болно.

Файлыг kube-apiserver унших замд байрлуулж, --encryption-provider-config аргументаар заа. Олон control plane хосттой бол сервер бүр ижил provider болон түлхүүрийн тохиргоотой байх ёстой. API server-үүдийг ээлжлэн шинэчлэхдээ шилжилтийн аль ч үед сервер бүр хадгалсан бичлэгийг тайлж чадахаар зохион байгуул; өөр түлхүүртэй сервер хүсэлтэд алдаа буцааж болзошгүй.

Шинэ бичлэгийг шалгаад хуучин Secret-үүдийг дахин бич

Тохиргоо хэрэгжсэний дараа нөхцөлт шалгалтын Secret-ийг kubectl create secret generic secret1 -n default --from-literal=mykey=mydata командаар үүсгэж болно. etcd-д хандах эрхтэй админ холболтын шаардлагатай TLS аргументуудаа өгөөд etcdctl get /registry/secrets/default/secret1 командыг ажиллуулж, үр дүнг hexdump -C-ээр харна. Хадгалсан утгад k8s:enc: угтвар, сонгосон provider болон тохиргоонд буй түлхүүрийн нэр харагдах ёстой. Дараа нь kubectl get secret secret1 -n default -o yaml командаар API тухайн Secret-ийг хэвийн буцааж байгааг шалга.

Шинэ Secret-ийн бичлэг шифрлэгдсэн байлаа ч өмнөх объектууд дараагийн бичилт хүртлээ хуучин хэлбэрээр үлдэнэ. Бүх Secret-ийг ижил агуулгатай нь дахин бичих албан ёсны команд нь kubectl get secrets --all-namespaces -o json | kubectl replace -f -. Үүнийг бүх namespace дахь Secret-ийг унших, бичих эрхтэй админ ажиллуулах ёстой. Том кластерт namespace-аар хувааж гүйцэтгэж болно; зэрэгцээ өөрчлөлтөөс зөрчил гарсан бол үйлдлийг дахин оролд.

Дахин бичсэний дараа шинэ болон өмнө байсан Secret-үүдийн etcd дахь төлөвийг шалга. Хэдхэн жишээ шинэ бичлэг шифрлэгдсэнийг харуулах боловч бүх хуучин объект шилжсэнийг батлахгүй. Бүх Secret шифрлэгдсэнд итгэлтэй болсны дараа л identity-г жагсаалтаас хасаж, API server-үүдийг ээлжлэн шинэчил. Ил хэлбэрээр үлдсэн бичлэг байхад identity-г хасвал API server түүнийг уншиж чадахгүй.

Түлхүүрийг өгөгдөлтэй нь хамт үе шаттай соль

Локал түлхүүрийг солихдоо шинэ түлхүүрийг одоогийн provider-ийн keys жагсаалтын хоёрдугаарт бүх control plane хостод нэм. Бүх API server шинэ тохиргоог авсны дараа шинэ түлхүүрийн найдвартай нөөц хуулбар үүсгээд түүнийг жагсаалтын эхэнд шилжүүлж, серверүүдийг дахин шинэчил. Ингэснээр дараагийн бичилт шинэ түлхүүрээр шифрлэгдэх бөгөөд хуучин түлхүүрээр хадгалсан бичлэгийг унших боломж хэвээр байна.

Дараа нь Secret-үүдийг дахин бичүүлж, etcd дахь бичлэгүүд шинэ түлхүүрийн нэртэй болсныг шалга. Бүх бичлэг шилжиж, шинэ түлхүүр найдвартай хадгалагдсаны дараа хуучин түлхүүрийг тохиргооноос хас. Зөвхөн шинэ түлхүүрийг эхэнд тавихад өмнөх өгөгдөл автоматаар дахин шифрлэгдэхгүй; хуучин түлхүүрийг эрт хасвал түүгээр шифрлэсэн объектууд уншигдахгүй.

Secret унших эрхийг RBAC-аар хязгаарла

etcd дахь шифрлэлт API-аар зөвшөөрөгдсөн уншилтыг хаахгүй. Kubernetes-ийн RBAC зөвлөмж-д Secret-д олгосон list болон watch эрх нь get эрхийн адил агуулгыг ил гаргах боломжтойг анхааруулсан. Иймээс list эрхийг зөвхөн Secret-ийн нэр харах эрх гэж үзэж болохгүй.

Role болон ClusterRole дахь secrets нөөцийн get, list, watch үйлдлийг хэрэглэгч, ServiceAccount бүрийн хэрэгцээгээр шалга. Боломжтой үед эрхийг namespace болон шаардлагатай Secret-ээр хязгаарлаж, нийт Secret-ийг жагсаах эсвэл ажиглах эрхийг зөвхөн зайлшгүй хэрэгтэй бүрэлдэхүүнд олго. Pod эсвэл Pod удирдах workload үүсгэх эрхийг бас харгалз: Secret-ийг шууд унших эрхгүй хүн түүнийг ашигладаг Pod ажиллуулж чадвал утгад нь хүрэх боломжтой. etcd-д шууд хандах эрхийг кластерийн админаар хязгаарлах нь API зөвшөөрөл болон хадгалах үеийн шифрлэлтийг хамтад нь хэрэгжүүлэхэд чухал.

Мөн уншаарай:

• Signal эсвэл WhatsApp: ижил шифрлэлт metadata-г ижил хамгаалахгүй
• WhatsApp-ын нууц үгийг тохируул: хуучин зургаан оронтой PIN хүрэлцэхгүй
• Docker Compose эсвэл Kubernetes: нэг сервер дээр илүү их нь дээр биш