Helm Security

Essensen i fortellingen om den mest populære pakkehåndtereren for Kubernetes kan illustreres med emoji:

• eske — det er Helm (det mest passende som finnes i den siste Emoji-utgaven);
• lås — sikkerhet;
• menneske — løse problemet.

I virkeligheten er det imidlertid litt mer komplisert, og fortellingen er full av tekniske detaljer om hvordan å gjøre Helm sikkert.

• Kort fortalt, hva er Helm, hvis du ikke visste eller har glemt det. Hvilke problemer løser han, og hvor plasserer han seg i økosystemet.
• La oss se på arkitekturen til Helm. Ingen samtale om sikkerhet og hvordan gjøre et verktøy eller en løsning mer sikker kan unngå å forstå komponentarkitekturen.
• Vi diskuterer komponentene i Helm.
• Det mest presserende spørsmålet — fremtiden — den nye versjonen Helm 3. 

Alt i denne artikkelen gjelder Helm 2. Denne versjonen er nå i produksjon, og det er sannsynligvis den du bruker nå, og det er i den det finnes sikkerhetstrusler.

Om taleren: Alexander Khayev (allexx) har jobbet med utvikling i 10 år, hjelper med å forbedre innholdet Moscow Python Conf++ og har blitt med i komiteen Helm Summit. Han jobber nå i Chainstack som utviklingsleder — en hybrid mellom leder for utvikling og den som er ansvarlig for levering av endelige utgivelser. Det vil si at han befinner seg på slagmarken, hvor alt fra produktutvikling til drift skjer.

Chainstack er en liten, aktivt voksende oppstartsbedrift, hvis oppgave er å gi kunder muligheten til å glemme om infrastrukturen og kompleksiteten ved drift av desentraliserte applikasjoner, utviklingsteamet er basert i Singapore. Ikke be Chainstack om å selge eller kjøpe kryptovaluta, men foreslå å snakke om enterprise blockchain-rammeverk, så vil de gjerne svare.

Helm

Dette er pakkehåndtereren (diagrammer) for Kubernetes. Den mest intuitive og universelle måten å bringe applikasjoner inn i et Kubernetes-kluster.

Det handler selvsagt om en mer strukturert og industriell tilnærming enn å lage egne YAML-manifester og skrive små verktøy.

Helm er det beste som for tiden er tilgjengelig og populært.

Hvorfor Helm? Først og fremst fordi det støttes av CNCF. Cloud Native er en stor organisasjon og morselskapet for prosjekter som Kubernetes, etcd, Fluentd og andre.

En annen viktig fakt, Helm er et veldig populært prosjekt. Da jeg i januar 2019 begynte å vurdere å fortelle om hvordan man kan gjøre Helm sikkert, hadde prosjektet 1000 stjerner på GitHub. I mai hadde det blitt 12 000.

Mange er interessert i Helm, så selv om du ennå ikke bruker det, vil kunnskap om sikkerheten rundt det være nyttig. Sikkerhet er viktig.

Hovedteamet for Helm støttes av Microsoft Azure, og derfor er det et ganske stabilt prosjekt i motsetning til mange andre. Utgivelsen av Helm 3 Alpha 2 i midten av juli viser at det er mange som jobber med prosjektet, og de har vilje og kapasitet til å videreutvikle og forbedre Helm.

Helm adresserer flere grunnleggende problemer ved applikasjonsadministrasjon i Kubernetes.

• Pakking av applikasjoner. Selv en applikasjon som «Hello, World» på WordPress består allerede av flere tjenester, og man ønsker å pakke dem sammen.
• Håndtering av kompleksiteten som oppstår med administrasjon av disse applikasjonene.
• Livssyklusen som ikke slutter etter installasjonen eller distribusjonen av applikasjonen. Den fortsetter å eksistere, den må oppdateres, og Helm bidrar til dette og prøver å tilføre riktig tiltak og retningslinjer.

Pakking er organisert på en forståelig måte: det finnes metadata i samsvar med funksjonen til en vanlig pakkebehandler for Linux, Windows eller MacOS. Det vil si et repository, avhengigheter fra forskjellige pakker, metainformasjon for applikasjonene, konfigurasjoner, spesifikasjoner for konfigurasjon, indeksering av informasjon osv. Alt dette lar Helm hente og bruke for applikasjoner.

Håndtering av kompleksitet. Hvis du har mange ensartede applikasjoner, er parameterisering nødvendig. Herav følger maler, men for å unngå å oppfinne din egen metode for å lage maler, kan du bruke det Helm tilbyr som standard.

Håndtering av applikasjonens livssyklus — etter min mening det mest interessante og uløste spørsmålet. Det er grunnen til at jeg kom til Helm en gang. Vi måtte holde oversikt over applikasjonens livssyklus, og vi ønsket å flytte vårt CI/CD og applikasjonssykluser inn i dette paradigmet.

Helm lar deg:

• håndtere distribusjoner, innføre begrepet konfigurasjon og revisjoner;
• utføre rollback suksessfullt;
• bruke hooks for forskjellige hendelser;
• legge til ekstra kontroller av applikasjoner og reagere på resultatene.

I tillegg Helm har "batterier" — et stort antall deilige ting som kan inkluderes som plugins for å forenkle livet. Plugins kan skrives selv, de er ganske isolerte og krever ingen strømlinjeformet arkitektur. Hvis du vil implementere noe, anbefaler jeg å gjøre det som en plugin, og kanskje senere inkludere det i upstream.

Helm er bygget på tre hovedkonsepter:

• Chart Repo — en beskrivelse og et sett med parametere som kan brukes for manifestet ditt. 
• Konfigurasjon — det vil si verdier som skal brukes (tekst, numeriske verdier osv.).
• Release samler de to øverste komponentene, og sammen blir de til en Release. Utgivelser kan versjoneres, noe som gir organisering av livssyklusen: liten ved installasjon og stor ved oppgradering, nedgradering eller tilbakestilling.

Helm-arkitektur

Diagrammet illustrerer Helm sin høynivåarkitektur.

Husk at Helm er noe som er knyttet til Kubernetes. Derfor trenger vi en Kubernetes-klynge (rektangel). Komponent kube-apiserver finnes på masteren. Uten Helm har vi Kubeconfig. Helm bringer med seg et lite binært verktøy, om du vil, Helm CLI, som installeres på datamaskinen, laptopen, mainframe — på hva som helst.

Men det er ikke nok. Helm har en serverkomponent Tiller. Den representerer Helm sine interesser inne i klyngen, det er en applikasjon inne i Kubernetes-klyngen akkurat som enhver annen.

Den neste komponenten Chart Repo — et repository med charts. Det finnes et offisielt repository, og det kan også være et privat repository for et selskap eller prosjekt.

Interaksjon

La oss se hvordan komponentene i arkitekturen interagerer når vi ønsker å installere en applikasjon med Helm.

• Vi sier Helm install, vi henvender oss til repository (Chart Repo) og får Helm-chartet.

• Helm-verktøyet (Helm CLI) interagerer med Kubeconfig for å finne ut hvilken klynge vi skal kontakte. 
• Når vi har fått denne informasjonen, kontakter verktøyet Tiller, som befinner seg i vår klynge, og som en applikasjon. 
• Tiller kontakter Kube-apiserver for å utføre handlinger i Kubernetes, for å opprette objekter (tjenester, podder, replikaer, hemmeligheter osv.).

Deretter vil vi komplicere diagrammet for å se angrepsvektoren som hele Helm-arkitekturen kan utsettes for. Deretter prøver vi å beskytte den.

Angrepsvektor

Det første potensielt svake punktet — privilegert API—bruker. I et diagram er dette en hacker som har fått administrativ tilgang til Helm CLI.

En ikke-privilegert API-bruker kan også utgjøre en trussel hvis de er i nærheten. En slik bruker vil ha en annen kontekst, for eksempel kan de være regulert innenfor et namespace i klyngens Kubeconfig-innstillinger.

Den mest interessante angrepsvektoren kan være prosessen som befinner seg inne i klyngen et sted nær Tiller og kan kontakte det. Dette kan være en webserver eller mikrotjeneste som ser det nettverksmiljøet i klyngen.

En eksotisk, men stadig mer populær, angrepsvariant er knyttet til Chart Repo. En chart laget av en ondsinnet forfatter kan inneholde usikre ressurser, og du kan utføre den i god tro. Eller de kan erstatte den charten du laster ned fra det offisielle depotet og for eksempel lage ressurser i form av policyer og eskalere sine rettigheter.

La oss forsøke å avvise angrep fra alle disse fire sidene og finne ut hvor problemene i Helm-arkitekturen er, og hvor det muligens ikke er noen.

Vi vil forstørre diagrammet, legge til flere elementer, men beholde alle de grunnleggende komponentene.

Helm CLI kommuniserer med Chart Repo, interagerer med Kubeconfig, og arbeidet overføres til klyngen i komponenten Tiller.

Tiller er representert med to objekter:

• Tiller-deploy svc, som setter opp en tjeneste;
• Tiller-deploy pod (i diagrammet med én forekomst i én replika), som håndterer all lasten og kontakter klyngen.

Ulike protokoller og skjemaer brukes for interaksjonen. Når det gjelder sikkerhet, er det mest interessante for oss:

• Mekanismen som Helm CLI bruker for å kontakte chart-repo: hvilken protokoll, finnes det autentisering og hva kan gjøres med dette.
• Protokollen som Helm CLI bruker, via kubectl, for å kommunisere med Tiller. Dette er en RPC-server installert inne i klyngen.
• Selve Tiller er tilgjengelig for mikrotjenester som er inne i klyngen, og interagerer med Kube-apiserver.

Vi vil diskutere alle disse retningene i rekkefølge.

RBAC

Det er meningsløst å snakke om sikkerheten til Helm eller en annen tjeneste inne i klyngen hvis RBAC ikke er aktivert.

Det kan virke som en gammel anbefaling, men jeg er sikker på at mange fortsatt ikke har aktivert RBAC selv i produksjon, fordi det medfører mye arbeid og mye må settes opp. Likevel oppfordrer jeg til å gjøre det.

https://rbac.dev/ — advokat nettsted for RBAC. Det er samlet en enorm mengde interessante materialer som vil hjelpe deg med å sette opp RBAC, viser hvorfor det er bra og hvordan man generelt lever med det i produksjon.

Jeg skal prøve å forklare hvordan Tiller og RBAC fungerer. Tiller fungerer inne i klyngen under en spesifikk tjenestekonto. Som regel, hvis RBAC ikke er konfigurert, vil dette være superbrukeren. I standardkonfigurasjon vil Tiller være administrator. Derfor sier mange at Tiller er en SSH-tunnel til klyngen din. Det er faktisk slik, så du kan bruke en egen spesialisert tjenestekonto i stedet for Default Service Account som vist i diagrammet ovenfor.

Når du initialiserer Helm, og installerer det for første gang på serveren, kan du angi en tjenestekonto ved hjelp av --service-account. Dette vil tillate bruk av en bruker med det minimum nødvendige settet av rettigheter. Du må imidlertid opprette en slik «girland»: Rolle og Rollebinding.

Dessverre vil ikke Helm gjøre dette for deg. Du eller administratoren din for Kubernetes-klyngen må på forhånd forberede en rekke Rolle, Rollebinding for tjenestekontoen for å gi til Helm.

Det oppstår et spørsmål — hva er forskjellen mellom Rolle og ClusterRole? Forskjellen er at ClusterRole gjelder for alle namespaces, i motsetning til vanlige Rolle og Rollebinding, som kun fungerer for en spesifikk namespace. Du kan konfigurere retningslinjer for hele klyngen og alle namespaces, så vel som personlig for hver namespace individuelt.

Det er verdt å nevne at RBAC også løser et stort problem. Mange klager over at Helm dessverre ikke er multitenancy (støtter ikke multi-leie). Hvis flere team bruker klyngen og bruker Helm, er det i utgangspunktet umulig å konfigurere retningslinjer og avgrense tilgangen deres innenfor denne klyngen, fordi det er en spesifikk tjenestekonto som Helm kjører under, og den oppretter alle ressurser i klyngen under den, noe som noen ganger er svært upraktisk. Dette er faktisk tilfelle — både i den binære filen og i prosessen, Helm Tiller har ikke begrepet multitenancy..

Det finnes derimot en utmerket måte som lar deg kjøre Tiller i klyngen flere ganger. Det er ikke noe problem, Tiller kan kjøres i hver namespace. Dermed kan du bruke RBAC, Kubeconfig som kontekst, og begrense tilgangen til spesifikke Helm.

Det vil se slik ut.

For example, there are two Kubeconfig contexts for different teams (two namespaces): X Team for the development team and the admin cluster. The admin cluster has its own extensive Tiller located within the Kube-system namespace, thus a more advanced service account. There is a separate namespace for the development team where they can deploy their services in a dedicated namespace.

This is a workable approach; Tiller is not so resource-hungry that it could significantly impact your budget. It is one of the quick solutions.

Feel free to configure Tiller separately and provide Kubeconfig with context for the team, for specific developers, or for environments: Dev, Staging, Production (it is doubtful that everything will be on one cluster, however, this is possible).

Continuing our story, let’s switch from RBAC and talk about ConfigMaps.

ConfigMaps

Helm uses ConfigMaps as a data storage. When we discussed the architecture, there was nowhere a database that stored information about releases, configurations, rollbacks, etc. This is handled by ConfigMaps.

The main problem with ConfigMaps is well-known — they are fundamentally insecure, because they cannot store sensitive data. This refers to anything that should not go beyond the service, such as passwords. The most native way for Helm now is to transition from using ConfigMaps to secrets.

This is done very simply. You override the Tiller configuration and specify that the storage will be secrets. Then, for each deployment, you will receive a secret instead of a ConfigMap.

You may argue that secrets themselves are a strange concept, and not very secure. However, it’s important to understand that this is handled by the Kubernetes developers themselves. Since version 1.10, i.e., quite a while ago, it has been possible to connect proper storage for storing secrets, at least in public clouds. The team is currently working on providing even better access to secrets for individual pods or other entities.

It is better to translate Storage Helm to secrets and then secure them centrally.

Of course, there will remain a limit for data storage of 1 MB. Helm bruker etcd som et distribuert lagringssystem for ConfigMaps. Der vurderte de at dette var en passende dataklynge for replikering og slikt. Det er en interessant diskusjon om dette på Reddit, jeg anbefaler å finne denne morsomme lesestoffet til helgen eller lese sammendraget. here.

Chart Repos

Charten er mest sosialt sårbare og kan bli en kilde til «Man in the middle», spesielt hvis en bruker standardløsninger. Først og fremst gjelder dette for depotene som er tilgjengelige via HTTP.

Det er definitivt nødvendig å tilgjengeliggjøre Helm Repo over HTTPS — det er det beste alternativet og koster ikke mye.

Pay attention to mekanisme for signaturer på chartene. Teknologien er utrolig enkel. Det er det samme som du bruker på GitHub, en vanlig PGP-mekanisme med offentlige og private nøkler. Sett det opp, så kan du være sikker, med de nødvendige nøklene, og signere alt slik at det virkelig er ditt chart.

I tillegg, Helm-klienten støtter TLS (ikke i betydningen HTTP fra serveren, men gjensidig TLS). Du kan bruke server- og klientnøkler for å kommunisere. Jeg skal være ærlig, jeg bruker ikke denne mekanismen på grunn av min aversjon mot gjensidige sertifikater. Generelt, chartmuseum — det primære verktøyet for å tilgjengeliggjøre Helm Repo for Helm 2 — støtter også basic auth. Basic auth kan brukes hvis det er enklere og mer betryggende.

Det er også et plugin helm-gcs, som lar deg plassere Chart Repos i Google Cloud Storage. Dette er ganske praktisk, fungerer utmerket og er ganske sikkert, fordi alle beskrevne mekanismer utnyttes.

Hvis du aktiverer HTTPS eller TLS, bruker mTLS og kobler til basic auth for å redusere risikoene ytterligere, får du en sikker kommunikasjonskanal mellom Helm CLI og Chart Repo.

gRPC API

Neste steg er svært ansvarlig — å sikre Tiller, som ligger i klyngen og er, på den ene siden, server, og på den andre siden — selv henvender seg til andre komponenter og prøver å utgi seg for noen andre.

Som jeg allerede har sagt, er Tiller en tjeneste som tilbyr gRPC, Helm-klienten henvender seg til den via gRPC. Som standard er naturligvis TLS deaktivert. Hvorfor dette er gjort er et diskusjonsspørsmål; jeg mener det er for å forenkle konfigurasjonen ved oppstart.

For produksjon og til og med for staging anbefaler jeg å aktivere TLS på gRPC.

Etter mi mening, i motsetning til mTLS for diagrammer, er dette hensiktsmessig og veldig enkelt å gjøre — generer infrastrukturen PQI, opprett et sertifikat, start Tiller, og overfør sertifikatet under initieringen. Deretter kan du utføre alle Helm-kommandoer mens du bruker det genererte sertifikatet og den private nøkkelen.

Dermed vil du beskytte deg mot alle forespørslene til Tiller utenfor klyngen.

Så vi har sikret tilkoblingskanalen til Tiller, allerede diskutert RBAC og justert rettighetene til Kubernetes apiserver, og redusert domenet som den kan samhandle med.

Sikret Helm

La oss se på den endelige skjemaet. Dette er den samme arkitekturen med de samme pilene.

Alle tilkoblinger kan nå trygt tegnes i grønt:

• for Chart Repo bruker vi TLS eller mTLS og basic auth;
• mTLS for Tiller, og det er presentert som en gRPC-tjeneste med TLS, vi bruker sertifikater;
• i klyngen brukes en spesialtjenestekonto med Rolle og RoleBinding. 

Vi har merkbart sikret klyngen, men noen kloke sa:

«Det eneste helt sikre tiltaket er en avstengt datamaskin som står i en betongboks og beskyttes av soldater».

Det finnes forskjellige måter å manipulere data og finne nye angrepsvektorer. Men jeg er sikker på at disse anbefalingene vil gjøre det mulig å oppnå et grunnleggende industrielt sikkerhetsstandard.

Bonus

Denne delen gjelder ikke direkte sikkerhet, men vil også være nyttig. Jeg skal vise noen interessante ting få kjenner til. For eksempel, hvordan man finner diagrammer — offisielle og uoffisielle.

I depotet github.com/helm/charts er det nå omtrent 300 diagrammer og to strømmer: stable og incubator. Den som bidrar, vet godt hvor vanskelig det er å komme fra incubator til stable, og hvor lett det er å bli kastet ut fra stable. Men dette er ikke det beste verktøyet for å finne diagrammer for Prometheus og alt annet du liker, av en enkel grunn — det er ikke en portal der det er lett å søke etter pakker.

Men det finnes en tjeneste hub.helm.sh, som gjør det mye enklere å finne diagrammer. Det viktigste er at det der er mange flere eksterne depoter og nesten 800 diagrammer tilgjengelig. I tillegg kan du koble til ditt eget depot hvis du av en eller annen grunn ikke ønsker å sende diagrammene dine til stable.

Prøv hub.helm.sh og la oss utvikle det sammen. Denne tjenesten er under Helm-prosjektet, og du kan bidra til UI-en hvis du er frontend-utvikler og ønsker å forbedre utseendet.

Jeg vil også trekke oppmerksomheten din til Open Service Broker API-integrasjon. Det høres tungvint og uklart ut, men det løser problemer som alle møter. Jeg forklarer med et enkelt eksempel.

Det finnes en Kubernetes-klynge der vi ønsker å kjøre en klassisk applikasjon — WordPress. Vanligvis, for full funksjonalitet, trenger man en database. Det finnes mange forskjellige løsninger, for eksempel kan man starte sin egen statefull-tjeneste. Dette er ikke veldig praktisk, men mange gjør det.

Andre, som oss i Chainstack, bruker administrerte databaser som MySQL eller PostgreSQL for serverne. Derfor har vi databasen et sted i skyen.

Men det oppstår et problem: vi må koble tjenesten vår til databasen, opprette en database-versjon, overføre legitimasjonene og på en eller annen måte administrere dem. Alt dette gjøres vanligvis manuelt av en systemadministrator eller utvikler. Det er ingen problemer når det er få applikasjoner. Når det er mange, trenger man en samlebånd. Det finnes et slikt samlebånd — det er Service Broker. Den lar deg bruke et spesialplugin til klyngen i offentlig sky og bestille ressurser fra leverandøren via Broker, som om det var et API. For dette kan man bruke Kubernetess sine innebygde verktøy.

Det er veldig enkelt. Man kan for eksempel be om Managed MySQL i Azure med basisnivå (dette kan tilpasses). Ved hjelp av Azure API vil databasen bli opprettet og klargjort for bruk. Du trenger ikke å blande deg inn, det tar pluginen seg av. For eksempel vil OSBA (Azure-pluginen) returnere legitimasjon til tjenesten og sende dette til Helm. Du kan bruke WordPress med skybasert MySQL uten å tenke på administrerte databaser eller bekymre deg for statefull-tjenester internt.

Man kan si at Helm fungerer som limet som på den ene siden lar deg distribuere tjenester, og på den andre siden konsumerer ressurser fra skyleverandører.

Man kan skrive sitt eget plugin og bruke hele denne historien on-premise. Da vil du ha ditt eget plugin til den bedriftsmessige Cloud-leverandøren. Jeg anbefaler å prøve denne tilnærmingen, spesielt hvis du har stor skala og ønsker raskt å sette opp utvikling, staging, eller hele infrastrukturen for en funksjon. Dette vil gjøre livet enklere for driftsteamet eller DevOps.

En annen løsning som jeg allerede har nevnt — er plugin helm-gcs, som lar deg bruke Google-buckets (objektlagring) for å lagre Helm-diagrammer.

Det trengs bare fire kommandoer for å komme i gang:

1. installere plugin-en;
2. initialisere den;
3. angi stien til bucket som ligger i gcp;
4. publisere diagrammer på standard måte.

Fordelen er at den bruker den native metoden gcp for autentisering. Du kan bruke en tjenestekonto, utviklerkonto — hva som helst. Dette er veldig praktisk og koster ingenting i drift. Hvis du, som jeg, fremmer opsless-filosofien, blir dette veldig praktisk, spesielt for små team.

Alternativer

Helm er ikke den eneste løsningen for å administrere tjenester. Det er mange spørsmål rundt det, kanskje derfor kom den tredje versjonen så raskt. Selvfølgelig finnes det alternativer.

Dette kan være både spesialiserte løsninger, som Ksonnet eller Metaparticle. Du kan bruke dine klassiske infrastrukturverktøy (Ansible, Terraform, Chef osv.) for de samme formålene som jeg har omtalt.

Til slutt finnes det løsningen Operator Framework, hvis popularitet øker.

Operator Framework er det viktigste alternativet til Helm som man bør være oppmerksom på.

Det er mer native for CNCF og Kubernetes, men terskelen for å komme i gang er mye høyere, det kreves mer programmering og mindre beskrivelse av manifestasjoner.

Det finnes forskjellige tillegg, som Draft, Scaffold. De letter livet betydelig, for eksempel for utviklere som forenkler syklusen for sending og kjøring av Helm for utrulling av testmiljøer. Jeg ville kalt dem kapasitetsutvidere.

Her er et visuelt diagram som viser hvor ting befinner seg.

På x-aksen er nivået av din personlige kontroll over hendelsene, mens y-aksen viser nivået av nativitet i Kubernetes. Helm versjon 2 ligger omtrent midt imellom. I versjon 3 er forbedringene ikke kolossale, men både kontrollnivået og nivået av nativitet har blitt bedre. Løsninger på nivået av Ksonnet er fortsatt underlegen Helm 2. Men de er vel verdt å se nærmere på for å vite hva annet som finnes i denne verden. Selvfølgelig vil konfigurasjonsbehandleren din være under din kontroll, men det er absolutt ikke native for Kubernetes.

Operator Framework er helt nativ for Kubernetes og gjør det mulig å håndtere det mye mer elegant og grundig (men husk inngangsnivået). Dette passer snarere for spesialiserte applikasjoner og forvaltning av dem, enn en masse kommandopakke for å pakke et stort antall applikasjoner med Helm.

Utvidelser forbedrer bare kontrollen litt, komplimenterer arbeidsflyten eller skjærer hjørner av CI/CD-pipelines.

Fremtiden for Helm

Den gode nyheten er at Helm 3 er på vei. Alpha-versjonen av Helm 3.0.0-alpha.2 er allerede ute, og den kan prøves. Den er relativt stabil, men funksjonaliteten er fortsatt begrenset.

Hvorfor trenger vi Helm 3? Først og fremst handler det om forsvinningen av Tiller, som en komponent. Dette, som du allerede forstår, er et stort skritt fremover, fordi arkitekturens sikkerhet forenkles.

Da Helm 2 ble laget, som var i tiden rundt Kubernetes 1.8 eller tidligere, var mange konsepter umodne. For eksempel er konseptet med CRD nå aktivt implementert, og Helm vil bruke CRD, for å lagre strukturer. Det vil bli mulig å bare bruke klienten og ikke ha serverdelen. Dermed kan du bruke de native Kubernetes-kommandoene for å jobbe med strukturer og ressurser. Dette er et stort skritt fremover.

Det vil komme støtte for native OCI-repositories (Open Container Initiative). Dette er en stor initiativ, og Helm er først og fremst interessert i å plassere sine diagrammer. Det har kommet til det punktet at for eksempel Docker Hub støtter mange OCI-standarder. Jeg vet ikke, men kanskje klassiske Docker-repository-providere vil begynne å gi deg muligheten til å plassere dine Helm-diagrammer.

Diskusjonre om meg er støtte for Lua, som templating motor for å skrive skript. Jeg er ikke stor fan av Lua, men dette vil være en helt valgfri mulighet. Jeg har sjekket dette tre ganger – bruken av Lua vil ikke være obligatorisk. Så de som ønsker å bruke Lua, kan gjøre det, de som liker Go – bli med i vår store leir og bruke go-tmpl for dette.

Endelig det jeg virkelig har savnet – komme med et skjema og validering av datatyper. Det vil ikke lenger være problemer med int eller string, du trenger ikke å omslutte null i doble anførselstegn. Det vil komme en JSON-schema som lar deg beskrive dette tydelig for verdiene.

Det vil bli sterkt redesignet event-drevet modell. Den er allerede konseptuelt beskrevet. Se i Helm 3-tråden, så vil du se hvor mye som er lagt til av hendelser, hooks og annet, som sterkt forenkler og samtidig gir mer kontroll over utplasseringsprosessen og reaksjonene på dem.

Helm 3 vil være enklere, tryggere og mer interessant ikke fordi vi ikke liker Helm 2, men fordi Kubernetes blir mer avansert. Dermed kan Helm dra nytte av Kubernetes' utviklinger og lage utmerkede administrasjonsverktøy for Kubernetes.

En annen god nyhet er at den DevOpsConf Alexander Khayorov vil fortelle, kan containere være sikre? La oss minne om at konferansen om integrering av utviklings-, test- og driftprosesser finner sted i Moskva 30. september og 1. oktober. Innen 20. august er det fortsatt mulig å gi en presentasjon og dele sin erfaring med å løse en av mange utfordringer ved DevOps-tilnærmingen.

For oppdateringer fra konferansen og nyheter, følg med på nyhetsbrevet og telegram-kanalen.

Kilde: habr.com