Jei dirbote „DevOps“ komandose, tipinė darbo eiga atrodo taip: programos kodo perkėlimas per CI pipeline, tada tvarkykite infrastruktūrą atskirai naudodami „GitOps“ įrankius, tokius kaip „kubectl“, „Terraform“ arba „Ansible“. Tai klasikinis „DevOps“: infrastruktūros kūrimas, testavimas, diegimas ir dažnai valdymas rankiniu būdu arba naudojant scenarijus.
Dabar pereikime prie „GitOps“. Su „GitOps“ viskas, įskaitant diegimus, infrastruktūrą ir prieigos taisykles, deklaruojama „Git“. Daugiau jokių... kubectl taikyti arba rankinius „Terraform“ paleidimus. „Git“ tampa sąsaja su gamyba. Atidarote PR, o „GitOps“ įrankis, pvz., „ArgoCD“ arba „FluxCD“, automatiškai sinchronizuoja jūsų norimą būseną su klasteriu.
Pagrindinis „GitOps“ ir „DevOps“ skirtumų pokytis
- DevOps: CI/CD pipelines stūmimas į klasterius
- GitOps: Klasteriai iš „Git“ ištraukia norimą būseną
Tai subtilus, bet esminis skirtumas. CI vis dar kuria ir testuoja, bet naudojant „GitOps“, CD yra pagrįstas „Git“. Jūsų PR tampa gamybos pokyčiu.
Kaip „GitOps“ keičia kūrėjų diegimo, infrastruktūros ir prieigos kontrolę
dislokavimo
Tradiciniame „DevOps“ diegimas reiškė paleidimą pipeline darbai arba komandų, pvz., įvedimas kubectl taikyti -f diegimą.yaml.
„GitOps“ sistemoje srautas pasikeičia. Redaguojate manifestą taip:
Atidarote PR. Atliekami CI patikrinimai („kubeval“, „yamllint“, politikos patikrinimai). Sujunkite juos ir jūsų „GitOps“ įrankis automatiškai sinchronizuos būseną. Diegimą dabar galima atsekti naudojant „Git“ istoriją ir PR peržiūras.
Infrastruktūra (Terraform)
„DevOps“ komandos dažnai vykdo teraformos planas bei taikyti teraformą rankiniu būdu arba su pipeline scenarijus. „GitOps“ sistemoje „Terraform“ kodo pakeitimai atliekami naudojant PR. Patvirtinus, operatorius arba automatizuota užduotis deklaratyviai pritaiko pakeitimus.
Pavyzdys: EC2 egzemplioriaus tipo arba saugos grupės atnaujinimas. Visas gyvavimo ciklas tampa matomas ir valdomas naudojant „Git“.
Prieigos valdymas
„DevOps“ sistemoje prieiga priklauso nuo IAM vaidmenų ir žetonų. Audito žurnalai yra išsklaidyti po CI sistemas ir debesies žurnalus.
„GitOps“ sistemoje prieigos pakeitimai atliekami naudojant versijavus manifestus. Pavyzdžiui:
Sujungti PR suteikia arba panaikina leidimus, o kiekvienas pakeitimas registruojamas „Git“.
„GitOps“ saugumo rizikos: kodėl „Git“ tampa jūsų gamybinės atakos paviršiumi
„GitOps“ centralizuoja valdymą „Git“ sistemoje, tačiau kartu išplečia ir atakų paviršių:
Kenkėjiški arba atsitiktiniai PR
PR galėtų grįžti prie pažeidžiamo vaizdo (paveikslėlis: naujausias) arba netyčia atskleisti paslaugą (tipas: apkrovos balansavimo įrenginys be IP apribojimų).
RBAC eskalavimas
Nesaugus YAML gali suteikti pernelyg daug privilegijų, pavyzdžiui, susieti pipeline paslaugos paskyrą klasterio administratorius.
Dreifavimo ir sinchronizavimo gedimai
Išoriniai pokyčiai (pvz. kubectl pataisa) arba operatoriaus klaidos gali sukelti konfigūracijos dreifą. Be sinchronizavimo įspėjimų problemos gali likti nepastebėtos.
Šios problemos iliustruoja esminį „GitOps“ ir „DevOps“ saugumo iššūkį: kai „Git“ saugykla tampa sąsaja su gamyba, saugumas turi būti užtikrinamas kiekviename etape. commitPrieigos kontrolės klaidos arba nesaugūs privatūs prisijungimai gali akimirksniu paveikti veikiančią infrastruktūrą.
Realaus pasaulio incidentas: netinkamai sukonfigūruotas RBAC „GitOps“ sistemoje
- Kas atsitiko: Jaunesnysis kūrėjas sujungė „Helm“ versijos papildinį per PR. Jis netyčia įtraukė „ClusterRoleBinding“ su padidintomis teisėmis. „ArgoCD“ jį sinchronizavo.
- Kokią riziką tai sukėlė: „Grafana“ tapo viešai prieinama; kūrėjų komandai buvo suteikta visa prieiga prie klasterio.
- Kaip tai buvo išspręsta: Aptikta saugumo skenavimo metu reaguojant į incidentą. Komanda pridėjo atliktą „Helm“ patvirtinimą ir griežtesnį PR patvirtinimą infrastruktūrai.
Kadangi „Git“ dabar yra gamybinė sąsaja, guardrails yra kritiški.
„GitOps“ saugumo kontrolinis sąrašas kūrėjams
| Saugumo praktika | Ką daryti | Kodėl tai svarbu |
|---|---|---|
| Filialų apsaugos | Vykdyti PR peržiūras ir statuso patikrinimus pagrindinėse | Užkirsti kelią neteisėtiems arba nepatvirtintiems gamybinės aplinkos pakeitimams |
| pasirašytas Commits | Reikalingas GPG pasirašytas commitir patvirtintos tapatybės | Užtikrinti atsekamumą ir atskaitomybę |
| Manifesto patvirtinimas | Pridėkite YAML, RBAC ir Helm patvirtinimą prie CI pipelines | Blokuokite nesaugias konfigūracijas ir išvenkite dreifo |
| Apimties patvirtinimai | Naudokite CODEOWNERS, kad apribotumėte, kas tvirtina infrastruktūros ir RBAC pakeitimus. | Apribokite pernelyg plačios prieigos riziką |
| Dreifo aptikimas | Įjungti „ArgoCD“ / „FluxCD“ sinchronizavimą ir įspėjimus apie būsenų neatitikimą | Rankinių pakeitimų arba operatoriaus klaidų nustatymas |
| Audito registravimas | Integruoti „GitOps“ įrankius su žurnalų rinkiniais (pvz., „Loki“ + „Grafana“) | Gaukite matomumą apie sinchronizavimo įvykius ir PR-to-produkcinę istoriją |
Ar komandos turėtų pakeisti „DevOps“ į „GitOps“?
Ne„GitOps“ nėra „DevOps“ pakaitalas, o tik papildymas.
- DevOps = kūrimas/testavimas pipelines, artefaktų generavimas, saugumo nuskaitymai.
- GitOps = valdymas kas bus dislokuotas, kurir kaip infrastruktūra yra palaikoma tinkamos būklės.
Geriausia praktika? Naudoti CI (DevOps) pipelines) kurti artefaktus ir vykdyti testus. Naudokite „GitOps“ įrankius CD ir infrastruktūros valdymui. Taip gausite nuoseklų diegimą, švarų auditą ir į kūrėjus orientuotus darbo eigą.
„GitOps“ įrankiai, kuriuos reikia žinoti
| Įrankis | geriausias | Apsaugos užrašai |
|---|---|---|
| ArgoCD | Vizualiniai darbo eigos | Įgalinti RBAC, SSO ir HTTPS |
| FluxCD | „Git“ pagrindu sukurta automatizacija | Apribokite prieigą prie „Git“, apribokite paslaptis |
| Pynimas GitOps | Kelių klasterių valdymas | Užtikrinti nuomos ribų laikymąsi |
| Šalmas | Sudėtingos / trečiųjų šalių programos | Patvirtinkite reikšmes (values.yaml), venkite paslapčių |
| Pritaikyti | Švarūs perdangos | Išvenkite poslinkio užtikrindami pagrindo / perdangos aiškumą |
Tinkamo įrankio pasirinkimas priklauso nuo jūsų darbo eigos poreikių. Naudoti ArgoCD matomumui ir vaidmenimis pagrįstai prieigos kontrolei. Pasirinkite FluxCD jei pageidaujate skriptų kūrimo ir „Git“ pagrindu sukurtos automatizacijos. Naudokite Šalmas trečiųjų šalių programoms, tokioms kaip „Prometheus“ (su griežtu patvirtinimu), ir pasirinkite Pritaikyti kai jums reikia švarių, minimalių vidinių paslaugų perdengimų.
„DevOps“ ir „GitOps“ kartu padeda komandoms teikti duomenis greičiau, saugiau ir užtikrinčiau. Svarbiausia ne rinktis vieną, o kitą, o žinoti, kur kiekvienas iš jų geriausiai tinka.
„Git“ saugumo DUK
Perskaitykite mūsų „Git“ saugumo DUK ir sužinokite, ką turėtų žinoti kiekvienas kūrėjas!
Realaus pasaulio pavyzdys: netinkamai sukonfigūruota „GitOps“ saugykla, valdanti gamybą
Šis scenarijus parodo, kaip greitai situacija gali pablogėti naudojant „GitOps“ ir „DevOps“ modelius. Komanda, naudodama su „webhook“ integruotą saugyklą, trūko tinkamos guardrailsPrižiūrėtojai turėjo rašymo prieigą ir nebuvo įdiegta jokia šakos apsauga. Paslauga buvo netyčia perjungta į tipas: apkrovos balansavimo įrenginys, atskleidžiant jį visuomenei. A Klasterio vaidmens susiejimas tame pačiame saugykloje suteikė pernelyg daug leidimų.
Kadangi „GitOps“ įrankiai, tokie kaip „ArgoCD“, pritaiko pakeitimus iš karto po jų sujungimo, neteisingos konfigūracijos perkeliamos automatiškai. Saugykla iš esmės tapo gamybine API.
Siekdama atkurti padėtį, komanda užblokavo infrastruktūros failų sujungimo teises, įdiegė RBAC politikų patikrinimą prieš sujungimą ir sukonfigūravo įspėjimus apie bet kokią sinchronizacijos būseną naudodama savo „GitOps“ įrankius. Šis pavyzdys rodo, kad „GitOps“ ir „DevOps“ palyginus, pristatymo greitis gali tapti trūkumu be patikimų kontrolės priemonių.
Pataisymai
- Užrakinti leidimustik vyresnieji „DevSecOps“ specialistai gali sujungti infrastruktūros PR
- Pridėti validatoriusCI blokuoja manifestinius PR su neleistinomis RBAC taisyklėmis
- Monitoriaus sinchronizavimas: įspėjimas, kai „ArgoCD“ įkelia pakeitimus
- Pasukti vaizdo žymas: priverstinis vaizdo pasirašymas arba naudojimas SBOM skeneriai
Kaip „Xygeni“ sustiprina „GitOps“ saugumą netrikdydama kūrėjų darbo eigų
Ksigeni sprendžia dažną „GitOps“ akląją zoną: rizikingus pakeitimus, kurie praslysta pro kodo peržiūras arba nepastebimai pasislenka po įdiegimo. Prieš sujungimą „Xygeni“ nuskaito pull requests dėl saugumo problemų, tokių kaip Klasterio vaidmens susiejimas į klasterio administratorius, paslaugos, teikiamos per „LoadBalancer“ be IP apribojimų, YAML užkoduotos paslaptys, .env, arba „Terraform“ failai, naudojimas paveikslėlis: naujausias, arba nepatikrintus konteinerio atvaizdus. Jis taip pat aptinka atvirus prievadus infrastruktūros apibrėžimuose, pvz., saugos grupes, kurios viešajam internetui atveria SSH.
Jei pull request pažeidžia saugumo politiką, „Xygeni“ gali tai automatiškai blokuoti arba pažymėti. Pavyzdžiui, ji gali užtikrinti, kad tik „ClusterIP“ paslaugos leidžiamos gamyboje, atmetami PR, suteikiantys pernelyg daug leidimų, arba reikalaujama, kad visuose konteinerio atvaizduose būtų Programinės įrangos medžiagų sąrašas (SBOM)Paslaptys, netinkamai sukonfigūruotos prieigos taisyklės ir nerezekami vaizdai taip pat sugaunami prieš jiems pasiekiant gamybos aplinką.
Sujungus kodą, „Xygeni“ toliau stebi „Git“ ir „GitOps“ veiklą. Ji aptinka tiesioginius apsaugotų šakų redagavimus, neleistinus leidimų pakeitimus „Git“ saugyklose ir netikėtus sinchronizavimus, kuriuos sukėlė „ArgoCD“ arba „FluxCD“, ypač tuos, kurie vyksta ne įprastomis darbo valandomis arba liečiasi su kritinėmis manifestais.
Rezultatas – didesnė kontrolė ir mažiau netikėtumų. „Xygeni“ suteikia matomumą, kas įdiegta, kas tai patvirtino ir kaip tai atitinka jūsų saugumo reikalavimus. standardir visa tai netrikdant kūrėjo darbo eigos. Išbandykite!
Išvada: „GitOps“ nepakeičia „DevOps“, bet keičia tai, ką kūrėjai privalo apsaugoti.
„GitOps“ nėra „DevOps“ pakaitalas, o evoliucija. „GitOps“ ir „DevOps“ modelyje CI išlieka orientuota į kūrimą ir testavimą, o „GitOps“ įrankiai, tokie kaip „ArgoCD“, „FluxCD“ arba „Weave GitOps“, valdo teikimą ir infrastruktūros būseną.
Šis perėjimas paverčia pačią „Git“ saugyklą jūsų vykdymo aplinkos dalimi. Jei ji nesaugi, nesaugi ir jūsų gamybinė aplinka. „GitOps“ ir „DevOps“ skirtumų supratimas yra būtinas norint saugiai kurti architektūrą. pipelineo tinkamų „GitOps“ įrankių naudojimas užtikrina, kad matomumas, vykdymo užtikrinimas ir auditas būtų integruoti nuo pat pradžių.
Kai „Git“ valdo gamybą, code security tampa operaciniu saugumu. Jei esate saugyklos savininkas, jūs turite ir klasterį. Apsaugokite abu, naudodami įrankius ir praktikas, kurios „Git“ traktuoja kaip jūsų naują vykdymo aplinkos sąsają.
