Helm-säkerhet

Kärnan i berättelsen om den mest populära paketchefen för Kubernetes kan beskrivas med hjälp av emojis:

• lådan – det är Helm (det mest passande som finns i den senaste Emoji-versionen);
• lås – säkerhet;
• människa – lösningen på problemet.

I själva verket kommer det att vara lite mer komplicerat, och berättelsen är full av tekniska detaljer om hur man gör Helm säkert.

• Kort sagt, vad är Helm, om du inte visste eller glömde det. Vilka problem löser den och var ligger den i ekosystemet.
• Låt oss titta på Helm-arkitekturen. Ingen diskussion om säkerhet och hur man kan göra ett verktyg eller en lösning mer säker kan passera utan att förstå komponentens arkitektur.
• Vi kommer att diskutera Helm-komponenter.
• Den mest brännande frågan – framtiden – den nya versionen Helm 3. 

Allt i denna artikel handlar om Helm 2. Den versionen är för närvarande i produktion och det är troligtvis den du använder just nu, och det är i den som det finns säkerhetshot.

Om talaren: Alexander Khayorov (allexx) har arbetat med utveckling i 10 år och hjälper till att förbättra innehållet Moscow Python Conf++ och gick med i kommittén Helm Summit. Just nu arbetar han på Chainstack som utvecklingsledare – en hybrid mellan en utvecklingsledare och en som ansvarar för leverans av slutprodukter. Det vill säga, han befinner sig på slagfältet där allt händer från produktens skapelse till dess drift.

Chainstack är en liten, växande startup vars uppgift är att ge kunder möjlighet att glömma infrastrukturen och svårigheterna att driva decentraliserade applikationer, utvecklingsteamet är baserat i Singapore. Be inte Chainstack att sälja eller köpa kryptovaluta, utan föreslå att prata om företagsramverken för blockchain, så kommer de gärna att svara.

Helm

Detta är en paketchef (diagram) för Kubernetes. Det mest förståeliga och mångsidiga sättet att ta appar till Kubernetes-klustret.

Det handlar naturligtvis om en mer strukturerad och industriell metod än att skapa sina egna YAML-manifest och skriva små verktyg.

Helm är det bästa som finns tillgängligt och populärt just nu.

Varför Helm? Först och främst för att den stöds av CNCF. Cloud Native är en stor organisation och moderbolag för projekt som Kubernetes, etcd, Fluentd och andra.

En annan viktig faktum är att Helm är ett mycket populärt projekt. När jag i januari 2019 först tänkte berätta om hur man gör Helm säkert hade projektet tusen stjärnor på GitHub. I maj hade de blivit 12 000.

Många är intresserade av Helm, så även om du fortfarande inte använder det kan kunskapen om dess säkerhet vara värdefull. Säkerhet är viktigt.

Det huvudsakliga teamet bakom Helm stöds av Microsoft Azure, vilket gör att projektet är relativt stabilt i jämförelse med många andra. Utrullningen av Helm 3 Alpha 2 i mitten av juli visar att det finns många människor som arbetar med projektet, och de har både vilja och resurser för att utveckla och förbättra Helm.

Helm löser flera centrala problem med applikationshantering i Kubernetes.

• Paketera applikationer. Även en applikation som "Hello, World" på WordPress består av flera tjänster som man vill paketera tillsammans.
• Hanterar den komplexiteten som uppstår med hanteringen av dessa applikationer.
• Livscykeln som inte slutar efter installation eller deployment av applikationen. Den fortsätter att existera, den behöver uppdateras, och Helm hjälper till med det och strävar efter att ge de rätta åtgärderna och policyn.

Packetering är uppbyggd på ett förståeligt sätt: det finns metadata som helt överensstämmer med hur en vanlig pakethanterare fungerar för Linux, Windows eller MacOS. Det vill säga en repository, beroenden mellan olika paket, metadata för applikationer, inställningar, konfigurationsspecifikationer, indexering av information etc. Allt detta möjliggör Helm att erhålla och använda för applikationerna.

Hantering av komplexitet. Om du har många liknande applikationer behövs parameterisering. Därifrån uppstår mallar, men för att inte behöva uppfinna egna sätt att skapa mallar kan du använda det som Helm erbjuder "out of the box".

Hantera livscykeln av applikationen är - enligt min mening - den mest intressanta och olösta frågan. Det är anledningen till att jag kom till Helm i första hand. Vi behövde hålla koll på applikationens livscykel, vi ville flytta vår CI/CD och applikationscykler till detta paradigm.

Helm möjliggör:

• att hantera distributioner, introducera begreppet konfiguration och revision;
• framgångsrikt utföra rollback;
• använda hooks för olika händelser;
• lägga till ytterligare kontroller för applikationer och reagera på deras resultat.

Dessutom Helm har "batterier". — ett stort antal goda saker som kan inkluderas som plugins, vilket förenklar livet. Plugins kan skrivas av dig själv, de är tillräckligt isolerade och kräver ingen känslig arkitektur. Om du vill implementera något, rekommenderar jag att göra det som en plugin och eventuellt senare inkludera det i upstream.

Helm bygger på tre grundläggande koncept:

• Chart Repo — en beskrivning och en uppsättning parametrar som kan användas för din manifest. 
• Konfigurera — det vill säga värden som kommer att tillämpas (text, numeriska värden osv.).
• Release innehåller de två överliggande komponenterna, och tillsammans blir de till en Release. Releases kan versionshanteras, vilket möjliggör livscykelorganisation: liten vid installation och stor vid uppgradering, nedgradering eller återställning.

Helm-arkitektur

Schemat visar konceptuellt den hög nivå arkitekturen för Helm.

Jag påminner om att Helm är något som är kopplat till Kubernetes. Därför kan vi inte klara oss utan en Kubernetes-kluster (rektangel). Komponenten kube-apiserver finns på mastern. Utan Helm har vi Kubeconfig. Helm tillhandahåller en liten binär som kan kallas Helm CLI, som installeras på datorer, bärbara datorer, mainframes — på vad som helst.

Men detta är inte tillräckligt. Helm har en serverkomponent, Tiller. Den representerar Helm:s intressen inom klustret, det är en liknande applikation inom Kubernetes-klustret som vilken annan som helst.

Den nästa komponenten, Chart Repo — ett repository med charts. Det finns ett officiellt repository, och det kan finnas ett privat repository för företaget eller projektet.

Interaktion

Låt oss se hur komponenterna i arkitekturen interagerar när vi vill installera en applikation med hjälp av Helm.

• Vi säger Helm install, vi kontaktar repositoryt (Chart Repo) och får Helm-charten.

• Helm-verktyget (Helm CLI) interagerar med Kubeconfig för att ta reda på vilket kluster som ska kontaktas. 
• När denna information har erhållits, kontaktar verktyget Tiller, som finns i vårt kluster, som en applikation. 
• Tiller kontaktar Kube-apiserver för att utföra åtgärder i Kubernetes, skapa vissa objekt (tjänster, pods, repliker, hemligheter osv.).

Därefter kommer vi att komplicera schemat för att se de attackvektorer som hela Helm-arkitekturen kan utsättas för. Och sedan försöka skydda den.

Attackvektor

Den första potentiellt svaga punkten — privilegierad API—användare. Inom schemat är detta en hacker som har fått administrativ åtkomst till Helm CLI.

Icke-privilegierad API-användare kan också utgöra en risk om den är i närheten. En sådan användare kommer att ha en annan kontext, till exempel kan den vara inlåst i ett visst namespace i klusterinställningarna för Kubeconfig.

Den mest intressanta attackvektorn kan vara en process som finns någonstans i klustret nära Tiller och kan kommunicera med den. Det kan vara en webbserver eller mikrotjänst som ser det nätverksmiljö som klustret befinner sig i.

Ett exotiskt, men växande, alternativ till attacken är relaterat till Chart Repo. En chart skapad av en illojal författare kan innehålla osäkra resurser, och du kommer att köra den i tron att den är säker. Eller så kan den ersätta den chart som du laddar ner från det officiella arkivet och, till exempel, skapa resurser i form av policys och eskalera sin egen åtkomst.

Låt oss försöka avvärja attacker från alla dessa fyra håll och se var det finns problem i Helm-arkitekturen och var det eventuellt inte finns några.

Vi gör schemat större, lägger till fler element men behåller alla grundläggande beståndsdelar.

Helm CLI kommunicerar med Chart Repo, interagerar med Kubeconfig och jobbet överlämnas till klustret i komponenten Tiller.

Tiller representeras av två objekt:

• Tiller-deploy svc, som ställer upp en viss tjänst;
• Tiller-deploy pod (i schemat i ett enda exemplar i en replik), där all belastning körs och som kommunicerar med klustret.

Olika protokoll och scheman används för interaktionen. Från säkerhetssynpunkt är vi mest intresserade av:

• Mechanismen genom vilken Helm CLI kommunicerar med chart repo: vilket protokoll används, finns det autentisering och vad kan man göra med detta.
• Protokollet genom vilket Helm CLI, med hjälp av kubectl, kommunicerar med Tiller. Det är en RPC-server som är installerad inuti klustret.
• Själva Tiller är tillgängligt för mikrotjänster som finns i klustret och interagerar med Kube-apiserver.

Låt oss diskutera alla dessa riktningar i ordning.

RBAC

Det är meningslöst att prata om någon säkerhet för Helm eller annan tjänst inom klustret om RBAC inte är aktiverat.

Det verkar som om detta inte är det senaste rådet, men jag är säker på att många fortfarande inte har aktiverat RBAC, även i produktion, eftersom det innebär mycket arbete och man måste konfigurera mycket. Jag uppmanar ändå att göra det.

https://rbac.dev/ — en advokat-webbplats för RBAC. Här samlas en enorm mängd intressanta material som hjälper till att ställa in RBAC, visar varför det är bra och hur man generellt kan arbeta med det i produktion.

Jag ska försöka förklara hur Tiller och RBAC fungerar. Tiller körs inuti klustret under ett specifikt servicekonto. I allmänhet, om RBAC inte är inställt, kommer det att vara en superanvändare. I standardkonfigurationen kommer Tiller att vara administratör. Därför säger man ofta att Tiller är en SSH-tunnel till ditt kluster. Så är det i verkligheten, så du kan använda ett separat specialiserat servicekonto istället för Default Service Account som visas ovan.

När du initierar Helm, installerar det för första gången på servern, kan du ange servicekontot med --service-account. Detta gör det möjligt att använda en användare med det minimiuppsättning av rättigheter som krävs. Tyvärr måste du skapa en sådan "kedja": Role och RoleBinding.

Tyvärr kommer Helm inte att göra detta för dig. Antingen du eller din Kubernetes-klusteradministratör måste i förväg förbereda en uppsättning Role, RoleBinding för servicekonto, för att överföra till Helm.

Frågan uppstår — vad är skillnaden mellan Role och ClusterRole? Skillnaden är att ClusterRole gäller för alla namespaces, till skillnad från vanliga Role och RoleBinding, som endast fungerar för specifika namespaces. Du kan ställa in riktlinjer för hela klustret och alla namespaces, såväl som personligt för varje namespace individuellt.

Det är värt att nämna att RBAC också löser ett annat stort problem. Många klagar på att Helm tyvärr inte är multitenancy (inte stöder fleranvändartillgång). Om flera team använder klustret och Helm, är det i princip omöjligt att ställa in riktlinjer och avgränsa deras åtkomst inom detta kluster, eftersom det finns ett specifikt servicekonto under vilket Helm fungerar, och det skapar alla resurser i klustret från detta, vilket ibland är mycket opraktiskt. Det är verkligen sant — både den binära filen och processen, Helm Tiller har ingen uppfattning om multitenancy..

Det finns dock ett utmärkt sätt som gör att du kan köra Tiller flera gånger i klustret. Det finns inga problem med detta, Tiller kan startas i varje namespace. Så kan du dra nytta av RBAC, Kubeconfig som kontext, och begränsa åtkomsten till ett speciellt Helm.

Det kommer att se ut som följande.

Till exempel finns det två Kubeconfig med kontext för olika team (två namespace): X Team för utvecklarteamet och klusteradministratören. Klusteradministratören har sin breda Tiller, som finns i kube-system namespace, och därmed en avancerad service-account. Och ett separat namespace för utvecklarteamet, där de kan deploya sina tjänster i det specifika namespace.

Detta är en fungerande metod, Tiller är inte så resurskrävande att det skulle påverka din budget märkbart. Det är en av de snabba lösningarna.

Tveka inte att konfigurera Tiller separat och tillhandahålla Kubeconfig med kontext för teamet, för en specifik utvecklare eller för miljön: Dev, Staging, Production (det är osannolikt att allt kommer att vara på ett kluster, men det kan göras).

Fortsätter vi vår historia, byter vi från RBAC och pratar om ConfigMaps.

ConfigMaps

Helm använder ConfigMaps som datalagring. När vi pratade om arkitekturen fanns det ingen databas där information om releaser, konfigurationer, rollbacks och så vidare lagrades. Det används ConfigMaps för.

Det största problemet med ConfigMaps är känt – de är i grunden osäkra, i dem kan man inte lagra känslig information. Det handlar om allt som inte bör komma längre än tjänsten, till exempel lösenord. Det mest naturnära sättet för Helm just nu är att övergå från att använda ConfigMaps till hemligheter.

Detta görs mycket enkelt. Du överskriver konfigurationen för Tiller och anger att lagringen ska vara hemligheter. Då får du istället för ConfigMap en hemlighet vid varje deployment.

Du kan invända mot att själva hemligheterna är ett konstigt koncept och inte särskilt säkra. Men det är viktigt att förstå att detta hanteras av Kubernetes-skaparna. Från och med version 1.10, dvs. ganska länge sedan, finns det möjlighet att åtminstone i offentliga moln ansluta riktigt lagringsutrymme för att lagra hemligheter. Just nu arbetar teamet på att ge bättre åtkomst till hemligheter för vissa pods eller andra enheter.

Storage Helm bör bättre översättas till hemligheter, och dessa ska centralt säkras.

Självklart kommer det att finnas en gräns för datalagring på 1 MB. Helm använder här etcd som ett distribuerat lager för ConfigMaps. Där ansåg man att detta var en lämplig databit för replikeringar och så vidare. Det finns en intressant diskussion om detta på Reddit, jag rekommenderar att du hittar denna underhållande läsning för helgen eller läser sammanfattningen. ). Ett typiskt exempel på användning:.

Chart Repos

Charts är särskilt socialt utsatta och kan bli en källa till "Man in the middle", särskilt när man använder ett standardlösning. Främst handlar det om depåer som exponeras via HTTP.

Det är definitivt viktigt att exponera Helm Repo via HTTPS – det är den bästa lösningen och kostar inte mycket.

Observera signeringsmekanismen för charts. Tekniken är så enkelt att det nästan är löjligt. Det är samma sak som du använder på GitHub, den vanliga PGP-maskineriet med offentliga och privata nycklar. Ställ in det och var säker på att ha de rätta nycklarna och signera allt så att det verkligen är din chart.

Dessutom, Helm-klienten stöder TLS (inte i meningen HTTP från serverns sida, utan ömsesidig TLS). Du kan använda server- och klientnycklar för att kommunicera. Jag ska ärligt säga att jag inte använder en sådan mekanism på grund av ogillande av ömsesidiga certifikat. I princip, chartmuseum — det primära verktyget för att exponera Helm Repo för Helm 2 — stödjer även basic auth. Du kan använda basic auth om det är mer bekvämt och tryggt.

Det finns även en plugin helm-gcs, som gör det möjligt att lagra Chart Repos i Google Cloud Storage. Detta är ganska praktiskt, fungerar utmärkt och är tillräckligt säkert eftersom alla de beskrivna mekanismerna används.

Om du aktiverar HTTPS eller TLS, använder mTLS, aktiverar basic auth för att ytterligare minska riskerna, får du en säker kommunikationskanal mellan Helm CLI och Chart Repo.

gRPC API

Nästa steg är mycket viktigt — att säkra Tiller, som finns i klustret och är, å ena sidan, servern, å andra sidan — själv kontaktar andra komponenter och försöker framstå som någon annan.

Som jag redan sagt är Tiller en tjänst som exponerar gRPC; Helm-klienten kommer till den via gRPC. Som standard är naturligtvis TLS avstängt. Varför det är så är en diskussionsfråga, jag tror att det gjordes för att förenkla inställningen vid starten.

För produktion och till och med för staging rekommenderar jag att aktivera TLS på gRPC.

Enligt min åsikt är det här, till skillnad från mTLS för diagram, lämpligt och görs väldigt enkelt — du genererar en PQI-infrastruktur, skapar ett certifikat, kör Tiller och överför certifikatet under initialiseringen. Efter detta kan du köra alla Helm-kommandon och presentera dig med det genererade certifikatet och den privata nyckeln.

Genom detta skyddar du dig från alla förfrågningar till Tiller utanför klustret.

Så vi har skyddat anslutningskanalen till Tiller, redan diskuterat RBAC och justerat rättigheterna för Kubernetes apiserver, minskat domänen med vilken den kan interagera.

Säker Helm

Låt oss ta en titt på det slutliga schemat. Det är samma arkitektur med samma pilar.

Nu kan vi helt frimodigt rita alla anslutningar i grönt:

• för Chart Repo använder vi TLS eller mTLS och basic auth;
• mTLS för Tiller, och det ställs in som en gRPC-tjänst med TLS, vi använder certifikat;
• i klustret används ett speciellt tjänstekonto med Roll och RoleBinding. 

Vi har märkbar säkrat klustret, men någon smart sa:

"Det mest säkra lösningen kan bara vara en — en avstängd dator som ligger i en betonglåda och bevakas av soldater."

Det finns olika sätt att manipulera data och hitta nya vektorer för attacker. Men jag är säker på att dessa rekommendationer kommer att hjälpa till att implementera en grundläggande industristandard för säkerhet.

Bonus

Denna del handlar inte direkt om säkerhet, men den kommer också att vara användbar. Jag ska visa några intressanta saker som få känner till. Till exempel hur man söker efter diagram — officiella och icke-officiella.

I lagret github.com/helm/charts just nu finns det cirka 300 diagram och två strömmar: stable och incubator. Den som bidrar vet hur svårt det är att gå från incubator till stable, och hur lätt det är att åka ut från stable. Men detta är inte det bästa verktyget för att söka efter diagram för Prometheus och allt annat du gillar, av en enkel anledning — det är inte en portal där det är bekvämt att söka efter paket.

Men det finns en tjänst hub.helm.sh, som gör det mycket enklare att hitta diagram. Det viktigaste är att det finns mycket fler externa repositorier tillgängliga och nästan 800 diagram. Dessutom kan du ansluta ditt eget förråd om du av någon anledning inte vill skicka dina diagram till stable.

Prova hub.helm.sh och låt oss utveckla det tillsammans. Denna tjänst är under Helm-projektet, och du kan bidra även i dess UI, om du är frontend-utvecklare och bara vill förbättra utseendet.

Jag vill också påpeka att Open Service Broker API-integration. Det låter omständligt och oklart, men löser problem som alla står inför. Jag ska förklara med ett enkelt exempel.

Det finns en Kubernetes-kluster där vi vill köra en klassisk applikation — WordPress. Vanligtvis behövs en databas för fullständig funktionalitet. Det finns många olika lösningar, till exempel kan man köra sin egen stateful-tjänst. Det är inte särskilt praktiskt, men många gör så.

Andra, som vi på Chainstack, använder hanterade databaser, till exempel MySQL eller PostgreSQL, för servrar. Därför ligger våra databaser någonstans i molnet.

Men det uppstår ett problem: vi måste koppla vår tjänst till databasen, skapa en databas flavor, överföra credentials och på något sätt hantera det. Allt detta görs vanligtvis manuellt av en systemadministratör eller utvecklare. Det finns inget problem när det finns få applikationer. När det finns många behövs en kombinat. En sådan kombinat finns — det är Service Broker. Det låter dig använda en speciell plugin för att beställa resurser från en leverantör via Broker, som om det vore ett API. För detta kan man använda Kubernetess inbyggda medel.

Det är väldigt enkelt. Man kan begära till exempel Managed MySQL i Azure med en grundläggande nivå (detta kan justeras). Med hjälp av Azure API kommer databasen att skapas och förberedas för användning. Du behöver inte blanda dig i det, detsamma gäller pluginen. Till exempel kommer OSBA (Azure-plugin) att returnera credentials till tjänsten och överföra dem till Helm. Du kommer kunna använda WordPress med moln-MySQL, helt utan att behöva hantera hanterade databaser och behöver inte bekymra dig för stateful-tjänsterna inuti.

Man kan säga att Helm fungerar som limmet som å ena sidan tillåter att deploya tjänster, och å andra sidan — konsumera resurser från molnleverantörer.

Man kan skriva sin egen plugin och använda hela detta koncept on-premise. Då kommer du bara ha din egen plugin för din företagsmolnleverantör. Jag rekommenderar att prova denna metod, särskilt om du har en stor skala och vill snabbt implementera dev, staging eller hela infrastrukturen för en funktion. Detta kommer att förenkla livet för era operations eller DevOps.

En annan lösning som jag redan nämnt är helms-plugin-gcs, som gör det möjligt att använda Google-buckets (objektlagring) för att lagra Helm-diagram.

Det krävs bara fyra kommandon för att börja använda det:

1. installera pluginen;
2. initiera den;
3. ange en väg till bucket som finns i gcp;
4. publicera diagram på ett standardiserat sätt.

Fördelen är att den inbyggda gcp-metoden för autentisering kommer att användas. Du kan använda en tjänstekonto, utvecklarkonto — vad som helst. Det är mycket praktiskt och kostar ingenting i drift. Om du, som jag, främjar opsless-filosofin, blir det mycket användbart, särskilt för små team.

Alternativ

Helm är inte den enda lösningen för att hantera tjänster. Det finns många frågor kring det, och antagligen är det därför version tre kom så snabbt. Självklart finns det alternativ.

Det kan vara specialiserade lösningar, till exempel Ksonnet eller Metaparticle. Du kan använda dina klassiska infrastrukturella verktyg (Ansible, Terraform, Chef osv.) för samma syften som jag nämnde.

Till sist finns det en lösning Operator Framework, vars popularitet växer.

Operator Framework är den främsta alternativet till Helm, som man bör hålla ett öga på.

Den är mer inbyggd för CNCF och Kubernetes, men ingångströskeln är mycket högre, så det krävs mer programmering och mindre beskrivning av manifester.

Det finns olika tillägg, som Draft och Scaffold. De underlättar livet kraftigt, till exempel förenklar de utvecklarcykeln för att skicka och köra Helm för att distribuera testmiljöer. Jag skulle kalla dem möjlighetsförlängare.

Här är en tydlig graf över var saker ligger.

På x-axeln är nivån av ditt personliga kontroll över vad som händer, på y-axeln nivån av Kubernetes-inbyggdhet. Helm version 2 ligger någonstans i mitten. I version 3 är det inte en enorm förändring, men både kontrollen och nivån av inbyggdhet har förbättrats. Ksonnet-nivålösningar ligger fortfarande efter även Helm 2. Men det är värt att kika på dem för att veta vad som annars finns i denna värld. Självklart kommer din konfigurationshanterare att vara under din kontroll, men är absolut inte inbyggd för Kubernetes.

Operator Framework är helt inbyggt för Kubernetes och tillåter en att hantera den på ett mycket mer elegant och noggrant sätt (men kom ihåg ingångsnivån). Det är mer lämpat för specialiserade applikationer och att skapa management för dem snarare än för en masskomplettering av stora mängder applikationer med hjälp av Helm.

Möjlighetsförlängarna förbättrar bara kontrollen något, kompletterar arbetsflödet eller skär av hörn i CI/CD-pipelines.

Framtiden för Helm

Den goda nyheten är att Helm 3 har kommit. Alpha-versionen av Helm 3.0.0-alpha.2 har släppts och kan testas. Den är tillräckligt stabil, men funktionaliteten är fortfarande begränsad.

Varför behövs Helm 3? Först och främst handlar det om försvinnandet av Tiller, som komponent. Detta är, som ni redan förstår, ett stort steg framåt, eftersom det förenklar arkitekturen med avseende på säkerhet.

När Helm 2 skapades, vilket var under tiderna för Kubernetes 1.8 eller ännu tidigare, var många koncept omogna. Till exempel, konceptet CRD implementeras nu aktivt, och Helm kommer att använda CRD, för att spara strukturer. Det blir möjligt att enbart använda klienten utan att behöva en serverdel. Därmed kan man använda de inbyggda kommandona i Kubernetes för att arbeta med strukturer och resurser. Detta är ett stort framsteg.

Det kommer att finnas stöd för inhemska OCI-repositorier (Open Container Initiative). Detta är en stor initiativ, och Helm är främst intresserad av det för att kunna placera sina chartor. Det går så långt att till exempel Docker Hub stöder många OCI-standarder. Jag spekulerar inte, men det är möjligt att klassiska Docker-repositorie-leverantörer kommer att erbjuda möjligheten att placera sina Helm-chartor.

En tveksam fråga för mig är stödet för Lua, som templating engine för att skriva skript. Jag är ingen stor fan av Lua, men det kommer att vara en helt valfri möjlighet. Jag har kontrollerat detta tre gånger – användning av Lua kommer inte att vara obligatoriskt. Så den som vill, kan använda Lua, och den som gillar Go – gå med i vår stora läger och använd go-tmpl för detta.

Äntligen det som jag verkligen har saknat – framträdandet av schema och validering av datatyper. Det kommer inte längre att vara några problem med int eller string, man behöver inte längre omsluta noll med dubbla citattecken. En JSON-schema kommer att finnas som tydligt beskriver detta för values.

Den kommer att vara mycket omarbetad event-driven model. Den är redan konceptuellt beskriven. Titta i Helm 3-grenen, och ni kommer att se hur många händelser, hooks och mer som har lagts till, vilket i hög grad kommer att förenkla och å ena sidan, ge mer kontroll över deployprocesser och reaktioner på dem.

Helm 3 kommer att vara enklare, säkrare och mer intressant, inte för att vi inte gillar Helm 2, utan för att Kubernetes blir mer avancerat. Därmed kan Helm använda de framsteg som Kubernetes gör och skapa utmärkta hanterare för Kubernetes.

Ytterligare en bra nyhet är att DevOpsConf Alexander Khayev kommer att berätta, kan containrar vara säkra? Kom ihåg att konferensen om integration av utvecklings-, test- och driftsättningsprocesser kommer att hållas i Moskva den 30 september och 1 oktober. Fram till den 20 augusti kan du fortfarande skicka in en presentation och berätta om dina erfarenheter av att lösa en av många utmaningar i DevOps-ansatsen.

Följ konferensens checkpoints och nyheter på i ett nyhetsbrev och telegram-kanalen.

Källa: habr.com