Kubernetes Secret on oletuksena selväkielinen etcd:ssä – salaa se oikein

Kubernetes Secret -arvojen base64-koodaus ei salaa niitä. Kubernetesin Secret-turvaohjeen mukaan Secret-objektit tallentuvat oletuksena salaamattomina etcd:hen. Tallennuksen salaus otetaan käyttöön API-palvelimen EncryptionConfiguration-asetuksella.

Uusi asetus vaikuttaa seuraaviin kirjoituksiin, joten jo tallennetut Secret-objektit täytyy kirjoittaa uudelleen. Turvallinen järjestys on selvittää nykyinen asetus, turvata palautus, ottaa salaava tarjoaja käyttöön kaikilla API-palvelimilla, päivittää vanhat objektit ja tarkistaa niiden tallennusmuoto. Siirtymävaiheessa identity säilytetään lukemista varten; sen voi poistaa vasta, kun salaamattomia Secret-tietueita ei enää ole.

Selvitä lähtötila ja turvaa palautus

Tarkista jokaisen kube-apiserver-prosessin käynnistysasetuksista, onko --encryption-provider-config käytössä ja mitä resursseja sen osoittama tiedosto koskee. Secret-objektien salaus edellyttää resources-luettelossa merkintää secrets sekä salaavaa tarjoajaa providers-luettelon ensimmäisellä sijalla. Jos ensimmäisenä on identity, API-palvelin kirjoittaa Secretit salaamattomina, vaikka tiedostossa olisi myös salausavaimia.

Ota ennen muutosta palautuskelpoinen etcd-varmuuskopio ja säilytä nykyinen salauskonfiguraatio sekä sen lukemiseen tarvittavat avaimet tai KMS-yhteys. Jos varmuuskopio on otettu ennen salauksen käyttöönottoa, sen sisältämä Secret-data pysyy alkuperäisessä tallennusmuodossaan: myöhempi asetuksen muutos ei salaa vanhaa kopiota. Rajaa siksi myös varmuuskopion käyttöoikeudet ja suunnittele palautus niin, että palautetut objektit ovat API-palvelimen luettavissa.

Valitse paikallinen avain tai KMS-kuorisalaus

Paikallisessa salauksessa avain on API-palvelimen käyttämässä konfiguraatiotiedostossa. Se suojaa etcd:stä saadun datan sisältöä, mutta saman hallintatason koneen avaintiedostoon pääsevä voi purkaa suojan. Rajaa tiedoston lukuoikeus API-palvelimen käyttäjään ja jaa avain turvallisesti kaikille hallintatason koneille. Kubernetesin tarjoajista aescbc on edelleen esimerkeissä, mutta sitä ei suositella CBC-tilaan liittyvän haavoittuvuusriskin vuoksi; aesgcm puolestaan edellyttää suunniteltua automaattista avaimen kiertoa.

KMS-kuorisalauksessa ulkoinen avainpalvelu hallitsee avainta, jolla datan salaamiseen tarvittava avain suojataan. Kubernetesin KMS-ohje kuvaa KMS v2:n kertakäyttöiset data-avaimet: API-palvelin johtaa ne salaisesta siemenestä ja satunnaisesta datasta, ja hallintatason koneella toimiva KMS-lisäosa välittää yhteyden ulkoiseen avainpalveluun Unix-pistokkeen kautta. KMS v2 on vakaa Kubernetes-versiosta v1.29 lähtien; tarkista silti oman klusteriversion ja lisäosan yhteensopivuus. KMS vähentää riippuvuutta paikallisesta pääavaimesta, mutta palautuminen edellyttää myös ulkoisen avaimen ja lisäosan säilymistä käytettävinä.

Määritä salaus kaikille API-palvelimille

Laadi EncryptionConfiguration-tiedosto, jossa apiVersion on apiserver.config.k8s.io/v1, kind on EncryptionConfiguration ja resources sisältää secrets-merkinnän. Aseta valittu salaava tarjoaja providers-luettelon kärkeen. KMS v2 -asetuksessa kms-tarjoajalle määritetään apiVersion: v2, lisäosan name ja unix://-alkuinen endpoint. Jätä identity: {} luettelon viimeiseksi siirtymän ajaksi, jotta API-palvelin pystyy lukemaan vanhat salaamattomat tietueet uudelleenkirjoitusta varten.

Järjestyksellä on kaksi eri tehtävää: ensimmäinen tarjoaja määrää uuden kirjoituksen tallennusmuodon, kun taas luku käyttää tallennetulle muodolle sopivaa tarjoajaa. Jos siirryt aiemmasta paikallisesta salauksesta KMS:ään, säilytä myös vanha tarjoaja uuden jälkeen, kunnes sillä salatut objektit on kirjoitettu uudelleen. Vanhan avaimen poistaminen liian aikaisin voi tehdä sen avulla salatut Secretit lukukelvottomiksi.

Vie yhdenmukainen konfiguraatio jokaiselle hallintatason koneelle, osoita siihen kube-apiserverin --encryption-provider-config-asetuksella ja käynnistä API-palvelimet uudelleen hallitusti. Varmista ennen vanhojen objektien massapäivitystä, että uuden Secretin luonti ja luku onnistuvat. KMS-käytössä tarkista myös lisäosan terveystila sekä sen oikeus käyttää ulkoista avainpalvelua; toimiva API-luku ei yksin osoita, millaisena tietue sijaitsee etcd:ssä.

Kirjoita vanhat Secret-objektit uudelleen

Salaus tehdään kirjoitushetkellä, joten asetuksen vaihtaminen ei muuta etcd:ssä ennestään olevia tietueita. Kubernetesin tallennussalausohje neuvoo lukemaan ja korvaamaan Secret-objektit samalla sisällöllä komennolla kubectl get secrets --all-namespaces -o json | kubectl replace -f -. Komento vaatii oikeuden lukea ja päivittää kaikkien nimiavaruuksien Secretit.

1. Varmista, että kaikki API-palvelimet käyttävät uutta salaavaa tarjoajaa ja että vanhojen tietueiden lukemiseen tarvittavat tarjoajat ovat yhä mukana.
2. Suorita uudelleenkirjoitus. Suuressa klusterissa käsittele Secretit nimiavaruuksittain tai skriptillä, joka kirjaa onnistuneet ja epäonnistuneet päivitykset.
3. Ratkaise samanaikaisista muutoksista johtuvat kirjoitusristiriidat ja aja epäonnistuneet päivitykset uudelleen. Koko komennon voi suorittaa uudestaan.

Sama menettely tarvitaan, kun haluat siirtää vanhat tietueet uuteen salausavaimeen tai paikallisesta tarjoajasta KMS:ään. Pelkkä uuden tarjoajan lisääminen listan kärkeen muuttaa vain sen jälkeen kirjoitettavia tietueita. Pidä aiempi purkutapa mukana siihen asti, kunnes uudelleenkirjoituksen kattavuus on varmistettu.

Todenna tallennus ennen identityn poistamista

Tarkista uudelleenkirjoitetun Secretin tallennusmuoto riittävillä ylläpito-oikeuksilla suoraan etcd:stä esimerkiksi etcdctl-työkalulla. Paikanna oikea tietue klusterisi käyttämästä avainpolusta ja tarkista, että sen arvo alkaa valitun tarjoajan tunnisteella; KMS v2:n tunniste on k8s:enc:kms:v2:. Varmista lisäksi, että sama Secret palautuu Kubernetesin API:n kautta. API-luku osoittaa purkamisen toimivan, kun taas etcd-tietue näyttää tallennetun muodon.

Yhden Secretin tarkistus osoittaa kirjoitustavan, mutta identityn poistaminen edellyttää kattavuuden varmistamista kaikille Secret-objekteille. Varmista, että jokainen suunniteltu päivitys onnistui ja että jäljellä olevissa Secret-tietueissa on odotettu salatun tallennuksen tunniste. Jos identity poistetaan yhdenkin salaamattoman tietueen ollessa jäljellä, API-palvelin ei enää pysty lukemaan sitä.

Poista identity vasta tämän tarkistuksen jälkeen kaikkien API-palvelinten konfiguraatiosta ja käynnistä palvelimet uudelleen hallitusti. Tarkista vielä Secret-objektien luettavuus API:n kautta. Säilytä palautukseen tarvittavat avaimet sekä vanhat varmuuskopiot suojattuina niiden alkuperäisen tallennusmuodon mukaisesti.