Sigurnost Helma

Bitka pri pripovijanju o najpopularnijem paketu menadžeru za Kubernetes mogla bi se prikazati pomoću emojija:

• kutija — to je Helm (najprikladnije je u posljednjoj verziji Emoji);
• ključa — sigurnost;
• čovječuljak — rješenje problema.

U stvarnosti, sve će biti malo složenije, a priča je puna tehničkih detalja o tome kako učiniti Helm sigurnim. Ukazat ćemo na to što je Helm, ako niste znali ili ste zaboravili. Koje probleme rješava i gdje se nalazi u ekosustavu..

• Pogledajmo arhitekturu Helma. Nijedna rasprava o sigurnosti i o tome kako učiniti alat ili rješenje sigurnijim ne može proći bez razumijevanja arhitekture komponenti.
• Raspravimo o komponentama Helma.
• Najvažnije pitanje — budućnost — nova verzija Helma 3.
• Sve u ovom članku odnosi se na Helm 2. Ova verzija je trenutno u produkciji i vjerojatno ju sada koristite, a u njoj su prisutne sigurnosne prijetnje. 

Aleksandar Khajerov (

O govoru: allexx) bavi se razvojem 10 godina, pomaže unaprijediti sadržajMoscow Python Conf++ i pridružio se odboru Helm Summit . Trenutno radi u Chainstacku kao razvojni voditelj — to je hibrid između rukovoditelja razvoja i osobe koja je odgovorna za isporuku konačnih izdanja. To jest, nalazi se na mjestu gdje se odvija sve od stvaranja proizvoda do njegove eksploatacije.Chainstack je mali, aktivno rastući startup, čija je zadaća omogućiti klijentima da zaborave na infrastrukturu i složenosti vezane uz upravljanje decentraliziranim aplikacijama, razvojni tim se nalazi u Singapuru. Ne tražite od Chainstacka da proda ili kupi kriptovalutu, ali ponudite da razgovarate o enterprise blockchain okvirima, i rado će vam odgovoriti.

To je paket menadžer (chartova) za Kubernetes. Najjasniji i najuniverzalniji način za stavljanje aplikacija u Kubernetes klaster.

Helm

Govori se, naravno, o strukturiranijem i industrijskom pristupu u odnosu na stvaranje vlastitih YAML manifestacija i pisanje malih alata.

Helm je najbolje što trenutno postoji od dostupnog i popularnog.

Zašto Helm? Prije svega zato što ga podržava CNCF. Cloud Native je velika organizacija koja je matična kompanija za projekte Kubernetes, etcd, Fluentd i druge.

Zašto Helm? Prvo i najvažnije, jer ga podržava CNCF. Cloud Native je velika organizacija koja je matična kompanija za projekte Kubernetes, etcd, Fluentd i druge.

Još jedna važna činjenica, Helm je vrlo popularan projekt. Kada sam u siječnju 2019. godine odlučio govoriti o tome kako učiniti Helm sigurnim, projekt je imao tisuću zvjezdica na GitHubu. Do svibnja ih je već bilo 12 tisuća.

Mnogi se zanima za Helm, stoga, čak i ako ga još ne koristite, znanje o njegovoj sigurnosti će vam biti korisno. Sigurnost je važna.

Glavni tim Helm podržava Microsoft Azure, i zbog toga je to prilično stabilan projekt u usporedbi s mnogim drugima. Izlazak Helm 3 Alpha 2 sredinom srpnja svjedoči o tome da na projektu radi dosta ljudi koji imaju želju i snagu razvijati i poboljšati Helm.

Helm rješava nekoliko osnovnih problema upravljanja aplikacijama u Kubernetesu.

• Pakiranje aplikacije. Čak i aplikacija tipa „Hello, World” na WordPressu već predstavlja nekoliko servisa, i želimo ih zapakirati zajedno.
• Upravljanje složenošću koja nastaje s upravljanjem tih aplikacija.
• Životni ciklus koji ne završava nakon instalacije ili implementacije aplikacije. Ona nastavlja postojati, potrebno ju je ažurirati, a u tome pomaže Helm, pokušavajući donijeti ispravne mjere i politike.

Pakiranje je uređeno na razumljiv način: postoje metapodaci u punoj sukladnosti s radom običnog upravitelja paketa za Linux, Windows ili MacOS. Dakle, repozitorij, ovisnosti o različitim paketima, metainformacije za aplikacije, postavke, značajke konfiguracije, indeksiranje informacija itd. Sve to Helm omogućava da se dobije i koristi za aplikacije.

Upravljanje složenošću. Ako imate puno identičnih aplikacija, potrebna je parametrizacija. Iz toga proizlaze predlošci, ali da ne biste smišljali vlastiti način izrade predložaka, možete koristiti ono što Helm nudi iz kutije.

Upravljanje životnim ciklusom aplikacije — po mom mišljenju, to je najzanimljivije i neriješeno pitanje. To je razlog zbog kojeg sam se tada okrenuo Helmu. Trebali smo pratiti životni ciklus aplikacije, željeli smo prenijeti naš CI/CD i cikluse aplikacija u ovu paradigmu.

Helm omogućava:

• upravljanje implementacijama, uvodi pojam konfiguracije i revizije;
• uspješno provoditi rollback;
• koristiti hook-ove za različite događaje;
• dodavati dodatne provjere aplikacija i reagirati na njihove rezultate.

Osim toga Helm ima "baterije". — ogroman broj ukusnih stvari koje možete uključiti u obliku dodataka, olakšavajući si život. Dodatke možete pisati sami, oni su prilično izolirani i ne zahtijevaju složenu arhitekturu. Ako želite nešto implementirati, preporučujem da to učinite u obliku dodatka, a kasnije možda uključite u upstream.

Helm se temelji na tri glavne koncepcije:

• Chart Repo — opis i niz parametarizacije koji su mogući za vaš manifest. 
• Postavke — to jest, vrijednosti koje će se primijeniti (tekst, numeričke vrijednosti i sl.).
• Objava objedinjuje dva gornja komponente, a zajedno se pretvaraju u Release. Izdanje se može verzionirati, čime se postiže organizacija životnog ciklusa: malo prilikom instalacije i veliko prilikom nadogradnje, smanjenja ili vraćanja.

Arhitektura Helm

Na shemi konceptualno je prikazana visoka razina arhitekture Helma.

Podsjećam, Helm je nešto što je povezano s Kubernetesom. Stoga ne možemo proći bez Kubernetes klastera (pravokutnik). Komponenta kube-apiserver nalazi se na masteru. Bez Helma imamo Kubeconfig. Helm donosi jednu malu binarnu, ako to tako možemo nazvati, alat Helm CLI, koji se instalira na računalo, laptop, mainframe — na sve što želite.

Ali to nije dovoljno. Helm ima serversku komponentu Tiller. On predstavlja interese Helma unutar klastera, to je ista aplikacija unutar Kubernetes klastera kao i svaka druga.

Sljedeća komponenta Chart Repo — repozitorij s chartovima. Postoji službeni repozitorij, a može biti i privatni repozitorij tvrtke ili projekta.

Interakcija

Razmotrimo kako komponente arhitekture međusobno djeluju kada želimo instalirati aplikaciju putem Helma.

• Kažemo Helm install, obraćamo se repozitoriju (Chart Repo) i dobivamo Helm chart.

• Helm alat (Helm CLI) djeluje s Kubeconfigom, kako bi saznao kojem klasteru se obratiti. 
• Nakon što dobijemo te informacije, alat se obraća Tilleru, koji se nalazi u našem klasteru, već kao aplikaciji. 
• Tiller se obraća Kube-apiserveru kako bi poduzeo radnje u Kubernetesu, stvorio neke objekte (servise, podove, replikate, tajne itd.).

Zatim ćemo pojednostaviti shemu kako bismo vidjeli vektore napada kojima bi se cijela arhitektura Helma mogla suočiti. A kasnije ćemo pokušati je zaštititi.

Vektori napada

Prvo potencijalno slabo mjesto — privilegirani API—korisnik. U okviru sheme, to je haker koji je dobio administratorski pristup Helm CLI.

Nepovlašteni API korisnik također može predstavljati opasnost ako se nalazi negdje u blizini. Takav korisnik će imati drugi kontekst, na primjer, može biti zabilježen u jednom namespaceu klastera u postavkama Kubeconfig.

Najzanimljiviji vektor napada može biti proces koji se nalazi unutar klastera negdje blizu Tillera i može mu pristupiti. To može biti web server ili mikroservis koji vidi mrežno okruženje klastera.

Egzotična, ali sve popularnija, varijanta napada povezana je s Chart Repo. Chart koji je kreiran od strane nesavjesnog autora može sadržavati nesigurne resurse, a vi biste ga izvršili vjerujući mu. Ili bi mogao zamijeniti chart koji preuzimate iz zvaničnog repozitorija i, na primjer, stvoriti resurs u obliku politika i tako eskalirati svoj pristup.

Pokušajmo se obraniti od napada sa svih ovih četiri strane i istražiti gdje su ovdje problemi u arhitekturi Helma, a gdje ih možda nema.

Uvećajmo shemu, dodajmo više elemenata, ali sačuvajmo sve osnovne komponente.

Helm CLI komunicira s Chart Repo, interagira s Kubeconfigom, a rad se prosljeđuje u klaster u komponentu Tiller.

Tiller je predstavljen s dva objekta:

• Tiller-deploy svc koji izlaže određenu uslugu;
• Tiller-deploy pod (na shemi u jednoj jedinstvenoj instanci u jednoj repliki), na kojem se odvija sav teret, koji se obraća klasteru.

Za interakciju se koriste različiti protokoli i sheme. Sa stajališta sigurnosti, najzanimljiviji su nam:

• Mehanizam putem kojeg Helm CLI pristupa chart repo: koji protokol, postoji li autentifikacija i što se s tim može učiniti.
• Protokol putem kojeg Helm CLI, koristeći kubectl, komunicira s Tillerom. To je RPC server instaliran unutar klastera.
• Sam Tiller je dostupan mikroservisima koji se nalaze u klasteru i interagira s Kube-apiserverom.

Razgovarajmo o svim tim pravcima redom.

RBAC

Besmisleno je govoriti o bilo kojoj sigurnosti Helma ili druge usluge unutar klastera, ako RBAC nije uključen.

Čini se da to nije najnovija preporuka, ali sam siguran da mnogi i dalje nisu uključili RBAC čak ni u produkciji, jer je to velika gnjavaža i treba sve dobro postaviti. Ipak, pozivam vas da to učinite.

https://rbac.dev/ — pravni savjetnik za RBAC. Tamo se nalazi ogroman broj zanimljivih materijala koji će pomoći u postavljanju RBAC-a, pokazati zašto je dobar i kako s njim živjeti u produkciji.

Pokušat ću objasniti kako Tiller i RBAC rade. Tiller radi unutar klastera pod nekim servisnim računom. Obično, ako RBAC nije postavljen, to će biti superuser. U osnovnoj konfiguraciji Tiller će biti admin. Zato se često kaže da je Tiller SSH tunel do vašeg klastera. U stvarnosti, to je tako, pa se može koristiti poseban servisni račun umjesto Default Service Account na gornjoj shemi.

Kada inicijalizirate Helm, prvi put ga instalirate na server, možete odrediti servisni račun pomoću --service-account. To će omogućiti korištenje korisnika s minimalnim potrebnim skupom prava. Nažalost, morat ćete stvoriti takvu "niz": Role i RoleBinding.

Nažalost, Helm to neće učiniti umjesto vas. Vama ili vašem administratoru Kubernetes klastera potrebno je unaprijed pripremiti skup Role i RoleBinding za servisni račun kako bi se predao Helmu.

Pitanje se postavlja — koja je razlika između Role i ClusterRole? Razlika je u tome što ClusterRole djeluje za sve namespaces, za razliku od običnih Role i RoleBinding, koji rade samo za specijalizirani namespace. Možete postaviti politike i za cijeli klaster i za sve namespaces, kao i personalizirane za svaki namespace pojedinačno.

Treba spomenuti da RBAC omogućuje rješavanje još jednog velikog problema. Mnogi se žale da Helm, nažalost, nije multitenant (ne podržava višekorisničko korištenje). Ako nekoliko timova koristi klaster i koristi Helm, u načelu se ne može postaviti politike i ograničiti njihov pristup u okviru tog klastera, jer postoji neki servisni račun pod kojim radi Helm, i on stvara sve resurse u klasteru, što ponekad može biti vrlo nezgodno. To je istina — kao sama binarna datoteka, kao proces, Helm Tiller nema pojam o multitenantnosti..

Međutim, postoji izvrstan način koji omogućava pokretanje Tillera u klasteru više puta. S tim nema nikakvih problema, Tiller se može pokrenuti u svakom namespaceu. Tako možete iskoristiti RBAC, Kubeconfig kao kontekst, i ograničiti pristup posebnom Helmu.

To će izgledati ovako.

Na primjer, postoje dva Kubeconfig s kontekstom za različite timove (dva namespace): X Team za razvojni tim i adminsitratorski klaster. Administratorski klaster ima svoj široki Tiller, koji se nalazi u Kube-system namespace, a time i napredne service-account. Osim toga, postoji odvojen namespace za razvojni tim, koji će moći implementirati svoje servise u poseban namespace.

To je radni pristup, Tiller nije toliko zahtjevan da bi to moglo značajno utjecati na vaš budžet. To je jedno od brzih rješenja.

Ne ustručavajte se odvojeno konfigurirati Tiller i pružiti Kubeconfig s kontekstom za tim, za određenog programera ili za okruženje: Dev, Staging, Production (dosta je sumnjivo da će sve biti na jednom klasteru, iako je to moguće).

Nastavljajući našu priču, prebacit ćemo se s RBAC-a i razgovarati o ConfigMaps.

ConfigMaps

Helm koristi ConfigMaps kao skladište podataka. Kada smo govorili o arhitekturi, nije bilo nijedne baze podataka u kojoj se čuvaju informacije o izdanjima, konfiguracijama, rollback-ima itd. Za to se koristi ConfigMaps.

Glavni problem s ConfigMaps-ima je poznat — oni su inherentno nesigurni, u njima nije moguće čuvati osjetljive podatke. Riječ je o svemu što ne bi trebalo izaći iz servisa, poput lozinki. Najprikladniji način za Helm sada je prelazak s korištenja ConfigMaps-a na tajne.

To se radi vrlo jednostavno. Preopredjeljujete postavku Tiller-a i navodite da će skladište biti tajne. Tada ćete za svaku implementaciju dobivati ne ConfigMap, već tajnu.

Možete prigovoriti da su same tajne - čudna koncept, i da to nije baš sigurno. Međutim, treba razumjeti da se ovim pitanjima bave sami razvojni programeri Kubernetes-a. Počevši od verzije 1.10, tj. već neko vrijeme, postoji mogućnost, bar u javnim oblacima, povezati odgovarajuće skladište za pohranu tajni. Trenutno tim radi na još boljoj distribuciji pristupa tajnama, određenim podovima ili drugim entitetima.

Skladište Helm je bolje prevesti na tajne, a njih zauzvrat centralizirano osigurati.

Naravno, ostat će ograničenje za pohranu podataka od 1 MB. Helm ovdje koristi etcd kao distribuirano skladište za ConfigMaps. Tamo su procijenili da je to prikladni komad podataka za replikacije itd. O tome postoji zanimljiva rasprava na Redditu, preporučujem da pronađete ovo zanimljivo štivo za vikend ili pročitate sažetak. ovdje.

Chart Repos

Chartovi su najviše društveno ranjivi i mogu postati izvor "Man in the middle", posebno ako koristite standardna rješenja. Uglavnom se radi o repozitorijima koji su dostupni putem HTTP-a.

Definitivno, treba postaviti Helm Repo preko HTTPS-a — to je najbolja opcija i nije skupa.

Obratite pažnju na mehanizam potpisa chartova. Tehnologija je izuzetno jednostavna. To je isto ono što koristite na GitHubu, obična PGP mašinerija s javnim i privatnim ključevima. Postavite to i bit ćete sigurni, imajući potrebne ključeve i potpisujući sve, da je to stvarno vaš chart.

Osim toga, Helm klijent podržava TLS (ne u smislu HTTP-a sa strane servera, već uzajamni TLS). Možete koristiti server i klijent ključeve za komunikaciju. Iskreno, ne koristim takav mehanizam zbog nevolje prema uzajamnim certifikatima. U principu, chartmuseum — glavni alat za postavljanje Helm Repo za Helm 2 — također podržava basic auth. Možete koristiti basic auth ako je to prikladnije i sigurnije.

Postoji i plugin helm-gcs, koji omogućuje postavljanje Chart Repos u Google Cloud Storage. To je prilično praktično, odlično radi i dovoljno je sigurno, jer se koriste svi opisani mehanizmi.

Ako uključite HTTPS ili TLS, koristite mTLS, povežite basic auth da dodatno smanjite rizike, dobit ćete siguran kanal komunikacije između Helm CLI i Chart Repo.

gRPC API

Sljedeći korak je vrlo odgovoran — osigurati Tiller, koji se nalazi u klasteru i koji je, s jedne strane, server, a s druge strane — sam pristupa drugim komponentama i pokušava se predstavljati nekim drugim.

Kao što sam već rekao, Tiller je servis koji izlaže gRPC, a Helm klijent dolazi do njega putem gRPC-a. Po defaultu, naravno, TLS je isključen. Zašto je to tako — pitanje je rasprave, mislim da je to kako bi se pojednostavila inicijalna konfiguracija.

Za produkciju i čak za staging preporučujem uključiti TLS na gRPC.

Smislim da je, za razliku od mTLS za chartove, ovdje to prikladno i vrlo jednostavno — generirate PQI infrastrukturu, kreirate certifikat, pokrećete Tiller, predajete certifikat tijekom inicijalizacije. Nakon toga možete izvoditi sve Helm naredbe, predstavljajući se generiranim certifikatom i privatnim ključem.

Time ćete se zaštititi od svih zahtjeva prema Tilleru izvana iz klastera.

Dakle, osigurali smo kanal povezivanja s Tillerom, već smo razgovarali o RBAC-u i postavili prava Kubernetes apiservera, smanjili domen koji može komunicirati.

Zaštićeni Helm

Pogledajmo konačnu shemu. To je ista arhitektura sa istim strelicama.

Sve veze sada se mogu odvažnije prikazati zelenom bojom:

• za Chart Repo koristimo TLS ili mTLS i osnovnu autentifikaciju;
• mTLS za Tiller, koji je izložen kao gRPC usluga s TLS-om, koristimo certifikate;
• u klasteru se koristi posebni servisni račun s ulogom i RoleBindingom. 

Značajno smo osigurali klaster, ali netko pametan je rekao:

„Apsolutno sigurno rješenje može biti samo jedno — isključen računar koji se nalazi u betonskoj kutiji i čuvaju ga vojnici.“

Postoje različiti načini manipulacije podacima i pronalaženja novih vektora napada. Međutim, siguran sam da će vas ove preporuke omogućiti da postignete osnovni industrijski standard sigurnosti.

Bonus

Ovaj dio se ne odnosi izravno na sigurnost, ali će također biti koristan. Prikazat ću neke zanimljive stvari koje mnogi ne znaju. Na primjer, kako tražiti chartove — službene i neslužbene.

U repozitoriju github.com/helm/charts sada postoji oko 300 chartova i dva strima: stable i incubator. Oni koji doprinose znaju koliko je teško preći iz incubatora u stable, i koliko je lako ispasti iz stablea. Međutim, ovo nije najbolji alat za traženje chartova za Prometheus i sve što vam se sviđa, iz jednog jednostavnog razloga — to nije portal za jednostavno pretraživanje paketa.

Ali postoji usluga hub.helm.sh, s kojom je pronalaženje chartova mnogo jednostavnije. Najvažnije, tamo je znatno više vanjskih repozitorija i dostupno je gotovo 800 chartova. Osim toga, možete povezati svoj repozitorij ako iz nekog razloga ne želite slati svoje chartove u stable.

Isprobajte hub.helm.sh i hajde da ga zajedno razvijamo. Ova usluga je pod Helm projektom, a vi možete doprinositi čak i njegovom UI-ju ako ste frontend developer i želite jednostavno poboljšati izgled.

Također želim skrenuti vašu pozornost na Open Service Broker API integraciju. Zvuči komplicirano i nejasno, ali rješava probleme s kojima se svi suočavaju. Objasnit ću na jednostavnom primjeru.

Imamo Kubernetes klaster u kojem želimo pokrenuti klasičnu aplikaciju — WordPress. Obično, za punu funkcionalnost potrebna je baza podataka. Ima mnogo različitih rješenja, na primjer, možemo pokrenuti vlastitu stateful uslugu. To nije baš zgodno, ali mnogi to rade.

Drugi, na primjer mi u Chainstack-u, koriste upravljane baze podataka, kao što su MySQL ili PostgreSQL, za servere. Stoga se naše baze nalaze negdje u oblaku.

Ali javlja se problem: potrebno je povezati našu uslugu s bazom podataka, stvoriti flavor baze podataka, prenijeti vjerodajnice i nekako njima upravljati. Sve to obično obavlja sistemski administrator ili programer ručno. Nema problema kad je aplikacija malo. Kada ih je puno, potrebna je kombajn. Takav kombajn postoji — to je Service Broker. Omogućuje korištenje posebnog dodatka za klaster javnog oblaka i naručivanje resursa od pružatelja putem Brokera, kao da je to API. Za to se mogu koristiti izvorni alati Kubernetes-a.

To je vrlo jednostavno. Možete zatražiti, na primjer, Managed MySQL u Azure-u s osnovnim tierom (to se može podesiti). Korištenjem Azure API-a baza će biti stvorena i pripremljena za korištenje. Nećete se trebati u to miješati, za to se brine dodatak. Na primjer, OSBA (Azure dodatak) će vratiti vjerodajnice u servis, prenijeti to Helm-u. Moći ćete koristiti WordPress s oblaku MySQL-om, ne brinući se o upravljanim bazama podataka i ne zamarajući se stateful uslugama unutra.

Može se reći da Helm predstavlja ljepilo koje s jedne strane omogućuje raspoređivanje usluga, a s druge — konzumiranje resursa pružatelja oblaka.

Možete napisati svoj dodatak i koristiti cijelu tu priču on-premise. Tada ćete imati jednostavno svoj dodatak za korporativnog Cloud-providera. Preporučujem da isprobate takav pristup, posebno ako imate veliku razmjenu i želite brzo postaviti dev, staging ili cijelu infrastrukturu pod funkciju. To će olakšati život vašim operacijama ili DevOps-u.

Još jedan nalaz koji sam već spomenuo — to je helm-gcs dodatak, koji omogućuje korištenje Google-buckets (objektno spremište) za pohranu Helm-ovih grafova.

Potrebna su samo četiri naredbe da biste počeli koristiti:

1. instalirati dodatak;
2. inicializirati ga;
3. postaviti put do bucket-a koji se nalazi u gcp;
4. objaviti karte na standardni način.

Lepota je u tome što će se koristiti native pristup gcp za autorizaciju. Možete koristiti servisni račun, račun programera — sve što želite. To je vrlo zgodno i ne košta ništa u eksploataciji. Ako, kao i ja, propagirate opsless filozofiju, onda će vam ovo biti vrlo praktično, posebno za manje timove.

Alternatives

Helm nije jedino rešenje za upravljanje servisima. Ima puno pitanja, verovatno zbog toga je tako brzo izašla treća verzija. Naravno, postoje alternative.

To mogu biti specijalizovana rešenja, kao što su Ksonnet ili Metaparticle. Možete koristiti svoja klasična sredstva za upravljanje infrastrukturom (Ansible, Terraform, Chef itd.) za iste ciljeve o kojima sam govorio.

Na kraju, postoji rešenje Operator Framework, čija popularnost raste.

Operator Framework je glavna alternativa Helmu na koju treba obratiti pažnju.

Ono je više nativno za CNCF i Kubernetes, ali je prag ulaska mnogo viši, potrebno je više programirati i manje opisivati manifeste.

Postoje različiti dodaci, kao što su Draft, Scaffold. Oni značajno olakšavaju život, na primer, programerima olakšavaju ciklus slanja i pokretanja Helma za implementaciju testnog okruženja. Nazvao bih ih proširivačima mogućnosti.

Evo preglednog grafikona o tome gde se šta nalazi.

Na apscisi je nivo vaše lične kontrole nad dešavanjima, na ordinati nivo nativnosti Kubernetesa. Helm verzija 2 je negde na sredini. U verziji 3 nije monumentalno, ali su poboljšani i kontrola i nivo nativnosti. Rešenja nivoa Ksonnet su ipak inferiorna čak i Helmu 2. Međutim, vredi ih pogledati da biste znali šta još postoji u ovom svetu. Naravno, vaš menadžer konfiguracije će biti pod vašom kontrolom, ali apsolutno nije nativan za Kubernetes.

Operator Framework je apsolutno nativan za Kubernetes i omogućava da se njime upravlja mnogo elegantnije i preciznije (ali pametno je imati na umu nivo ulaska). Pre bi bio pogodan za specijalizovanu aplikaciju i kreiranje menadžmenta za nju, nego kao masovni kombajn za pakovanje ogromnog broja aplikacija pomoću Helma.

Proširivači samo malo poboljšavaju kontrolu, dopunjavaju radne tokove ili skraćuju uglove CI/CD pipelines.

Budućnost Helma

Dobra vijest je da dolazi Helm 3. Već je objavljena alfa verzija Helm 3.0.0-alpha.2, koju možete isprobati. Dovoljno je stabilna, ali funkcionalnost je još uvijek ograničena.

Zašto je potreban Helm 3? Prije svega, radi se o nestajanju Tillera, kao komponente. To je, kao što već razumijete, ogroman korak naprijed, jer se s aspekta sigurnosti arhitekture sve pojednostavljuje.

Kada je Helm 2 stvoren, a to je bilo u vrijeme Kubernetes 1.8 ili čak ranije, mnoge koncepcije su bile nezrele. Na primjer, koncept CRD se sada aktivno implementira, a Helm će koristiti CRD, kako bi pohranio strukture. Bit će moguće koristiti samo klijenta i ne držati serverski dio. U skladu s tim, koristiti nativne Kubernetes komande za rad sa strukturama i resursima. To je ogroman korak naprijed.

Pojavit će se podrška za nativne OCI repozitorije (Open Container Initiative). To je ogromna inicijativa, a Helm je zanimljiv prvenstveno za to da smjesti svoje karte. Dolazi do toga da, na primjer, Docker Hub podržava mnoge OCI standarde. Ne želim precijeniti, ali možda će klasični pružatelji Docker repozitorija početi davati mogućnost smještaja svojih Helm karata.

Sporna priča za mene je podrška za Luu, kao templating engine za pisanje skripti. Nisam veliki obožavatelj Lue, ali to će biti potpuno opcionalna mogućnost. Provjerio sam to tri puta — korištenje Lue neće biti obavezno. Dakle, tko želi može koristiti Luu, a tko voli Go — pridružite se našem velikom kampu i koristite go-tmpl za to.

Napokon, ono što mi je definitivno nedostajalo je pojava sheme i validacija tipova podataka. Više neće biti problema s int ili string, nije potrebno obavijati nulu u dvostruke navodnike. Pojavit će se JSONS shema koja će to omogućiti da se jasno opiše za values.

Veoma će se preraditi event-driven model. Već je konceptualno opisan. Pogledajte u granu Helm 3 i vidjet ćete koliko je mnogo dodatih događaja, hookova i drugih stvari koje će znatno pojednostaviti i, s druge strane, dodati kontrolu nad procesima implementacije i reakcijama na njih.

Helm 3 će biti jednostavniji, sigurniji i zanimljiviji ne zato što volimo Helm 2 manje, već zato što Kubernetes postaje napredniji. U skladu s tim, Helm može iskoristiti dostignuća Kubernetes-a i stvoriti odlične menadžere za Kubernetes.

Još jedna dobra vijest je da DevOpsConf Aleksandar Hajev će govoriti, mogu li kontejneri biti sigurni? Podsjećamo, konferencija o integraciji procesa razvoja, testiranja i operacija održat će se u Moskvi 30. rujna i 1. listopada. Do 20. kolovoza još se može ili opušteno i podijeliti svoja iskustva rješavanja jednog od mnogih zadatka DevOps pristupa.

Za novosti i informacije o konferenciji pratite našu newsletteru i telegram grupu.

Izvor: habr.com