Kubernetes Secrets nie sú šifrované automaticky: treba prepísať aj staré

Podľa odporúčaní OWASP Kubernetes štandardne ukladá objekty Secret do etcd bez šifrovania v pokoji; po nastavení šifrovacieho poskytovateľa treba už uložené objekty prepísať. Nová konfigurácia totiž šifruje pri zápise a staré záznamy spätne nemení.

V existujúcom klastri preto zálohujte etcd a kľúč, pripravte všetky API servery na čítanie šifrovaných údajov, až potom zapnite šifrovaný zápis a prepíšte Secrets. Výsledok overte v etcd. Poskytovateľa identity, ktorý umožňuje čítať nešifrované záznamy, odstráňte až po kontrole migrácie.

Pred zmenou pripravte zálohu a zistite stav klastra

Skontrolujte argument --encryption-provider-config na API serveroch a poradie poskytovateľov pre zdroj secrets. Ani prítomnosť konfiguračného súboru nedokazuje, že sú šifrované všetky existujúce záznamy. Zistite tiež, koľko API serverov obsluhuje požiadavky a ako sa na každom z nich aktualizuje konfigurácia; v spravovanom klastri môže tieto nastavenia ovládať poskytovateľ služby.

Pred zásahom vytvorte obnoviteľnú zálohu etcd a uložte ju s obmedzeným prístupom a vlastným šifrovaním. Záloha vytvorená pred migráciou obsahuje údaje v ich dovtedajšej podobe a neskorší prepis Secretov ju nezmení. Oddelene bezpečne uchovajte aj šifrovací kľúč: po obnove zálohy so šifrovanými záznamami ho API server potrebuje na ich čítanie.

V klastri s viacerými API servermi zmeňte poradie dvakrát

Postup Kubernetes pre šifrovanie v pokoji vysvetľuje, že prvý poskytovateľ v EncryptionConfiguration zapisuje nové údaje, zatiaľ čo pri čítaní sa skúšajú zodpovedajúci poskytovatelia a kľúče. Pre lokálny kľúč uvádza vytvorenie náhodného 32-bajtového kľúča zakódovaného do base64. Súbor s kľúčom sprístupnite iba procesu kube-apiserver a pri prenose medzi uzlami ho chráňte.

Pre lokálne spravovaný kľúč možno zvoliť secretbox; ak potrebujete kľúče spravovať mimo klastra, Kubernetes podporuje KMS. Dokumentácia síce ukazuje aj konfiguráciu aescbc, v prehľade poskytovateľov ho však hodnotí ako slabý a neodporúča ho. Pri miestnom kľúči zostáva kľúč na hostiteľovi riadiacej roviny, takže ochrana samotného etcd nerieši kompromitáciu tohto hostiteľa.

V klastri s viacerými API servermi najprv pridajte rovnaký nový kľúč a poskytovateľa na každý server za identity. Pri tomto poradí sa ešte zapisuje bez šifrovania, no po postupnom obnovení všetkých serverov už každý pozná nový kľúč. Až v druhej fáze presuňte šifrovacieho poskytovateľa pred identity a opäť aktualizujte servery postupne. Počas tohto prechodu vie aj server s predchádzajúcim poradím čítať záznamy vytvorené šifrovacím poskytovateľom.

Pri API serveroch spustených ako statické Pody pripojte súbor EncryptionConfiguration do každého kontajnera a nastavte --encryption-provider-config na jeho cestu. Po každom reštarte overte pripravenosť servera a čítanie existujúcich Secretov. Ak konfigurácie nebudú zhodné v použitých poskytovateľoch a kľúčoch, niektorý server nemusí dokázať prečítať záznam zapísaný iným.

Po zapnutí zápisu prepíšte existujúce Secrets

Keď už všetky API servery zapisujú šifrovane, vytvorte skúšobný Secret a skontrolujte jeho uloženie v etcd. Overte aj to, že ho API server dokáže prečítať. Táto skúška zachytí chybu v novom zápise skôr, než začnete meniť všetky existujúce objekty.

Správca s oprávnením čítať a meniť Secrets vo všetkých menných priestoroch potom môže spustiť kubectl get secrets --all-namespaces -o json | kubectl replace -f -. Príkaz odošle objekty späť cez API s rovnakými hodnotami; nový zápis ich uloží podľa aktuálneho šifrovacieho nastavenia. Ak pri súbežnej zmene vznikne konflikt, po jeho vyriešení príkaz zopakujte. Vo veľkom klastri možno prepis rozdeliť podľa menných priestorov.

Príkaz číta aj hodnoty Secretov, preto ho spúšťajte v dôveryhodnom správcovskom prostredí a jeho výstup neukladajte do bežných logov. Sledujte chyby pri jednotlivých objektoch, najmä ak ich súčasne menia aplikácie alebo operátory. Úspešné prijatie zmien cez API ešte samo osebe nie je kontrolou podoby všetkých záznamov v etcd.

Overte uloženie v etcd pred odstránením identity

Pomocou etcdctl prečítajte záznam pod cestou /registry/secrets/<menný-priestor>/<názov> s prístupovými údajmi platnými pre váš klaster. V uloženej hodnote hľadajte šifrovací prefix zvoleného poskytovateľa a názov očakávaného kľúča. Napríklad pri aescbc dokumentácia ukazuje prefix k8s:enc:aescbc:v1:; pri inom poskytovateľovi kontrolujte jeho vlastný formát. Čítanie pomocou kubectl preverí dešifrovanie cez API, ale neukáže podobu hodnoty v etcd.

Nový skúšobný objekt preukáže správnosť nových zápisov, nie migráciu starých. Pred odstránením identity preto porovnajte aktuálny zoznam Secretov s ich aktuálnymi záznamami v etcd a skontrolujte každý, ktorý mal byť prepísaný. Ak zostane nešifrovaný záznam a identity odstránite predčasne, API server ho nebude vedieť načítať. Po úspešnej kontrole odstráňte identity z konfigurácie na všetkých API serveroch, postupne ich obnovte a znovu overte čítanie.

Pri rotácii nechajte starý kľúč dostupný na čítanie

Nový kľúč najprv pridajte za súčasný kľúč na všetkých API serveroch a postupne ich obnovte. Keď každý server pozná oba kľúče a nový je bezpečne zálohovaný, presuňte ho na prvé miesto v zozname. Po ďalšom postupnom obnovení sa nové zápisy šifrujú novým kľúčom, zatiaľ čo starý zostáva použiteľný na dešifrovanie doterajších záznamov.

Existujúce Secrets potom znovu prepíšte cez API a v etcd overte, že aktuálne záznamy nesú názov nového kľúča. Až po dokončení a kontrole prepísania odstráňte starý kľúč z konfigurácie všetkých serverov. Jeho skoršie odstránenie by znemožnilo čítanie objektov, ktoré ešte zostali šifrované starým kľúčom.

Čo šifrovanie uložených objektov nepokrýva

Šifrovanie mení podobu vybraných objektov pri uložení do etcd. Neberie oprávnenému používateľovi prístup k Secretu cez API ani nechráni jeho hodnotu po načítaní aplikáciou. Odporúčania Kubernetes pre Secrets preto zahŕňajú obmedzenie oprávnení RBAC, prístupu k etcd a ochranu údajov v aplikáciách.

Base64 v manifeste je iba spôsob kódovania hodnoty, nie šifrovanie. Samostatnú ochranu potrebujú aj zálohy a zväzky pripojené ku kontajnerom; nastavenie šifrovania API objektov ich nepokrýva. Pri kontrole bezpečnosti tak rozlišujte medzi aktuálnym záznamom v etcd, staršími zálohami a miestami, kde aplikácia už pracuje s odhalenou hodnotou.

Prečítajte si aj:

• Prenos prístupových kľúčov v Androide: bez CSV, ale nie medzi každou aplikáciou
• Údaj zmizol z Googlu, nie z webu: ako požiadať o odstránenie
• Cloud šifruje súbory, nie všetky stopy: ako nastaviť Cryptomator