Kui olete töötanud DevOps meeskondades, näeb tüüpiline töövoog välja selline: rakenduse koodi edastamine konfiguratsiooniliidese kaudu pipeline, seejärel halda infrastruktuuri eraldi, kasutades GitOpsi tööriistu nagu kubectl, Terraform või Ansible. See on klassikaline DevOps: ehita, testi, juuruta ja sageli halda infrastruktuuri käsitsi või skriptide abil.
Nüüd siseneme GitOpsi. GitOpsis deklareeritakse kõik, sealhulgas juurutused, infrastruktuur ja juurdepääsureeglid, Gitis. Enam mitte midagi. kubectl kohaldada või käsitsi Terraformi käivitamised. Gitist saab liides tootmisega. Avate PR-i ja GitOpsi tööriist, näiteks ArgoCD või FluxCD, sünkroonib teie soovitud oleku automaatselt klastriga.
GitOpsi ja DevOpsi peamine nihe
- DevOps: CI/CD pipelineklastrite poole püüdlemine
- GitOps: Klastrid tõmbavad Gitist soovitud oleku
See on peen, aga mängu muutev erinevus. CI ikka ehitab ja testib, aga GitOpsiga on CD Giti-põhine. Sinu PR-ist saab tootmise muutus.
Kuidas GitOps muudab arendajate kontrolli juurutuste, infrastruktuuri ja juurdepääsu üle
kasutuselevõttu
Traditsioonilises DevOpsis tähendas juurutamine käitamist pipeline töökohti või tippige käske, näiteks kubectl rakenda -f juurutamine.yaml.
GitOpsis voog muutub. Manifesti saate muuta järgmiselt:
apiVersion: apps/v1 kind: Deployment metadata: name: my-app spec: replicas: 4 template: spec: containers: - name: web image: myregistry/my-app:1.2.4 Avate PR-i. Käivitatakse CI-kontrollid (kubeval, yamllint, poliitikakontrollid). Ühendage need ja teie GitOpsi tööriist sünkroonib oleku automaatselt. Juurutamist saab nüüd jälgida Giti ajaloo ja PR-i ülevaadete kaudu.
Taristu (Terraform)
DevOpsi meeskonnad töötavad sageli terraformi plaan ja rakendada terravormi käsitsi või koos pipeline skriptid. GitOpsis tehakse Terraformi koodi muudatusi PR-ide kaudu. Pärast kinnitamist käivitavad need operaatori või automatiseeritud töö muudatuste deklaratiivseks rakendamiseks.
Näide: EC2 eksemplari tüübi või turvagrupi uuendamine. Kogu elutsükkel muutub nähtavaks ja Giti kaudu juhitavaks.
Access Control
DevOpsis tugineb ligipääs IAM-rollidele ja tokenidele. Auditeerimisjäljed on hajutatud CI-süsteemide ja pilvelogide vahel.
GitOpsis tehakse juurdepääsumuudatusi versioonitud manifestide kaudu. Näiteks:
kind: ClusterRoleBinding metadata: name: dev-team-admin subjects: - kind: Group name: dev-team roleRef: kind: ClusterRole name: cluster-admin Ühendatud PR-id annavad või tühistavad õigusi ja iga muudatus logitakse Gitis.
GitOpsi turvariskid: miks Gitist saab teie tootmiskeskkonna rünnakupind
GitOps koondab kontrolli Giti, kuid see laiendab ka rünnakupinda:
Pahatahtlikud või juhuslikud PR-id
PR võib taastada haavatava pildi (pilt: viimane) või teenuse tahtmatut paljastamist (tüüp: koormusejaotur ilma IP-piiranguteta).
RBAC eskalatsioon
Ebaturvaline YAML võib anda liigseid õigusi, näiteks siduda pipeline teenusekonto klastri admin.
Triivi ja sünkroonimise tõrked
Välised muutused (nt. kubectl plaaster) või operaatori vead võivad põhjustada konfiguratsiooni triivi. Ilma sünkroonimisteadeteta võivad probleemid jääda märkamata.
Need probleemid illustreerivad GitOpsi ja DevOpsi võrdluses esinevat kriitilist turvaväljakutset: kui Giti repositooriumist saab tootmiskeskkonna liides, tuleb turvalisust tagada igal sammul. commitJuurdepääsukontrolli vead või ebaturvalised PR-id võivad koheselt kanduda üle töötavale infrastruktuurile.
Reaalse maailma intsident: valesti konfigureeritud RBAC GitOpsis
- Mis juhtus: Noorem arendaja liitis PR-i kaudu Helmi versiooniuuenduse. See lisas tahtmatult laiendatud õigustega ClusterRoleBinding'i. ArgoCD sünkroonis selle.
- Millist riski see kaasa tõi: Grafana muutus avalikult kättesaadavaks; arendusmeeskonnale anti klastrile täielik juurdepääs.
- Kuidas see lahendati: Turvaskannimise käigus tuvastatud intsidendile reageerimise ajal. Meeskond lisas renderdatud Helmi valideerimise ja rangema PR-kinnituse infrastruktuuri jaoks.
Kuna Git on nüüd tootmisliides, guardrails on kriitilised.
GitOpsi turbekontrollnimekiri arendajatele
| Turvapraktika | Mida teha | Miks see on oluline |
|---|---|---|
| Filiaalide kaitse | Jõustage PR-ülevaated ja staatuse kontrollid peamistes | Vältige volitamata või kinnitamata muudatusi tootmiskeskkonnas |
| Allkirjastatud Commits | Nõutav GPG-allkirjastatud commitja kontrollitud identiteedid | Jälgitavuse ja vastutuse tagamine |
| Manifesti valideerimine | Lisage CI-le YAML-i, RBAC-i ja Helmi valideerimine pipelines | Blokeeri ebaturvalised konfiguratsioonid ja väldi triivi |
| Ulatuslikud kinnitused | Kasutage KOODIOMANIKUID, et piirata infrastruktuuri ja RBAC-i muudatuste kinnitajaid | Liiga laia juurdepääsuga kaasneva riski piiramine |
| Triivi tuvastamine | Luba ArgoCD/FluxCD sünkroonimine ja oleku mittevastavuse korral märguanded | Tuvastage käsitsi tehtud muudatused või operaatori vead |
| Auditi logimine | GitOpsi tööriistade integreerimine logimispinudega (nt Loki + Grafana) | Saage ülevaade sünkroonimissündmustest ja PR-i ja tootearenduse ajaloost |
Kas meeskonnad peaksid DevOpsi asendama GitOpsiga?
EiGitOps ei asenda DevOpsi, vaid on selle täiendus.
- DevOps = ehitamine/testimine pipelines, artefaktide genereerimine, turvaskaneeringud.
- GitOps = haldamine mida saab kasutusele võetud, kusja Kuidas infrastruktuuri korras hoitakse.
Parim tava? Kasutage CI-d (DevOps) pipelines) artefaktide loomiseks ja testide käivitamiseks. CD ja infrastruktuuri haldamiseks kasutage GitOpsi tööriistu. Nii saavutate järjepidevad juurutused, puhta auditeerimise ja arendajatele suunatud töövood.
GitOpsi tööriistad, mida teada
| Vahend | Parim | Väärtpaberid |
|---|---|---|
| ArgoCD | Visuaalsed töövood | Jõusta RBAC, SSO ja HTTPS |
| FluxCD | Giti-natiivne automatiseerimine | Piira Giti ligipääsu, piira saladusi |
| Kuduge GitOpsi | Mitme klastri haldus | Üürilepingu piiride jõustamine |
| Rooliratas | Keerulised/kolmandate osapoolte rakendused | Valideeri values.yaml, väldi saladusi |
| Kohanda | Puhas kiht | Vältige triivi aluse/ülekatte selguse abil |
Õige tööriista valimine sõltub teie töövoo vajadustest. Kasutama ArgoCD nähtavuse ja rollipõhise juurdepääsukontrolli tagamiseks. Valige FluxCD kui eelistate skriptimist ja Giti-natiivset automatiseerimist. Kasutage Rooliratas kolmandate osapoolte rakenduste, näiteks Prometheuse (range valideerimisega) jaoks ja valige Kohanda kui vajate sisemiste teenuste jaoks puhtaid ja minimaalseid kihte.
DevOps ja GitOps aitavad meeskondadel koos kiiremini, turvalisemalt ja enesekindlamalt tarnida. Asi pole selles, et üks teise asemel eelistataks, vaid teadmises, kuhu kumbki kõige paremini sobib.
Giti turvalisuse KKK
Loe meie Giti turvalisuse KKK-d ja saa teada, mida iga arendaja peaks teadma!
Reaalse maailma näide: valesti konfigureeritud GitOps Repo, mis kontrollib tootmist
See stsenaarium näitab, kui kiiresti asjad GitOps vs DevOps mudelite puhul eskaleeruda võivad. Meeskonnal, kes kasutas veebikonksuga integreeritud repositooriumi, puudus korralik guardrailsHooldajatel oli kirjutamisõigus ja harukaitse puudus. Teenus pöörati kogemata ümber tüüp: koormusejaotur, paljastades selle avalikkusele. A Klastrirolli sidumine samas repositooriumis anti liigsed õigused.
Kuna GitOpsi tööriistad, näiteks ArgoCD, rakendavad muudatusi kohe pärast ühendamist, levivad valekonfiguratsioonid automaatselt. Repositooriumist sai sisuliselt tootmiskeskkonna API.
Taastamiseks lukustas meeskond infrastruktuurifailide ühendamisõigused, rakendas RBAC-poliitikate ühendamiseelse valideerimise ja konfigureeris oma GitOpsi tööriistade kaudu hoiatused mis tahes sünkroonist väljas olemise kohta. See näide toob esile, et GitOpsi ja DevOpsi võrdluses võib edastuskiirus ilma kindlate kontrollimeetmeteta muutuda takistuseks.
Parandused
- Lukusta õigusedainult kõrgemad DevSecOpsi liikmed saavad infrastruktuuri PR-e ühendada
- Lisa valideerijaidCI blokeerib keelatud RBAC-reeglitega manifesti PR-id
- Monitori sünkroonimised: hoiatus, kui ArgoCD avaldab muudatusi
- Pööra pildisilte: jõustada pildi allkirjastamine või kasutamine SBOM skannerid
Kuidas Xygeni tugevdab GitOpsi turvalisust arendajate töövooge häirimata
Xygeni käsitleb GitOpsi levinud pimeala: riskantseid muudatusi, mis libisevad läbi koodiülevaatuste või triivivad märkamatult pärast juurutamist. Enne ühendamist skannib Xygeni pull requests turvaküsimuste, näiteks Klastrirolli sidumine et klastri administraator, teenused, mis on nähtavad läbi Koormuse tasakaalustaja ilma IP-piiranguteta, YAML-is kõvakodeeritud saladused, .envvõi Terraformi failide kasutamine pilt: viimanevõi kontrollimata konteineri kujutisi. See tuvastab ka infrastruktuuri definitsioonides avatud porte, näiteks turvagruppe, mis avaldavad SSH-d avalikule internetile.
Kui pull request rikub turvapoliitikaid, saab Xygeni selle automaatselt blokeerida või märgistada. Näiteks saab see jõustada, et ainult KlastriIP teenused on lubatud tootmises, lükake tagasi liigseid õigusi andvad PR-id või nõudke, et kõik konteineripildid sisaldaksid Tarkvara materjalide loend (SBOM)Salajased koodid, valesti konfigureeritud juurdepääsureeglid ja jälgimatud pildid tabatakse samuti enne, kui need tootmiskeskkonda jõuavad.
Pärast koodi ühendamist jätkab Xygeni Giti ja GitOpsi tegevuse jälgimist. See tuvastab kaitstud harude otseseid muudatusi, Giti repositooriumide volitamata õiguste muudatusi ja ArgoCD või FluxCD poolt käivitatud ootamatuid sünkroonimisi, eriti neid, mis toimuvad väljaspool tavapärast tööaega või puudutavad kriitilisi manifeste.
Tulemuseks on suurem kontroll ja vähem üllatusi. Xygeni annab nähtavuse sellele, mis on juurutatud, kes selle heaks kiitis ja kuidas see on teie turvalisusega kooskõlas. standards, kõik see arendaja töövoogu häirimata. Proovi järele!
Kokkuvõte: GitOps ei asenda DevOpsi, kuid see muudab seda, mida arendajad peavad kaitsma
GitOps ei ole DevOpsi asendaja, vaid evolutsiooniline tulemus. GitOpsi ja DevOpsi mudelis keskendub CI endiselt ehitamisele ja testimisele, samas kui GitOpsi tööriistad nagu ArgoCD, FluxCD või Weave GitOps haldavad tarnimist ja infrastruktuuri olekut.
See üleminek muudab Giti repositooriumi enda osaks teie käituskeskkonnast. Kui see on ebakindel, on seda ka teie tootmine. GitOpsi ja DevOpsi erinevuste mõistmine on turvalise arhitektuuri loomiseks hädavajalik. pipelineja õigete GitOps-tööriistade kasutamine tagab nähtavuse, jõustamise ja auditeerimise algusest peale.
Kui Git juhib tootmist, code security muutub operatiivseks turvalisuseks. Kui omad hoidlat, omad ka klastri. Turva mõlemat tööriistade ja tavadega, mis käsitlevad Giti sinu uue käituskeskkonna liidesena.
