Programavimas

OPA: bendrosios paskirties „cloud-native“ politikos variklis

Kai jūsų organizacija aprėpia debesį, galite pastebėti, kad „cloud-native“ kamino dinamiškumui ir mastui reikia kur kas sudėtingesnio saugumo ir atitikties. Pavyzdžiui, kai konteinerių orkestravimo platformos, pvz., „Kubernetes“, traukia trauką, kūrėjai ir „devops“ komandos turi naują atsakomybę už politikos sritis, tokias kaip priėmimo kontrolė, ir labiau tradicines sritis, pvz., Skaičiavimą, saugojimą ir tinklų kūrimą. Tuo tarpu kiekvienai programai, mikroservisui ar paslaugų tinklui reikia savo autorizacijos politikos rinkinio, kurį kūrėjai palaiko.

Dėl šių priežasčių ieškoma paprastesnio, efektyvesnio laiko kurti, vykdyti ir valdyti politiką debesyse. Įveskite „Open Policy Agent“ (OPA). Prieš ketverius metus sukurta kaip atviro kodo, domenų-agnostikos politikos variklis, OPA tampa de facto standartiniu „cloud-native“ politikos standartu. Tiesą sakant, OPA jau naudoja gamyboje tokios kompanijos kaip „Netflix“, „Pinterest“ ir „Goldman Sachs“, tokiems naudojimo atvejams kaip „Kubernetes“ priėmimo kontrolė ir mikroservikų API autorizacija. OPA taip pat valdo daugelį debesų įrankių, kuriuos jau žinote ir mėgstate, įskaitant „Atlassian“ rinkinį ir „Chef Automate“.

[Taip pat: Kur svetainės patikimumo inžinerija susitinka su devopais]

„OPA“ suteikia „cloud-native“ organizacijoms vieningą politikos kalbą, kad sprendimus dėl leidimų būtų galima išreikšti bendru būdu, visose programose, API, infrastruktūroje ir dar daugiau, nereikalaujant griežtai koduoti užsakytos politikos kiekvienoje iš tų įvairių kalbų ir įrankių atskirai. . Be to, kadangi OPA yra skirta autorizacijai, ji siūlo vis didesnę našumo optimizavimo rinkinį, kad politikos autoriai didžiąją laiko dalį galėtų skirti teisingos, prižiūrimos politikos rašymui ir palikti našumą OPA.

OPA prieigos teisių politikoje yra daug daug naudojimo atvejų - pradedant apsauginių juostų išdėstymu aplink konteinerių orkestravimą, baigiant SSH prieigos valdymu ar kontekstiniu pagrindu teikiamų paslaugų tinklo autorizacijos suteikimu. Tačiau yra trys populiarūs naudojimo atvejai, kurie daugeliui OPA vartotojų suteikia gerą paleidimo pultą: programos autorizacija, „Kubernetes“ priėmimo kontrolė ir mikropaslaugos.

OPA dėl paraiškos autorizacijos

Leidimų politika yra visur, nes praktiškai kiekvienai programai to reikia. Tačiau kūrėjai paprastai „sukasi savo“ kodą, o tai ne tik užima daug laiko, bet ir sukuria sudėtingą įrankių ir politikos, kurią sunku prižiūrėti, antklodę. Nors kiekvienos programos autorizavimas yra labai svarbus, laikas, praleistas kuriant politiką, reiškia mažiau laiko sutelkiant dėmesį į vartotojui skirtas funkcijas.

OPA naudoja tikslui skirtą deklaratyvią politikos kalbą, kuri leidžia autorizavimo politikos kūrimą paprastą. Pvz., Galite sukurti ir vykdyti politiką taip paprasta, kaip „Negalite perskaityti AII, jei esate rangovas“, arba „Jane gali pasiekti šią paskyrą“. Bet tai tik pradžia. Kadangi OPA žino kontekstą, taip pat galite kurti politiką, kurioje atsižvelgiama į bet ką planetoje, pavyzdžiui, „Paskutinę prekybos dienos valandą reikalingi akcijų sandoriai, dėl kurių sudarys daugiau nei milijono dolerių sandorį, gali būti įvykdyti tik konkrečias paslaugas nurodytoje vardų srityje “.

Žinoma, daugelis organizacijų jau turi užsakymą. Tačiau, jei jūs tikitės suskaidyti savo programas ir išplėsti mikroservisų debesyje išlaikydami efektyvumą kūrėjams, reikės paskirstytos autorizacijos sistemos. Daugeliui trūksta OPA dėlionės.

OPA „Kubernetes“ priėmimo kontrolei

Daugelis vartotojų taip pat naudoja OPA, kad sukurtų „Kubernetes“ apsaugas. Pati „Kubernetes“ tapo pagrindine ir kritiškai svarbia misija, o organizacijos ieško būdų, kaip apibrėžti ir įgyvendinti apsaugos apsaugas, kad būtų galima sumažinti saugumo ir atitikties riziką. Naudodamiesi OPA, administratoriai gali nustatyti aiškią politiką, kad kūrėjai galėtų paspartinti vamzdynų gamybą ir greitai pateikti naujas paslaugas į rinką, nesijaudindami dėl veiklos, saugumo ar atitikties rizikos.

OPA gali būti naudojama kuriant strategijas, atmetančias bet kokius įsibrovimus, naudojančius tą patį pagrindinio kompiuterio pavadinimą, arba reikalaujančius, kad visi konteinerio vaizdai būtų iš patikimo registro, arba užtikrinti, kad visa saugykla visada būtų pažymėta šifruotu bitu arba kad kiekviena programa būtų atidengta internete naudoti patvirtintą domeno vardą - pateikti tik keletą pavyzdžių.

Kadangi OPA tiesiogiai integruojasi su „Kubernetes“ API serveriu, jis gali atmesti bet kokį išteklių, kurio neleidžia politika, skaičiavime, tinkle, saugykloje ir pan. Ypač naudingas kūrėjams, jūs galite atskleisti šias strategijas anksčiau kūrimo ciklo metu, pvz., CI / CD, kad kūrėjai galėtų gauti grįžtamąjį ryšį ir išspręsti problemas prieš vykdymą. Be to, jūs netgi galite patvirtinti savo politiką ne juostoje, užtikrindami, kad ji pasiektų numatytą poveikį ir netyčia nekeltų problemų.

Mikropaslaugų OPA

Galiausiai OPA tapo labai populiari padėdama organizacijoms valdyti savo mikropaslaugas ir paslaugų tinklo architektūrą. Naudodamiesi OPA, galite tiesiogiai sukurti ir vykdyti prieigos prie mikropaslaugos (paprastai kaip šoninė priekaba) autorizacijos strategijas, kurti paslaugų tarnybų strategijas paslaugų tinkle arba, saugumo požiūriu, sukurti strategijas, kurios riboja šoninį judėjimą paslaugų tinkle. architektūra.

Kurti vieningą debesų architektūrų politiką

Apskritai, naudojant OPA, bendras tikslas yra sukurti vieningą požiūrį į „Cloud-native stack“ politikos kūrimą - taigi jums nereikės nuolat valdyti politikos daugybėje vietų, naudojant skirtingas kalbas ir metodus, naudojant skelbimą. hoc genčių žinių, wikių ir PDF rinkinių derinys arba netinkamų įrankių kratinys.

[Taip pat: 7 geriausios nuotolinio judrių komandų praktikos]

Be paprastų kūrimų ir spartesnio pristatymo, tai yra didelė naujiena ir saugumui, nes OPA sumažina įrankių, kurių reikia patikrinti, pavyzdį, jei įtariate, kad buvo bandoma neteisėtai pasiekti. Panašiai, tiek operacijų, tiek atitikties požiūriu, OPA palengvina informacijos rinkimą ir analizavimą heterogeniškoje aplinkoje - padeda greitai nustatyti problemas ir jas greičiau išspręsti.

Kūrėjai ieško paprastesnio, efektyvesnio būdo, susijusio su strategijomis pagrįstų valdiklių, skirtų savo debesims skirtoms aplinkoms, sukūrimui ir valdymui. Daugeliui toks sprendimas yra OPA. Jei pastebite, kad prisiliečiate prie autorizacijos politikos keliose vietose, keliomis kalbomis ar keliose komandose, OPA gali padėti pašalinti perteklių ir greitą pristatymą jums, kaip ir jiems.

Timas Hinrichsas yra „Open Policy Agent“ projekto ir „Styra“ CTO įkūrėjas. Prieš tai jis įkūrė „OpenStack Congress“ projektą ir buvo „VMware“ programinės įrangos inžinierius. Timas praleido pastaruosius 18 metų kurdamas deklaratyvias kalbas įvairioms sritims, tokioms kaip debesų kompiuterija, programinės įrangos apibrėžtas tinklas, konfigūracijos valdymas, žiniatinklio saugumas ir prieigos kontrolė. Jis gavo daktaro laipsnį. Stanfordo universiteto informatikos srityje 2008 m.

Naujųjų technologijų forumas suteikia galimybę tyrinėti ir aptarti besiformuojančios įmonės technologijas beprecedentiame gylyje. Atranka yra subjektyvi, atsižvelgiant į mūsų pasirinktas technologijas, kurios, mūsų manymu, yra svarbios ir labiausiai domina skaitytojus. nepriima rinkodaros užtikrinimo priemonės paskelbimui ir pasilieka teisę redaguoti visą pateiktą turinį. Visus klausimus siųskite adresu [email protected].

$config[zx-auto] not found$config[zx-overlay] not found