Gellid darlunio hanfod y stori am y rheolwr pecyn mwyaf poblogaidd ar gyfer Kubernetes gan ddefnyddio emoji:
- y blwch yw Helm (sef y peth agosaf at y datganiad Emoji diweddaraf);
- lock - diogelwch;
- y dyn bach yw'r ateb i'r broblem.
Yn wir, bydd popeth ychydig yn fwy cymhleth, ac mae'r stori'n llawn manylion technegol am Sut i wneud Helm yn ddiogel.
- Yn gryno beth yw Helm rhag ofn nad oeddech chi'n gwybod neu wedi anghofio. Pa broblemau y mae'n eu datrys a ble mae wedi'i leoli yn yr ecosystem.
- Gadewch i ni edrych ar bensaernïaeth Helm. Nid oes unrhyw sgwrs am ddiogelwch a sut i wneud offeryn neu ddatrysiad yn fwy diogel yn gyflawn heb ddeall pensaernïaeth y gydran.
- Gadewch i ni drafod cydrannau Helm.
- Y cwestiwn mwyaf llosg yw'r dyfodol - y fersiwn newydd o Helm 3.
Mae popeth yn yr erthygl hon yn berthnasol i Helm 2. Mae'r fersiwn hon yn cael ei chynhyrchu ar hyn o bryd ac mae'n fwyaf tebygol yr un rydych chi'n ei ddefnyddio ar hyn o bryd, a dyma'r fersiwn sy'n cynnwys y risgiau diogelwch.
Am y siaradwr: Alexander Khayorov () wedi bod yn datblygu ers 10 mlynedd, gan helpu i wella cynnwys ac ymunodd â'r pwyllgor . Nawr mae'n gweithio yn Chainstack fel arweinydd datblygu - mae hwn yn hybrid rhwng rheolwr datblygu a pherson sy'n gyfrifol am ddarparu datganiadau terfynol. Hynny yw, mae wedi'i leoli ar faes y gad, lle mae popeth yn digwydd o greu cynnyrch i'w weithrediad.
Mae Chainstack yn gwmni cychwyn bach sy'n tyfu'n weithredol a'i genhadaeth yw galluogi cleientiaid i anghofio am seilwaith a chymhlethdodau gweithredu cymwysiadau datganoledig; mae'r tîm datblygu wedi'i leoli yn Singapore. Peidiwch â gofyn i Chainstack werthu neu brynu cryptocurrency, ond cynigiwch siarad am fframweithiau blockchain menter, a byddant yn hapus i'ch ateb.
Helm
Mae hwn yn rheolwr pecyn (siart) ar gyfer Kubernetes. Y ffordd fwyaf greddfol a chyffredinol o ddod â chymwysiadau i glwstwr Kubernetes.
Rydym, wrth gwrs, yn sôn am ddull mwy strwythurol a diwydiannol na chreu eich maniffestau YAML eich hun ac ysgrifennu cyfleustodau bach.
Helm yw'r gorau sydd ar gael ar hyn o bryd ac sy'n boblogaidd.
Pam Helm? Yn bennaf oherwydd ei fod yn cael ei gefnogi gan y CNCF. Mae Cloud Native yn sefydliad mawr a dyma'r rhiant-gwmni ar gyfer prosiectau Kubernetes, etcd, Fluentd ac eraill.
Ffaith bwysig arall yw bod Helm yn brosiect poblogaidd iawn. Pan ddechreuais siarad am sut i wneud Helm yn ddiogel ym mis Ionawr 2019, roedd gan y prosiect fil o sêr ar GitHub. Erbyn mis Mai roedd 12 mil ohonyn nhw.
Mae gan lawer o bobl ddiddordeb yn Helm, felly hyd yn oed os nad ydych chi'n ei ddefnyddio eto, byddwch chi'n elwa o wybod am ei ddiogelwch. Mae diogelwch yn bwysig.
Cefnogir tîm craidd Helm gan Microsoft Azure ac felly mae'n brosiect eithaf sefydlog, yn wahanol i lawer o rai eraill. Mae rhyddhau Helm 3 Alpha 2 yng nghanol mis Gorffennaf yn dangos bod cryn dipyn o bobl yn gweithio ar y prosiect, ac mae ganddyn nhw'r awydd a'r egni i ddatblygu a gwella Helm.
Mae Helm yn datrys nifer o broblemau sylfaenol rheoli cymwysiadau yn Kubernetes.
- Pecynnu cais. Mae hyd yn oed cymhwysiad fel “Helo, Byd” ar WordPress eisoes yn cynnwys sawl gwasanaeth, ac rydych chi am eu pecynnu gyda'i gilydd.
- Rheoli'r cymhlethdod a ddaw gyda rheoli'r cymwysiadau hyn.
- Cylch bywyd nad yw'n dod i ben ar ôl i'r cymhwysiad gael ei osod neu ei ddefnyddio. Mae’n parhau i fyw, mae angen ei ddiweddaru, ac mae Helm yn helpu gyda hyn ac yn ceisio dod â’r mesurau a’r polisïau cywir ar gyfer hyn.
Bagio mae wedi'i drefnu mewn ffordd glir: mae metadata yn gwbl unol â gwaith rheolwr pecynnau rheolaidd ar gyfer Linux, Windows neu MacOS. Hynny yw, ystorfa, dibyniaethau ar becynnau amrywiol, gwybodaeth meta ar gyfer cymwysiadau, gosodiadau, nodweddion cyfluniad, mynegeio gwybodaeth, ac ati Mae Helm yn caniatáu ichi gael a defnyddio hyn i gyd ar gyfer cymwysiadau.
Rheoli Cymhlethdod. Os oes gennych lawer o gymwysiadau o'r un math, yna mae angen paramedroli. Daw templedi o hyn, ond er mwyn osgoi gorfod meddwl am eich ffordd eich hun o greu templedi, gallwch ddefnyddio'r hyn y mae Helm yn ei gynnig allan o'r bocs.
Rheoli Cylch Bywyd Cymhwysiad - yn fy marn i, dyma'r cwestiwn mwyaf diddorol a heb ei ddatrys. Dyma pam y deuthum i Helm yn ôl yn y dydd. Roedd angen i ni gadw llygad ar gylch oes y cymhwysiad ac roeddem am symud ein cylchoedd CI/CD a chymhwyso i'r patrwm hwn.
Mae Helm yn caniatáu ichi:
- rheoli gosodiadau, cyflwyno'r cysyniad o gyfluniad ac adolygu;
- cyflawni dychwelyd yn llwyddiannus;
- defnyddio bachau ar gyfer gwahanol ddigwyddiadau;
- ychwanegu gwiriadau cais ychwanegol ac ymateb i'w canlyniadau.
Ar ben hynny Mae gan Helm “batris” - nifer enfawr o bethau blasus y gellir eu cynnwys ar ffurf ategion, gan symleiddio'ch bywyd. Gellir ysgrifennu ategion yn annibynnol, maent yn eithaf ynysig ac nid oes angen pensaernïaeth gytûn arnynt. Os ydych chi am weithredu rhywbeth, rwy'n argymell ei wneud fel ategyn, ac yna o bosibl ei gynnwys i fyny'r afon.
Mae Helm yn seiliedig ar dri phrif gysyniad:
- Siart Repo - disgrifiad ac amrywiaeth o baramedrau posibl ar gyfer eich maniffest.
- config —hynny yw, y gwerthoedd a fydd yn cael eu cymhwyso (testun, gwerthoedd rhifol, ac ati).
- Rhyddhau yn casglu y ddwy gydran uchaf, a gyda'i gilydd maent yn troi yn Rhyddhau. Gellir fersiwnio datganiadau, a thrwy hynny gyflawni cylch bywyd trefnus: bach ar adeg gosod a mawr ar adeg uwchraddio, israddio neu ddychwelyd.
Pensaernïaeth Helm
Mae'r diagram yn ddarlun cysyniadol o bensaernïaeth lefel uchel Helm.
Gadewch imi eich atgoffa bod Helm yn rhywbeth sy'n gysylltiedig â Kubernetes. Felly, ni allwn wneud heb glwstwr Kubernetes (petryal). Mae'r gydran kube-apiserver yn byw ar y meistr. Heb Helm mae gennym Kubeconfig. Helm yn dod ag un deuaidd bach, os gallwch chi ei alw'n hynny, Helm CLI cyfleustodau, sy'n cael ei osod ar gyfrifiadur, gliniadur, prif ffrâm - ar unrhyw beth.
Ond nid yw hyn yn ddigon. Mae gan Helm gydran gweinydd o'r enw Tiller. Mae'n cynrychioli buddiannau Helm o fewn y clwstwr; mae'n gais o fewn clwstwr Kubernetes, yn union fel unrhyw un arall.
Ystorfa gyda siartiau yw cydran nesaf Chart Repo. Mae yna gadwrfa swyddogol, a gall fod storfa breifat o gwmni neu brosiect.
Rhyngweithio
Gadewch i ni edrych ar sut mae'r cydrannau pensaernïaeth yn rhyngweithio pan fyddwn am osod cymhwysiad gan ddefnyddio Helm.
- Rydyn ni'n siarad
Helm install, cyrchwch yr ystorfa (Chart Repo) a chael siart Helm.
- Mae cyfleustodau Helm (Helm CLI) yn rhyngweithio â Kubeconfig er mwyn darganfod pa glwstwr i gysylltu ag ef.
- Ar ôl derbyn y wybodaeth hon, mae'r cyfleustodau'n cyfeirio at Tiller, sydd wedi'i leoli yn ein clwstwr, fel cais.
- Mae Tiller yn galw Kube-apiserver i berfformio gweithredoedd yn Kubernetes, creu rhai gwrthrychau (gwasanaethau, codennau, replicas, cyfrinachau, ac ati).
Nesaf, byddwn yn cymhlethu'r diagram i weld y fector ymosodiad y gall pensaernïaeth Helm gyfan fod yn agored iddo. Ac yna byddwn yn ceisio ei hamddiffyn.
Fector ymosodiad
Y pwynt gwan posibl cyntaf yw API breintiedig-y defnyddiwr. Fel rhan o'r cynllun, mae hwn yn haciwr sydd wedi cael mynediad gweinyddol i Helm CLI.
Defnyddiwr API di-freintiedig gall hefyd achosi perygl os yw rhywle gerllaw. Bydd gan ddefnyddiwr o'r fath gyd-destun gwahanol, er enghraifft, gellir ei osod mewn gofod enw clwstwr yn y gosodiadau Kubeconfig.
Efallai mai'r fector ymosodiad mwyaf diddorol yw proses sy'n byw o fewn clwstwr yn rhywle ger Tiller ac yn gallu cael mynediad iddo. Gall hwn fod yn weinydd gwe neu'n ficrowasanaeth sy'n gweld amgylchedd rhwydwaith y clwstwr.
Mae amrywiad ymosodiad egsotig, ond cynyddol boblogaidd, yn cynnwys Chart Repo. Gall siart a grëwyd gan awdur diegwyddor gynnwys adnoddau anniogel, a byddwch yn ei gwblhau trwy ei gymryd ar ffydd. Neu gall ddisodli'r siart rydych chi'n ei lawrlwytho o'r gadwrfa swyddogol ac, er enghraifft, creu adnodd ar ffurf polisïau a chynyddu ei fynediad.
Gadewch i ni geisio atal ymosodiadau o'r pedair ochr hyn a darganfod lle mae problemau ym mhensaernïaeth Helm, a lle, efallai, nad oes rhai.
Gadewch i ni ehangu'r diagram, ychwanegu mwy o elfennau, ond cadw'r holl gydrannau sylfaenol.
Mae'r Helm CLI yn cyfathrebu â'r Chart Repo, yn rhyngweithio â Kubeconfig, ac mae'r gwaith yn cael ei drosglwyddo i'r clwstwr i gydran Tiller.
Cynrychiolir Tiller gan ddau wrthrych:
- Tiller-deploy svc, sy'n amlygu gwasanaeth penodol;
- Cod tiller-defnyddio (yn y diagram mewn copi sengl mewn un replica), y mae'r llwyth cyfan yn rhedeg arno, sy'n cyrchu'r clwstwr.
Defnyddir gwahanol brotocolau a chynlluniau ar gyfer rhyngweithio. O safbwynt diogelwch, mae gennym fwyaf o ddiddordeb mewn:
- Y mecanwaith y mae Helm CLI yn ei ddefnyddio i gael mynediad at repo'r siart: pa brotocol, a oes dilysu a beth ellir ei wneud ag ef.
- Y protocol y mae Helm CLI, gan ddefnyddio kubectl, yn cyfathrebu â Tiller. Mae hwn yn weinydd RPC wedi'i osod y tu mewn i'r clwstwr.
- Mae Tiller ei hun yn hygyrch i ficrowasanaethau sy'n byw yn y clwstwr ac yn rhyngweithio â'r Kube-apiserver.
Gadewch i ni drafod yr holl feysydd hyn mewn trefn.
RBAC
Nid oes diben siarad am unrhyw sicrwydd i Helm nac unrhyw wasanaeth arall o fewn y clwstwr oni bai bod RBAC wedi'i alluogi.
Mae'n ymddangos nad dyma'r argymhelliad diweddaraf, ond rwy'n siŵr nad yw llawer o bobl wedi galluogi RBAC hyd yn oed wrth gynhyrchu, oherwydd mae'n llawer o ffwdan ac mae angen ffurfweddu llawer o bethau. Fodd bynnag, fe’ch anogaf i wneud hyn.
— cyfreithiwr gwefan ar gyfer RBAC. Mae'n cynnwys llawer iawn o ddeunyddiau diddorol a fydd yn eich helpu i sefydlu RBAC, dangos pam ei fod yn dda a sut i fyw ag ef yn y bôn wrth gynhyrchu.
Byddaf yn ceisio esbonio sut mae Tiller a RBAC yn gweithio. Mae Tiller yn gweithio y tu mewn i'r clwstwr o dan gyfrif gwasanaeth penodol. Yn nodweddiadol, os nad yw RBAC wedi'i ffurfweddu, hwn fydd y superuser. Yn y cyfluniad sylfaenol, bydd Tiller yn weinyddwr. Dyna pam y dywedir yn aml mai twnnel SSH i'ch clwstwr yw Tiller. Mewn gwirionedd, mae hyn yn wir, felly gallwch ddefnyddio cyfrif gwasanaeth pwrpasol ar wahân yn lle'r Cyfrif Gwasanaeth Diofyn yn y diagram uchod.
Pan fyddwch chi'n cychwyn Helm a'i osod ar y gweinydd am y tro cyntaf, gallwch chi osod y cyfrif gwasanaeth gan ddefnyddio --service-account. Bydd hyn yn caniatáu ichi ddefnyddio defnyddiwr sydd â'r set lleiaf o hawliau gofynnol. Yn wir, bydd yn rhaid i chi greu “garland” o'r fath: Rōl a Rhwymo Rôl.
Yn anffodus, ni fydd Helm yn gwneud hyn i chi. Mae angen i chi neu'ch gweinyddwr clwstwr Kubernetes baratoi set o Rolau a Rwymedigaethau ar gyfer y cyfrif gwasanaeth ymlaen llaw er mwyn pasio Helm.
Mae'r cwestiwn yn codi - beth yw'r gwahaniaeth rhwng Rôl a Rôl Clwstwr? Y gwahaniaeth yw bod ClusterRole yn gweithio ar gyfer pob gofod enw, yn wahanol i Roles a RoleBindings rheolaidd, sydd ond yn gweithio i ofod enw arbenigol. Gallwch chi ffurfweddu polisïau ar gyfer y clwstwr cyfan a phob gofod enw, neu eu personoli ar gyfer pob gofod enw yn unigol.
Mae'n werth nodi bod RBAC yn datrys problem fawr arall. Mae llawer o bobl yn cwyno nad yw Helm, yn anffodus, yn aml-denantiaeth (nid yw'n cefnogi aml-denantiaeth). Os bydd sawl tîm yn defnyddio clwstwr ac yn defnyddio Helm, yn y bôn mae’n amhosibl sefydlu polisïau a chyfyngu ar eu mynediad o fewn y clwstwr hwn, oherwydd mae yna gyfrif gwasanaeth penodol y mae Helm yn rhedeg oddi tano, ac mae’n creu’r holl adnoddau yn y clwstwr oddi tano. , sydd weithiau'n anghyfleus iawn. Mae hyn yn wir - fel y ffeil ddeuaidd ei hun, fel y broses, Nid oes gan Helm Tiller unrhyw gysyniad o amlddaliadaeth.
Fodd bynnag, mae yna ffordd wych sy'n eich galluogi i redeg Tiller sawl gwaith mewn clwstwr. Nid oes problem gyda hyn, gellir lansio Tiller ym mhob gofod enw. Felly, gallwch ddefnyddio RBAC, Kubeconfig fel cyd-destun, a chyfyngu mynediad i Helm arbennig.
Bydd yn edrych fel hyn.
Er enghraifft, mae dau Kubeconfigs gyda chyd-destun ar gyfer gwahanol dimau (dau ofod enw): Tîm X ar gyfer y tîm datblygu a'r clwstwr gweinyddol. Mae gan y clwstwr gweinyddol ei Tiller eang ei hun, sydd wedi'i leoli yn y gofod enw system Kube, cyfrif gwasanaeth datblygedig cyfatebol. A gofod enw ar wahân ar gyfer y tîm datblygu, byddant yn gallu defnyddio eu gwasanaethau i ofod enwau arbennig.
Mae hwn yn ddull ymarferol, nid yw Tiller mor newynog am bŵer y bydd yn effeithio'n fawr ar eich cyllideb. Dyma un o'r atebion cyflym.
Mae croeso i chi ffurfweddu Tiller ar wahân a darparu cyd-destun i Kubeconfig ar gyfer y tîm, ar gyfer datblygwr penodol neu ar gyfer yr amgylchedd: Dev, Llwyfannu, Cynhyrchu (mae'n amheus y bydd popeth ar yr un clwstwr, fodd bynnag, gellir gwneud hyn).
Gan barhau â'n stori, gadewch i ni newid o RBAC a siarad am ConfigMaps.
Mapiau Ffurfwedd
Mae Helm yn defnyddio ConfigMaps fel ei storfa ddata. Pan siaradom am bensaernïaeth, nid oedd cronfa ddata yn unman a fyddai'n storio gwybodaeth am ddatganiadau, ffurfweddiadau, dychweliadau, ac ati. Defnyddir ConfigMaps ar gyfer hyn.
Mae'r brif broblem gyda ConfigMaps yn hysbys - maent yn anniogel mewn egwyddor; mae'n amhosibl storio data sensitif. Yr ydym yn sôn am bopeth na ddylai fynd y tu hwnt i’r gwasanaeth, er enghraifft, cyfrineiriau. Y ffordd fwyaf brodorol i Helm ar hyn o bryd yw newid o ddefnyddio ConfigMaps i gyfrinachau.
Gwneir hyn yn syml iawn. Diystyru'r gosodiad Tiller a nodi y bydd y storfa yn gyfrinachau. Yna ar gyfer pob defnydd byddwch yn derbyn nid ConfigMap, ond yn gyfrinach.
Gallech ddadlau bod cyfrinachau eu hunain yn gysyniad rhyfedd ac nid yn ddiogel iawn. Fodd bynnag, mae'n werth deall bod datblygwyr Kubernetes eu hunain yn gwneud hyn. Gan ddechrau o fersiwn 1.10, h.y. Ers cryn amser bellach, mae wedi bod yn bosibl, mewn cymylau cyhoeddus o leiaf, i gysylltu'r storfa gywir i storio cyfrinachau. Mae'r tîm bellach yn gweithio ar ffyrdd o ddosbarthu mynediad at gyfrinachau, codennau unigol, neu endidau eraill yn well.
Mae'n well trosglwyddo Helm Storio i gyfrinachau, ac maent, yn eu tro, yn cael eu sicrhau'n ganolog.
Wrth gwrs bydd yn parhau terfyn storio data o 1 MB. Mae Helm yma yn defnyddio ac ati fel storfa ddosbarthedig ar gyfer ConfigMaps. Ac yno roeddent o'r farn bod hwn yn dalp data addas ar gyfer atgynhyrchu, ac ati. Mae trafodaeth ddiddorol am hyn ar Reddit, rwy'n argymell dod o hyd i'r darlleniad doniol hwn ar gyfer y penwythnos neu ddarllen y dyfyniad .
Siart Repos
Siartiau yw'r rhai mwyaf agored i niwed yn gymdeithasol a gallant ddod yn ffynhonnell “Dyn yn y canol”, yn enwedig os ydych chi'n defnyddio datrysiad stoc. Yn gyntaf oll, rydym yn sôn am ystorfeydd sy'n cael eu hamlygu trwy HTTP.
Yn bendant mae angen i chi ddatgelu Helm Repo dros HTTPS - dyma'r opsiwn gorau ac mae'n rhad.
Rhowch sylw i mecanwaith llofnod siart. Mae'r dechnoleg yn syml ag uffern. Dyma'r un peth rydych chi'n ei ddefnyddio ar GitHub, peiriant PGP rheolaidd gydag allweddi cyhoeddus a phreifat. Gosodwch a gwnewch yn siŵr, gyda'r allweddi angenrheidiol a llofnodi popeth, mai dyma'ch siart mewn gwirionedd.
Yn ogystal, Mae cleient Helm yn cefnogi TLS (nid yn yr ystyr HTTP ochr y gweinydd, ond TLS cydfuddiannol). Gallwch ddefnyddio allweddi gweinydd a chleient er mwyn cyfathrebu. A bod yn onest, nid wyf yn defnyddio mecanwaith o'r fath oherwydd nid wyf yn hoffi tystysgrifau cydfuddiannol. Yn y bôn, - y prif offeryn ar gyfer sefydlu Helm Repo ar gyfer Helm 2 - hefyd yn cefnogi awdur sylfaenol. Gallwch ddefnyddio awdit sylfaenol os yw'n fwy cyfleus ac yn dawelach.
Mae yna hefyd ategyn , sy'n eich galluogi i gynnal Chart Repos ar Google Cloud Storage. Mae hyn yn eithaf cyfleus, yn gweithio'n wych ac yn eithaf diogel, oherwydd bod yr holl fecanweithiau a ddisgrifir yn cael eu hailgylchu.
Os ydych chi'n galluogi HTTPS neu TLS, defnyddiwch mTLS, a galluogi auth sylfaenol i leihau risgiau ymhellach, fe gewch sianel gyfathrebu ddiogel gyda Helm CLI a Chart Repo.
gRPC API
Mae'r cam nesaf yn bwysig iawn - i sicrhau Tiller, sydd wedi'i leoli yn y clwstwr ac sydd, ar y naill law, yn weinydd, ar y llaw arall, ei hun yn cyrchu cydrannau eraill ac yn ceisio esgus bod yn rhywun.
Fel y dywedais eisoes, mae Tiller yn wasanaeth sy'n datgelu gRPC, mae cleient Helm yn dod ato trwy gRPC. Yn ddiofyn, wrth gwrs, mae TLS wedi'i analluogi. Mae pam y gwnaed hyn yn gwestiwn dadleuol, mae'n ymddangos i mi ei fod yn symleiddio'r gosodiad ar y dechrau.
Ar gyfer cynhyrchu a hyd yn oed llwyfannu, rwy'n argymell galluogi TLS ar gRPC.
Yn fy marn i, yn wahanol i mTLS ar gyfer siartiau, mae hyn yn briodol yma ac yn cael ei wneud yn syml iawn - cynhyrchu seilwaith PQI, creu tystysgrif, lansio Tiller, trosglwyddo'r dystysgrif yn ystod ymgychwyn. Ar ôl hyn, gallwch chi weithredu'r holl orchmynion Helm, gan gyflwyno'r dystysgrif a gynhyrchir a'r allwedd breifat i chi'ch hun.
Fel hyn byddwch yn amddiffyn eich hun rhag pob cais i Tiller o'r tu allan i'r clwstwr.
Felly, rydym wedi sicrhau'r sianel gysylltiad â Tiller, rydym eisoes wedi trafod RBAC ac wedi addasu hawliau'r apiserver Kubernetes, gan leihau'r parth y gall ryngweithio ag ef.
Helm Gwarchodedig
Edrychwn ar y diagram terfynol. Yr un bensaernïaeth ydyw gyda'r un saethau.
Bellach gellir gwneud pob cysylltiad yn ddiogel mewn gwyrdd:
- ar gyfer Chart Repo rydym yn defnyddio TLS neu mTLS ac awdur sylfaenol;
- mTLS ar gyfer Tiller, ac mae'n agored fel gwasanaeth gRPC gyda TLS, rydym yn defnyddio tystysgrifau;
- mae'r clwstwr yn defnyddio cyfrif gwasanaeth arbennig gyda Role and RoleBinding.
Rydym wedi sicrhau’r clwstwr yn sylweddol, ond dywedodd rhywun smart:
“Dim ond un ateb cwbl ddiogel all fod – cyfrifiadur wedi’i ddiffodd, sydd wedi’i leoli mewn blwch concrit ac sy’n cael ei warchod gan filwyr.”
Mae yna wahanol ffyrdd o drin data a dod o hyd i fectorau ymosodiad newydd. Fodd bynnag, yr wyf yn hyderus y bydd yr argymhellion hyn yn cyrraedd safon diwydiant sylfaenol ar gyfer diogelwch.
Bonws
Nid yw'r rhan hon yn uniongyrchol gysylltiedig â diogelwch, ond bydd hefyd yn ddefnyddiol. Byddaf yn dangos rhai pethau diddorol i chi nad oes llawer o bobl yn gwybod amdanynt. Er enghraifft, sut i chwilio am siartiau - swyddogol ac answyddogol.
Yn yr ystorfa Nawr mae tua 300 o siartiau a dwy ffrwd: sefydlog a deorydd. Mae unrhyw un sy'n cyfrannu yn gwybod yn iawn pa mor anodd yw hi i fynd o ddeorydd i stabl, a pha mor hawdd yw hedfan allan o stabl. Fodd bynnag, nid dyma'r offeryn gorau i chwilio am siartiau ar gyfer Prometheus a beth bynnag arall y dymunwch, am un rheswm syml - nid yw'n borth lle gallwch chwilio'n gyfleus am becynnau.
Ond mae yna wasanaeth , sy'n ei gwneud hi'n llawer mwy cyfleus dod o hyd i siartiau. Yn bwysicaf oll, mae llawer mwy o ystorfeydd allanol a bron i 800 o swyn ar gael. Hefyd, gallwch chi gysylltu'ch ystorfa os nad ydych chi am anfon eich siartiau i sefydlog am ryw reswm.
Rhowch gynnig ar hub.helm.sh a gadewch i ni ei ddatblygu gyda'n gilydd. Mae'r gwasanaeth hwn o dan brosiect Helm, a gallwch hyd yn oed gyfrannu at ei UI os ydych chi'n ddatblygwr pen blaen a dim ond eisiau gwella'r ymddangosiad.
Hoffwn hefyd dynnu eich sylw at Integreiddio API Brocer Gwasanaeth Agored. Mae'n swnio'n feichus ac yn aneglur, ond mae'n datrys problemau y mae pawb yn eu hwynebu. Gadewch imi egluro gydag enghraifft syml.
Mae yna glwstwr Kubernetes lle rydyn ni am redeg cymhwysiad clasurol - WordPress. Yn gyffredinol, mae angen cronfa ddata ar gyfer ymarferoldeb llawn. Mae yna lawer o wahanol atebion, er enghraifft, gallwch chi lansio'ch gwasanaeth gwladwriaethol eich hun. Nid yw hyn yn gyfleus iawn, ond mae llawer o bobl yn ei wneud.
Mae eraill, fel ni yn Chainstack, yn defnyddio cronfeydd data a reolir fel MySQL neu PostgreSQL ar gyfer eu gweinyddwyr. Dyna pam mae ein cronfeydd data wedi'u lleoli rhywle yn y cwmwl.
Ond mae problem yn codi: mae angen i ni gysylltu ein gwasanaeth â chronfa ddata, creu blas cronfa ddata, trosglwyddo'r cymhwyster a'i reoli rywsut. Mae hyn i gyd fel arfer yn cael ei wneud â llaw gan weinyddwr y system neu'r datblygwr. Ac nid oes problem pan nad oes llawer o geisiadau. Pan fo llawer ohonyn nhw, mae angen cyfuniad arnoch chi. Mae cynaeafwr o'r fath - mae'n Brocer Gwasanaeth. Mae'n caniatáu ichi ddefnyddio ategyn arbennig ar gyfer clwstwr cwmwl cyhoeddus ac archebu adnoddau gan y darparwr trwy Broker, fel pe bai'n API. I wneud hyn, gallwch ddefnyddio offer Kubernetes brodorol.
Mae'n syml iawn. Gallwch chi ymholi, er enghraifft, MySQL a Reolir yn Azure gyda haen sylfaenol (gellir ffurfweddu hyn). Gan ddefnyddio'r API Azure, bydd y gronfa ddata yn cael ei chreu a'i pharatoi i'w defnyddio. Nid oes angen i chi ymyrryd â hyn, yr ategyn sy'n gyfrifol am hyn. Er enghraifft, bydd OSBA (ategyn Azure) yn dychwelyd credential i'r gwasanaeth ac yn ei drosglwyddo i Helm. Byddwch yn gallu defnyddio WordPress gyda MySQL cwmwl, peidio â delio â chronfeydd data a reolir o gwbl a pheidio â phoeni am wasanaethau wladwriaethol y tu mewn.
Gallwn ddweud bod Helm yn gweithredu fel glud sydd, ar y naill law, yn caniatáu ichi ddefnyddio gwasanaethau, ac ar y llaw arall, defnyddio adnoddau darparwyr cwmwl.
Gallwch chi ysgrifennu eich ategyn eich hun a defnyddio'r stori gyfan hon yn y fan a'r lle. Yna yn syml bydd gennych eich ategyn eich hun ar gyfer y darparwr Cloud corfforaethol. Rwy'n argymell rhoi cynnig ar y dull hwn, yn enwedig os oes gennych chi raddfa fawr ac eisiau defnyddio dev, llwyfannu, neu'r seilwaith cyfan yn gyflym ar gyfer nodwedd. Bydd hyn yn gwneud bywyd yn haws i'ch gweithrediadau neu DevOps.
Darganfyddiad arall y soniais amdano eisoes yw ategyn helm-gcs, sy'n eich galluogi i ddefnyddio bwcedi Google (storio gwrthrychau) i storio siartiau Helm.
Dim ond pedwar gorchymyn sydd eu hangen arnoch i ddechrau ei ddefnyddio:
- gosod yr ategyn;
- ei gychwyn;
- gosodwch y llwybr i'r bwced, sydd wedi'i leoli yn gcp;
- cyhoeddi siartiau yn y ffordd safonol.
Y harddwch yw y bydd y dull gcp brodorol yn cael ei ddefnyddio ar gyfer awdurdodi. Gallwch ddefnyddio cyfrif gwasanaeth, cyfrif datblygwr, beth bynnag y dymunwch. Mae'n gyfleus iawn ac nid yw'n costio dim i'w weithredu. Os ydych chi, fel fi, yn hyrwyddo'r athroniaeth opsless, yna bydd hyn yn gyfleus iawn, yn enwedig ar gyfer timau bach.
Dewisiadau amgen
Nid Helm yw'r unig ateb rheoli gwasanaeth. Mae yna lawer o gwestiynau amdano, ac mae'n debyg mai dyna pam yr ymddangosodd y trydydd fersiwn mor gyflym. Wrth gwrs mae yna ddewisiadau eraill.
Gall y rhain fod yn atebion arbenigol, er enghraifft, Ksonnet neu Metaparticle. Gallwch ddefnyddio'ch offer rheoli seilwaith clasurol (Ansible, Terraform, Chef, ac ati) at yr un dibenion ag y soniais amdanynt.
Yn olaf mae yna ateb , y mae ei boblogrwydd yn tyfu.
Fframwaith Gweithredwyr yw'r dewis amgen gorau i Helm ei ystyried.
Mae'n fwy brodorol i CNCF a Kubernetes, ond y mae y rhwystr i fynediad yn llawer uwch, mae angen i chi raglennu mwy a disgrifio maniffestau llai.
Mae yna amryw o ychwanegion, megis Drafft, Sgaffald. Maent yn gwneud bywyd yn llawer haws, er enghraifft, maent yn symleiddio'r cylch o anfon a lansio Helm i ddatblygwyr ddefnyddio amgylchedd prawf. Byddwn yn eu galw yn rymuswyr.
Dyma siart gweledol o ble mae popeth.
Ar yr echelin-x mae lefel eich rheolaeth bersonol dros yr hyn sy'n digwydd, ar yr echelin-y mae lefel brodorol Kubernetes. Mae fersiwn Helm 2 yn disgyn rhywle yn y canol. Yn fersiwn 3, nid yn aruthrol, ond mae rheolaeth a lefel y brodorol wedi gwella. Mae datrysiadau ar lefel Ksonnet yn dal i fod yn israddol hyd yn oed i Helm 2. Fodd bynnag, mae'n werth edrych arnynt i wybod beth arall sydd yn y byd hwn. Wrth gwrs, bydd eich rheolwr cyfluniad o dan eich rheolaeth, ond nid yw'n frodorol o gwbl i Kubernetes.
Mae'r Fframwaith Gweithredwyr yn gwbl frodorol i Kubernetes ac mae'n caniatáu ichi ei reoli'n llawer mwy cain a chraff (ond cofiwch am y lefel mynediad). Yn hytrach, mae hyn yn addas ar gyfer cais arbenigol a chreu rheolaeth ar ei gyfer, yn hytrach na chynaeafwr màs ar gyfer pecynnu nifer fawr o gymwysiadau gan ddefnyddio Helm.
Yn syml, mae estynwyr yn gwella rheolaeth ychydig, yn ategu llif gwaith, neu'n torri corneli ar biblinellau CI / CD.
Dyfodol Helm
Y newyddion da yw bod Helm 3 yn dod. Mae'r fersiwn alffa o Helm 3.0.0-alpha.2 eisoes wedi'i ryddhau, gallwch chi roi cynnig arni. Mae'n eithaf sefydlog, ond mae ymarferoldeb yn gyfyngedig o hyd.
Pam mae angen Helm 3 arnoch chi? Yn gyntaf oll, mae hon yn stori am diflaniad Tiller, fel cydran. Mae hyn, fel y deallwch eisoes, yn gam enfawr ymlaen, oherwydd o safbwynt diogelwch y bensaernïaeth, mae popeth wedi'i symleiddio.
Pan grëwyd Helm 2, a oedd o gwmpas amser Kubernetes 1.8 neu hyd yn oed yn gynharach, roedd llawer o'r cysyniadau yn anaeddfed. Er enghraifft, mae cysyniad CRD bellach yn cael ei roi ar waith yn weithredol, a bydd Helm yn gwneud hynny defnyddio CRDi storio strwythurau. Bydd yn bosibl defnyddio'r cleient yn unig a pheidio â chynnal rhan y gweinydd. Yn unol â hynny, defnyddiwch orchmynion Kubernetes brodorol i weithio gyda strwythurau ac adnoddau. Mae hwn yn gam enfawr ymlaen.
Bydd yn ymddangos cefnogaeth i gadwrfeydd OCI brodorol (Menter Cynhwysydd Agored). Mae hon yn fenter enfawr, ac mae gan Helm ddiddordeb yn bennaf mewn postio ei siartiau. Daw i'r pwynt, er enghraifft, bod Docker Hub yn cefnogi llawer o safonau OCI. Dydw i ddim yn dyfalu, ond efallai y bydd darparwyr ystorfa Docker clasurol yn dechrau rhoi cyfle i chi gynnal eich siartiau Helm.
Y stori ddadleuol i mi yw cefnogaeth Lua, fel peiriant templedi ar gyfer ysgrifennu sgriptiau. Dydw i ddim yn ffan mawr o Lua, ond byddai hyn yn nodwedd gwbl ddewisol. Fe wnes i wirio hyn 3 gwaith - ni fydd angen defnyddio Lua. Felly, mae'r rhai sydd am allu defnyddio Lua, y rhai sy'n hoffi Go, yn ymuno â'n gwersyll enfawr ac yn defnyddio go-tmpl ar gyfer hyn.
Yn olaf, yr hyn yr oeddwn yn bendant ar goll oedd ymddangosiad sgema a dilysu math o ddata. Ni fydd mwy o broblemau gydag int na llinyn, nid oes angen lapio sero mewn dyfynbrisiau dwbl. Bydd sgema JSONS yn ymddangos a fydd yn caniatáu ichi ddisgrifio hyn yn benodol ar gyfer gwerthoedd.
Bydd yn cael ei ail-weithio'n drwm model a yrrir gan ddigwyddiad. Mae eisoes wedi'i ddisgrifio'n gysyniadol. Edrychwch ar gangen Helm 3, a byddwch yn gweld faint o ddigwyddiadau a bachau a phethau eraill sydd wedi'u hychwanegu, a fydd yn symleiddio'n fawr ac, ar y llaw arall, yn ychwanegu rheolaeth dros y prosesau lleoli a'r ymatebion iddynt.
Bydd Helm 3 yn symlach, yn fwy diogel, ac yn fwy o hwyl, nid oherwydd nad ydym yn hoffi Helm 2, ond oherwydd bod Kubernetes yn dod yn fwy datblygedig. Yn unol â hynny, gall Helm ddefnyddio datblygiadau Kubernetes a chreu rheolwyr rhagorol ar gyfer Kubernetes arno.
Newyddion da arall yw hynny Bydd Alexander Khayorov yn dweud wrthych chi, Gadewch inni eich atgoffa y cynhelir y gynhadledd ar integreiddio prosesau datblygu, profi a gweithredu ym Moscow Medi 30 a Hydref 1. Gallwch chi ei wneud o hyd tan 20 Awst a dywedwch wrthym am eich profiad gyda'r datrysiad tasgau dull DevOps.
Dilynwch bwyntiau gwirio cynhadledd a newyddion yn и .
Ffynhonnell: hab.com