Gestionarea si rotirea secretelor cu seiful cheii Azure, serviciile gestionate si unele automatizari – partea 2

In postarea anterioara am discutat despre imaginea de ansamblu a existentei si obiectivelor lui Harpocrates. In acest post, voi incepe prin a ma scufunda in constructele definite de Harpocrates si cum pot fi folosite pentru a obtine configuratia dorita pentru mediul dvs.

Dupa cum sa discutat anterior, Harpocrates abordeaza necesitatea unei rotatii periodice a secretelor. Si ca atare, avem nevoie de o primitiva pentru a descrie aceasta „perioada”. Pentru a permite sprijinul altor constructii guvernamentale in viitor, Harpocrates foloseste un concept de „politica”. Aceasta primitiva este menita sa permita administratorului de sistem sa defineasca un set de intervale de rotatie bazate pe timp care pot fi apoi aplicate altor constructe din sistem. In momentul redactarii acestui post, politica este utilizata exclusiv pentru a defini un interval de rotatie, desi ar putea fi extinsa pentru a adauga proprietati de guvernare suplimentare.

Politicile sunt aplicate unor servicii specifice. Aceasta inseamna ca un anumit cont de stocare poate avea o politica de rotatie „de 15 zile”, in timp ce altui cont i se poate aplica o politica de „90 de zile”. Acest lucru permite administratorului sa descrie cat de des trebuie sa se roteasca acreditarile unui anumit serviciu. Acest lucru ne aduce la urmatoarea primitiva: „Serviciu”.

O primitiva „Serviciu” este utilizata pentru a descrie un serviciu specific pe care doriti sa il gestioneze Harpocrates. De exemplu, poate doriti sa activati Harpocrates sa roteasca tastele pentru „Cont de stocare A” si, ca atare, veti crea o definitie „Serviciu” pentru un astfel de serviciu. Definitia „Serviciului” ar oferi, de asemenea, metadate suplimentare despre serviciul dat, cum ar fi tipul serviciului acesta (de exemplu, cont de stocare, cont cosmosdb, cache Redis etc.); si in cele din urma, va fi configurat un „serviciu” cu un „sir de conexiune” care ar descrie modul in care acest serviciu special ar putea fi gestionat de furnizorul de gestionare secreta. In majoritatea cazurilor, acest sir de conexiune ar contine pur si simplu un grup de resurse si uri de serviciu. Cu toate acestea, este posibil sa adaugati jetoane suplimentare la aceasta bucata de metadate, atata timp cat sintaxa utilizata pentru a o defini este inteleasa de managementul secret furnizat respectiv. De exemplu, pentru furnizorul de gestionare secreta a contului de stocare Azure, sirul de conexiune arata astfel: „AccountEndpoint = https: //storageaccounta.core.windows.net; ResourceGroup = myrg;”. Daca ati fi extins furnizorul de administrare secret prin adaugarea propriului furnizor personalizat, sirul de conexiune utilizat pentru a configura un astfel de serviciu ar trebui pur si simplu sa se potriveasca cu sintaxa furnizorului dvs. de clienti stiu cum sa interpreteze. In momentul scrierii acestui articol, informatiile de configurare „Serviciu” nu sunt criptate, prin urmare ar trebui sa evitati stocarea secretelor cu definitiile sale. ResourceGroup = myrg; ”. Daca ati fi extins furnizorul de administrare secret prin adaugarea propriului furnizor personalizat, sirul de conexiune utilizat pentru a configura un astfel de serviciu ar trebui pur si simplu sa se potriveasca cu sintaxa furnizorului dvs. de clienti stiu cum sa interpreteze. In momentul redactarii acestui articol, informatiile de configurare „Serviciu” nu sunt criptate, prin urmare ar trebui sa evitati stocarea secretelor cu definitiile sale. ResourceGroup = myrg; ”. Daca ati fi extins furnizorul de administrare secret prin adaugarea propriului furnizor personalizat, sirul de conexiune utilizat pentru a configura un astfel de serviciu ar trebui pur si simplu sa se potriveasca cu sintaxa furnizorului dvs. de clienti stiu cum sa interpreteze. In momentul redactarii acestui articol, informatiile de configurare „Serviciu” nu sunt criptate, prin urmare ar trebui sa evitati stocarea secretelor cu definitiile sale.

Harpocrates foloseste Azure Key Vault ca magazin securizat pentru secretele de serviciu, precum si mecanismul de evenimente pentru a semnala cand un anumit secret urmeaza sa fie rotit. In Key Vault, secretele sunt identificate printr-un Uri unic. Iata un exemplu de Uri pentru KV Secret numit „secretul meu”: https://mykevault.vault.azure.net/secrets/my-secret/{version id}. Deoarece fiecare secret KV are un uri unice, bine definite, putem folosi acel Uri pentru a corela secretele stocate in KV cu serviciile pe care le-am definit in Harpocrates. Pentru a face acest lucru, avem nevoie de o a treia primitiva: „Secret”. Dupa cum probabil ati ghicit, „Secret” va furniza „informatii de cartografiere”, permitand Harpocrates sa „traduca” un KV uri catre un serviciu pe care incercam sa il gestionam. Pe langa aceasta informatie importanta, un „Secret” contine si informatii despre „tipul” de secret, precum si formatul in care acest secret urmeaza sa fie stocat in KV (mai multe despre acest lucru mai tarziu). In prezent, exista doua tipuri de secrete sustinute de Harpocrates: atasat si dependenta.

Secretele „atasate” reprezinta intrarile in KV care stocheaza valorile brute ale secretului serviciului din aval. De exemplu, atunci cand se creeaza metadate de gestionare pentru „StorageAccountA”, s-ar crea un secret Vault cheie numit „my-storage-account-a-master-key”. Acest secret KV ar fi asociat cu un „Secret” Harpocrates „StorageAccountASecret” care, la randul sau, ar fi asociat cu definitia serviciului „StorageAccountA” si ar fi de tipul „Attached”. Deoarece definitia serviciului „StorageAccountA” este asociata cu o anumita „politica”, acele politici vor fi folosite pentru a seta data de expirare a secretului seifului cheii numit „my-storage-account-a-master-key” si, ca atare, ar face ca acest secret sa expire, declansand un eveniment KV la care Harpocrates poate raspunde rotind cheia contului de stocare si actualizand secretul KV asociat.

Figura 1 Fluxul de proces secret „atasat”

Secretele „Dependenta” reprezinta intrari in Vault cheie care depind de valoarea unui alt secret. Acest tip de secret ar fi de obicei folosit pentru a defini un secret consumat de o aplicatie care are nevoie de acreditari pentru a accesa unul dintre serviciile gestionate de Harpocrates. Majoritatea aplicatiilor nu stocheaza secrete in forma simpla, ci folosesc mai degraba un format specific, cum ar fi un sir de conexiune. Intr-o aplicatie tipica, s-ar vedea probabil o intrare de configurare intr-o forma de sir de conexiune la baza de date, mai degraba decat mai multe intrari reprezentand fiecare: numele serverului, numele de utilizator, parola utilizatorului etc. Ca atare, secretele „Dependenta” sustin un concept de o Expresie de format. Atunci cand configureaza un secret „Dependenta”, un administrator de sistem i-ar oferi lui Harpocrates o expresie care se potriveste cu asteptarile aplicatiei consumatoare si poate arata cam asa: „Server = {{server-secret-id}}; Utilizator = {{user-secret-id}}; Parola = {{password-secret-id}}”. Valorile specificate in „{{“ „}}” sunt coduri generate de sistem ale secretelor gestionate de Harpocrates care pot fi rezolvate in momentul actualizarii dependentei, permitand astfel valoarea secreta reala a KV sa fie: „Server = myDbServer; User = MyDbUserName; Parola = P @ ssword @ 1 ”.

Acum ca avem limbajul pentru a descrie o politica, un serviciu si un secret, avem nevoie de o ultima constructie pentru a simplifica rezolutia secreta a dependentei: Dependenta secreta. Aceasta nu este atat de primitiva, cat doar o relatie care este definita in cadrul sistemului. Cand un secret are dependente si acel secret are cheile de serviciu asociate rotite, sistemul poate programa actualizari pentru toate celelalte secrete care depind de acesta. Deoarece dependentele nu necesita din punct de vedere tehnic sa depinda de secrete „atasate”, s-ar putea proiecta o strategie extinsa de rotatie secreta in cascada care sa fie executata de Harpocrates. Fluxul descris mai sus este descris in diagrama de mai jos:

Figura 2 Fluxul procesului secret „Dependenta”

Acum ca avem vocabularul necesar pentru a descrie comportamentul pe care vrem sa-l automatizeze Harpocrates, putem discuta despre cerintele si presupunerile runtime facute de Harpocrates. Vom face acest lucru in urmatoarea transa a acestei serii de bloguri. Ca intotdeauna, feedback-ul dvs. este binevenit si foarte apreciat.