Helm Security

Kubernetes-ისთვის ყველაზე პოპულარული პაკეტის მენეჯერის შესახებ სიუჟეტის არსი შეიძლება გამოსახული იყოს emoji-ს გამოყენებით:

• ყუთი არის Helm (რაც ყველაზე ახლოსაა Emoji-ს უახლეს გამოშვებასთან);
• საკეტი - დაცვა;
• პატარა კაცი პრობლემის გადაწყვეტაა.

სინამდვილეში, ყველაფერი ცოტა უფრო გართულდება და სიუჟეტი სავსეა ტექნიკური დეტალებით როგორ გავხადოთ Helm უსაფრთხო.

• მოკლედ რა არის Helm იმ შემთხვევაში თუ არ იცოდით ან დაგავიწყდათ. რა პრობლემებს წყვეტს და სად მდებარეობს ეკოსისტემაში.
• მოდით შევხედოთ Helm არქიტექტურას. არანაირი საუბარი უსაფრთხოებაზე და იმაზე, თუ როგორ გავხადოთ ხელსაწყო ან გადაწყვეტა უფრო უსაფრთხო, არ არის სრულყოფილი კომპონენტის არქიტექტურის გაგების გარეშე.
• მოდით განვიხილოთ Helm კომპონენტები.
• ყველაზე მწვავე კითხვა მომავალია - Helm 3-ის ახალი ვერსია. 

ამ სტატიაში ყველაფერი ეხება Helm 2-ს. ეს ვერსია ამჟამად წარმოების პროცესშია და, სავარაუდოდ, ისაა, რომელსაც ამჟამად იყენებთ, და ეს არის ვერსია, რომელიც შეიცავს უსაფრთხოების რისკებს.

სპიკერის შესახებ: ალექსანდრე ხაიოროვი (ალექს) 10 წელია ვითარდება, რაც ხელს უწყობს კონტენტის გაუმჯობესებას მოსკოვის პითონი Conf++ და შეუერთდა კომიტეტს Helm Summit. ახლა ის მუშაობს Chainstack-ში, როგორც განვითარების ლიდერი - ეს არის ჰიბრიდი განვითარების მენეჯერსა და პირს შორის, რომელიც პასუხისმგებელია საბოლოო რელიზების მიწოდებაზე. ანუ ის მდებარეობს ბრძოლის ველზე, სადაც ყველაფერი ხდება პროდუქტის შექმნიდან მის ექსპლუატაციამდე.

Chainstack არის პატარა, აქტიურად მზარდი სტარტაპი, რომლის მისიაა კლიენტებს საშუალება მისცეს დაივიწყონ დეცენტრალიზებული აპლიკაციების ფუნქციონირების ინფრასტრუქტურა და სირთულეები; განვითარების გუნდი მდებარეობს სინგაპურში. ნუ სთხოვთ Chainstack-ს კრიპტოვალუტის გაყიდვას ან ყიდვას, არამედ შესთავაზეთ ისაუბროთ საწარმოს ბლოკჩეინის ჩარჩოებზე და ისინი სიამოვნებით გიპასუხებენ.

საჭესთან

ეს არის პაკეტის (დიაგრამის) მენეჯერი Kubernetes-ისთვის. ყველაზე ინტუიციური და უნივერსალური გზა აპლიკაციების Kubernetes კლასტერში მიტანისთვის.

ჩვენ, რა თქმა უნდა, ვსაუბრობთ უფრო სტრუქტურულ და ინდუსტრიულ მიდგომაზე, ვიდრე საკუთარი YAML მანიფესტების შექმნა და მცირე კომუნალური საშუალებების დაწერა.

Helm არის საუკეთესო, რაც ამჟამად ხელმისაწვდომი და პოპულარულია.

რატომ Helm? პირველ რიგში იმიტომ, რომ მას მხარს უჭერს CNCF. Cloud Native არის დიდი ორგანიზაცია და არის Kubernetes, etcd, Fluentd და სხვა პროექტების მშობელი კომპანია.

კიდევ ერთი მნიშვნელოვანი ფაქტი ის არის, რომ Helm არის ძალიან პოპულარული პროექტი. როდესაც 2019 წლის იანვარში დავიწყე საუბარი იმაზე, თუ როგორ უნდა გამხდარიყო ჰელმი უსაფრთხო, პროექტს GitHub-ზე ათასი ვარსკვლავი ჰყავდა. მაისისთვის მათგან 12 ათასი იყო.

ბევრი ადამიანი დაინტერესებულია Helm-ით, ასე რომ, მაშინაც კი, თუ ჯერ არ იყენებთ მას, ისარგებლებთ მისი უსაფრთხოების შესახებ ცოდნით. უსაფრთხოება მნიშვნელოვანია.

Helm-ის ძირითადი გუნდი მხარდაჭერილია Microsoft Azure-ის მიერ და, შესაბამისად, საკმაოდ სტაბილური პროექტია, განსხვავებით ბევრი სხვასგან. Helm 3 Alpha 2-ის გამოშვება ივლისის შუა რიცხვებში მიუთითებს იმაზე, რომ პროექტზე საკმაოდ ბევრი ადამიანი მუშაობს და მათ აქვთ სურვილი და ენერგია, განავითარონ და გააუმჯობესონ Helm.

Helm წყვეტს აპლიკაციების მართვის რამდენიმე ძირეულ პრობლემას Kubernetes-ში.

• განაცხადის შეფუთვა. ისეთი აპლიკაციაც კი, როგორიცაა „გამარჯობა, სამყარო“ WordPress-ზე უკვე შედგება რამდენიმე სერვისისგან და გსურთ მათი შეფუთვა.
• ამ აპლიკაციების მართვასთან დაკავშირებული სირთულის მართვა.
• სიცოცხლის ციკლი, რომელიც არ მთავრდება აპლიკაციის დაინსტალირების ან განლაგების შემდეგ. ის აგრძელებს ცხოვრებას, საჭიროებს განახლებას და ჰელმი ეხმარება ამაში და ცდილობს სწორი ზომები და პოლიტიკა გამოიტანოს ამისთვის.

ჩანთები ის ორგანიზებულია მკაფიოდ: არის მეტამონაცემები, რომელიც სრულად შეესაბამება პაკეტის რეგულარული მენეჯერის მუშაობას Linux-ისთვის, Windows-ისთვის ან MacOS-ისთვის. ეს არის საცავი, დამოკიდებულებები სხვადასხვა პაკეტებზე, მეტა ინფორმაცია აპლიკაციებისთვის, პარამეტრები, კონფიგურაციის ფუნქციები, ინფორმაციის ინდექსირება და ა.შ. Helm გაძლევთ საშუალებას მიიღოთ და გამოიყენოთ ეს ყველაფერი აპლიკაციებისთვის.

სირთულის მართვა. თუ თქვენ გაქვთ იგივე ტიპის მრავალი აპლიკაცია, მაშინ საჭიროა პარამეტრიზაცია. შაბლონები აქედან მოდის, მაგრამ იმისათვის, რომ თავიდან აიცილოთ შაბლონების შექმნის საკუთარი გზა, შეგიძლიათ გამოიყენოთ ის, რასაც Helm გთავაზობთ.

აპლიკაციის სასიცოცხლო ციკლის მართვა - ჩემი აზრით, ეს ყველაზე საინტერესო და გადაუჭრელი კითხვაა. სწორედ ამიტომ მოვედი ჰელმში იმ დღეს. ჩვენ გვჭირდებოდა თვალყური ადევნეთ აპლიკაციის სასიცოცხლო ციკლს და გვინდოდა გადაგვეტანა ჩვენი CI/CD და განაცხადის ციკლები ამ პარადიგმაზე.

Helm გაძლევთ საშუალებას:

• განლაგების მართვა, ნერგავს კონფიგურაციისა და გადახედვის კონცეფციას;
• წარმატებით განახორციელოს უკან დაბრუნება;
• გამოიყენეთ კაკვები სხვადასხვა ღონისძიებებისთვის;
• დაამატეთ განაცხადის დამატებითი შემოწმებები და უპასუხეთ მათ შედეგებს.

უფრო მეტიც ჩაფხუტს აქვს "ბატარეები" - დიდი რაოდენობით გემრიელი ნივთები, რომლებიც შეიძლება შევიდეს დანამატების სახით, რაც ამარტივებს თქვენს ცხოვრებას. დანამატები შეიძლება დამოუკიდებლად დაიწეროს, ისინი საკმაოდ იზოლირებულია და არ საჭიროებს ჰარმონიულ არქიტექტურას. თუ გსურთ რაიმეს დანერგვა, გირჩევთ ამის გაკეთებას როგორც მოდულის სახით, შემდეგ კი შესაძლოა ჩართოთ ზემოთ ნაკადში.

Helm ეფუძნება სამ მთავარ კონცეფციას:

• ჩარტ რეპო — თქვენი მანიფესტისთვის შესაძლო პარამეტრიზაციის აღწერა და მასივი. 
• config — ანუ მნიშვნელობები, რომლებიც გამოყენებული იქნება (ტექსტი, რიცხვითი მნიშვნელობები და ა.შ.).
• რელიზი აგროვებს ორ ზედა კომპონენტს და ერთად გადაიქცევა გამოშვებად. გამოშვებები შეიძლება იყოს ვერსიული, რითაც მიიღწევა ორგანიზებული სასიცოცხლო ციკლი: მცირე ინსტალაციის დროს და დიდი განახლების, დაქვეითების ან დაბრუნების დროს.

ჩაფხუტის არქიტექტურა

დიაგრამა კონცეპტუალურად ასახავს ჰელმის მაღალი დონის არქიტექტურას.

შეგახსენებთ, რომ ჰელმი კუბერნეტესთან არის დაკავშირებული. მაშასადამე, ჩვენ არ შეგვიძლია Kubernetes კასეტურის (მართკუთხედის) გარეშე. kube-apiserver კომპონენტი მდებარეობს მასტერზე. Helm-ის გარეშე გვაქვს Kubeconfig. Helm-ს მოაქვს ერთი პატარა ორობითი, თუ შეიძლება ასე დავარქვათ Helm CLI უტილიტა, რომელიც დამონტაჟებულია კომპიუტერზე, ლეპტოპზე, მეინფრემზე - ნებისმიერზე.

მაგრამ ეს საკმარისი არ არის. Helm-ს აქვს სერვერის კომპონენტი, სახელად Tiller. ის წარმოადგენს ჰელმის ინტერესებს კლასტერში; ეს არის აპლიკაცია Kubernetes კლასტერში, ისევე როგორც ნებისმიერი სხვა.

Chart Repo-ს შემდეგი კომპონენტი არის საცავი სქემებით. არსებობს ოფიციალური საცავი და შეიძლება იყოს კომპანიის ან პროექტის კერძო საცავი.

ურთიერთქმედება

მოდით შევხედოთ როგორ ურთიერთქმედებენ არქიტექტურის კომპონენტები, როდესაც გვსურს აპლიკაციის დაყენება Helm-ის გამოყენებით.

• Ჩვენ ვსაუბრობთ Helm install, შედით საცავში (Chart Repo) და მიიღეთ Helm სქემა.

• Helm utility (Helm CLI) ურთიერთქმედებს Kubeconfig-თან, რათა გაარკვიოს რომელ კლასტერს დაუკავშირდეს. 
• ამ ინფორმაციის მიღების შემდეგ, პროგრამა იყენებს Tiller-ს, რომელიც მდებარეობს ჩვენს კლასტერში, როგორც აპლიკაცია. 
• ტილერი უწოდებს Kube-apiserver-ს, რომ შეასრულოს მოქმედებები Kubernetes-ში, შექმნას რამდენიმე ობიექტი (სერვისები, პოდები, რეპლიკა, საიდუმლოებები და ა.შ.).

შემდეგი, ჩვენ გავართულებთ დიაგრამას, რათა დავინახოთ თავდასხმის ვექტორი, რომელსაც მთელი Helm არქიტექტურა შეიძლება ექვემდებარებოდეს. შემდეგ კი ჩვენ შევეცდებით მის დაცვას.

შეტევის ვექტორი

პირველი პოტენციური სუსტი წერტილი არის პრივილეგირებული API-მომხმარებელი. როგორც სქემის ნაწილი, ეს არის ჰაკერი, რომელმაც მოიპოვა ადმინისტრატორის წვდომა Helm CLI-ზე.

არაპრივილეგირებული API მომხმარებელი ასევე შეიძლება საფრთხე შეუქმნას, თუ ის სადმე ახლოს არის. ასეთ მომხმარებელს ექნება განსხვავებული კონტექსტი, მაგალითად, ის შეიძლება დაფიქსირდეს ერთ კლასტერულ სახელთა სივრცეში Kubeconfig პარამეტრებში.

ყველაზე საინტერესო თავდასხმის ვექტორი შეიძლება იყოს პროცესი, რომელიც მდებარეობს კლასტერის შიგნით სადღაც ტილერის მახლობლად და შეუძლია მასზე წვდომა. ეს შეიძლება იყოს ვებ სერვერი ან მიკროსერვისი, რომელიც ხედავს კლასტერის ქსელურ გარემოს.

ეგზოტიკური, მაგრამ სულ უფრო პოპულარული თავდასხმის ვარიანტი მოიცავს Chart Repo-ს. არაკეთილსინდისიერი ავტორის მიერ შექმნილი დიაგრამა შეიძლება შეიცავდეს სახიფათო რესურსებს და თქვენ დაასრულებთ მას რწმენით. ან მას შეუძლია შეცვალოს გრაფიკი, რომელსაც ჩამოტვირთავთ ოფიციალური საცავიდან და, მაგალითად, შექმნას რესურსი პოლიტიკის სახით და გააძლიეროს მისი წვდომა.

შევეცადოთ თავიდან ავიცილოთ თავდასხმები ოთხივე მხრიდან და გავარკვიოთ, სად არის პრობლემები Helm-ის არქიტექტურაში და სად, შესაძლოა, არცერთი.

მოდით გავადიდოთ დიაგრამა, დავამატოთ მეტი ელემენტი, მაგრამ შევინარჩუნოთ ყველა ძირითადი კომპონენტი.

Helm CLI ურთიერთობს Chart Repo-სთან, ურთიერთქმედებს Kubeconfig-თან და ნამუშევარი გადადის კლასტერში Tiller კომპონენტში.

ტილერი წარმოდგენილია ორი ობიექტით:

• Tiller-deploy svc, რომელიც ავლენს გარკვეულ სერვისს;
• Tiller-deploy pod (დიაგრამაში ერთ ეგზემპლარად ერთ რეპლიკაში), რომელზედაც გადის მთელი დატვირთვა, რომელიც წვდება კლასტერს.

ურთიერთქმედებისთვის გამოიყენება სხვადასხვა პროტოკოლები და სქემები. უსაფრთხოების თვალსაზრისით, ჩვენ ყველაზე მეტად გვაინტერესებს:

• მექანიზმი, რომლითაც Helm CLI წვდება ჩარტების რეპოს: რა პროტოკოლი, არის თუ არა ავტორიზაცია და რა შეიძლება გაკეთდეს მასთან.
• პროტოკოლი, რომლითაც Helm CLI, kubectl-ის გამოყენებით, ურთიერთობს ტილერთან. ეს არის RPC სერვერი დაინსტალირებული კლასტერში.
• თავად Tiller არის ხელმისაწვდომი მიკროსერვისებისთვის, რომლებიც ცხოვრობენ კლასტერში და ურთიერთქმედებენ Kube-apiserver-თან.

განვიხილოთ ყველა ეს სფერო თანმიმდევრობით.

RBAC

აზრი არ აქვს Helm-ის ან კლასტერში ნებისმიერი სხვა სერვისის უსაფრთხოებაზე ლაპარაკს, თუ RBAC არ არის ჩართული.

როგორც ჩანს, ეს არ არის უახლესი რეკომენდაცია, მაგრამ დარწმუნებული ვარ, რომ ბევრს ჯერ კიდევ არ აქვს ჩართული RBAC წარმოებაშიც კი, რადგან ის დიდი აურზაურია და ბევრი რამის კონფიგურაციაა საჭირო. თუმცა, მე მოგიწოდებთ ამის გაკეთებას.

https://rbac.dev/ - RBAC-ის ვებსაიტის იურისტი. ის შეიცავს უზარმაზარ რაოდენობას საინტერესო მასალებს, რომლებიც დაგეხმარებათ დააყენოთ RBAC, აჩვენოთ, რატომ არის ის კარგი და როგორ იცხოვროთ ძირითადად წარმოებაში.

შევეცდები აგიხსნათ როგორ მუშაობს Tiller და RBAC. Tiller მუშაობს კლასტერის შიგნით გარკვეული სერვისის ანგარიშის ქვეშ. როგორც წესი, თუ RBAC არ არის კონფიგურირებული, ეს იქნება სუპერმომხმარებელი. ძირითად კონფიგურაციაში Tiller იქნება ადმინისტრატორი. ამიტომ ხშირად ამბობენ, რომ Tiller არის SSH გვირაბი თქვენს კლასტერში. სინამდვილეში, ეს მართალია, ასე რომ თქვენ შეგიძლიათ გამოიყენოთ ცალკე გამოყოფილი სერვისის ანგარიში ზემოთ დიაგრამაში ნაგულისხმევი სერვისის ანგარიშის ნაცვლად.

როდესაც Helm-ის ინიციალიზაციას და სერვერზე პირველად დააინსტალირებთ, შეგიძლიათ სერვისის ანგარიშის გამოყენებით დააყენოთ --service-account. ეს საშუალებას მოგცემთ გამოიყენოთ მომხმარებელი მინიმალური საჭირო უფლებების კომპლექტით. მართალია, თქვენ მოგიწევთ შექმნათ ასეთი "გირლანდი": როლი და როლი.

სამწუხაროდ, ჰელმი ამას შენთვის არ გააკეთებს. თქვენ ან თქვენი Kubernetes კლასტერის ადმინისტრატორმა წინასწარ უნდა მოამზადოთ Roles და RoleBindings კომპლექტი სერვის-ანგარიშისთვის, რათა გაიაროთ Helm.

ჩნდება კითხვა - რა განსხვავებაა Role-სა და ClusterRole-ს შორის? განსხვავება ისაა, რომ ClusterRole მუშაობს ყველა სახელთა სივრცისთვის, განსხვავებით ჩვეულებრივი Roles-ისა და RoleBindings-ისგან, რომლებიც მხოლოდ სპეციალიზებულ სახელთა სივრცისთვის მუშაობს. თქვენ შეგიძლიათ დააკონფიგურიროთ პოლიტიკა მთელი კლასტერისთვის და ყველა სახელთა სივრცისთვის, ან პერსონალიზებული იყოს თითოეული სახელთა სივრცისთვის ინდივიდუალურად.

აღსანიშნავია, რომ RBAC წყვეტს კიდევ ერთ დიდ პრობლემას. ბევრი ადამიანი ჩივის, რომ Helm, სამწუხაროდ, არ არის მრავალბინიანი (მულტიტენანსის მხარდაჭერა არ აქვს). თუ რამდენიმე გუნდი მოიხმარს კლასტერს და გამოიყენებს Helm-ს, ძირითადად შეუძლებელია ამ კლასტერში პოლიტიკის დაყენება და მათი წვდომის შეზღუდვა, რადგან არსებობს გარკვეული სერვისის ანგარიში, რომლითაც Helm მუშაობს და ის ქმნის კლასტერში არსებულ ყველა რესურსს მის ქვეშ. , რაც ზოგჯერ ძალიან მოუხერხებელია. ეს მართალია - როგორც თავად ბინარული ფაილი, ისევე როგორც პროცესი, ჰელმ ტილერს არ აქვს მულტიტენანტობის კონცეფცია.

თუმცა, არსებობს შესანიშნავი გზა, რომელიც საშუალებას გაძლევთ აწარმოოთ Tiller რამდენჯერმე კლასტერში. ამაში პრობლემა არ არის, Tiller შეიძლება გაშვებული იყოს ყველა სახელთა სივრცეში. ამრიგად, შეგიძლიათ გამოიყენოთ RBAC, Kubeconfig, როგორც კონტექსტი და შეზღუდოთ წვდომა სპეციალურ Helm-ზე.

ეს ასე გამოიყურება.

მაგალითად, არსებობს ორი Kubeconfig კონტექსტით სხვადასხვა გუნდისთვის (ორი სახელების სივრცე): X Team განვითარების გუნდისთვის და ადმინისტრაციული კლასტერი. ადმინისტრაციულ კლასტერს აქვს საკუთარი ფართო Tiller, რომელიც მდებარეობს Kube-სისტემის სახელთა სივრცეში, შესაბამისად მოწინავე სერვის-ანგარიში. და ცალკე სახელთა სივრცე დეველოპერული გუნდისთვის, მათ შეეძლებათ განათავსონ თავიანთი სერვისები სპეციალურ სახელთა სივრცეში.

ეს არის გამოსადეგი მიდგომა, Tiller არ არის იმდენად მშიერი, რომ ეს დიდად იმოქმედებს თქვენს ბიუჯეტზე. ეს არის ერთ-ერთი სწრაფი გამოსავალი.

მოგერიდებათ Tiller-ის კონფიგურაცია ცალკე და მიაწოდეთ Kubeconfig-ს კონტექსტი გუნდისთვის, კონკრეტული დეველოპერისთვის ან გარემოსთვის: Dev, Staging, Production (საეჭვოა ყველაფერი ერთ კლასტერზე იყოს, თუმცა ამის გაკეთება შესაძლებელია).

ვაგრძელებთ ჩვენს ისტორიას, გადავიდეთ RBAC-დან და ვისაუბროთ ConfigMaps-ზე.

ConfigMaps

Helm იყენებს ConfigMaps-ს მონაცემთა შესანახად. როდესაც ვსაუბრობდით არქიტექტურაზე, არსად არ არსებობდა მონაცემთა ბაზა, რომელიც ინახავდა ინფორმაციას გამოშვებების, კონფიგურაციების, გადაბრუნებების შესახებ და ა.შ. ამისთვის გამოიყენება ConfigMaps.

ცნობილია ConfigMaps-ის მთავარი პრობლემა - ისინი პრინციპში სახიფათოა; შეუძლებელია მგრძნობიარე მონაცემების შენახვა. ჩვენ ვსაუბრობთ ყველაფერზე, რაც არ უნდა გასცდეს სერვისს, მაგალითად, პაროლებს. Helm-ის ყველაზე მშობლიური გზა ახლა არის ConfigMaps-ის გამოყენებით საიდუმლოებაზე გადასვლა.

ეს კეთდება ძალიან მარტივად. გააუქმეთ Tiller პარამეტრი და მიუთითეთ, რომ შენახვა საიდუმლო იქნება. შემდეგ ყოველი განლაგებისთვის თქვენ მიიღებთ არა ConfigMap-ს, არამედ საიდუმლოს.

შეიძლება ამტკიცებდეთ, რომ საიდუმლოებები თავისთავად უცნაური ცნებაა და არც თუ ისე უსაფრთხო. თუმცა, ღირს იმის გაგება, რომ ამას თავად Kubernetes-ის დეველოპერები აკეთებენ. 1.10 ვერსიიდან დაწყებული, ე.ი. უკვე საკმაოდ დიდი ხანია, შესაძლებელია, ყოველ შემთხვევაში, საჯარო ღრუბლებში, საიდუმლოების შესანახად სწორი შენახვის დაკავშირება. გუნდი ახლა მუშაობს გზებზე, რათა უკეთ გავრცელდეს წვდომა საიდუმლოებებზე, ინდივიდუალურ პოდებზე ან სხვა ობიექტებზე.

უმჯობესია Storage Helm გადაიტანოთ საიდუმლოებამდე და ისინი, თავის მხრივ, დაცულია ცენტრალურად.

რა თქმა უნდა დარჩება მონაცემთა შენახვის ლიმიტი 1 მბ. Helm აქ იყენებს etcd-ს, როგორც განაწილებულ საცავს ConfigMaps-ისთვის. და იქ მათ ჩათვალეს, რომ ეს იყო მონაცემთა შესაფერისი ნაწილი რეპლიკაციისთვის და ა.შ. ამაზე საინტერესო დისკუსია მიმდინარეობს Reddit-ზე, გირჩევთ იპოვოთ ეს მხიარული წაკითხული შაბათ-კვირისთვის ან წაიკითხოთ ამონაწერი აქ.

ჩარტ რეპო

დიაგრამები ყველაზე სოციალურად დაუცველია და შეიძლება გახდეს „ადამიანი შუაში“ წყარო, განსაკუთრებით თუ იყენებთ საფონდო გადაწყვეტას. უპირველეს ყოვლისა, ჩვენ ვსაუბრობთ საცავებზე, რომლებიც ექვემდებარება HTTP-ს.

თქვენ აუცილებლად უნდა გაამჟღავნოთ Helm Repo HTTPS-ით - ეს საუკეთესო ვარიანტია და იაფია.

შენიშვნა გრაფიკის ხელმოწერის მექანიზმი. ტექნოლოგია ჯოჯოხეთად მარტივია. ეს არის იგივე, რასაც იყენებთ GitHub-ზე, ჩვეულებრივ PGP აპარატზე საჯარო და პირადი გასაღებებით. დააყენეთ და დარწმუნდით, რომ გქონდეთ საჭირო გასაღებები და ხელი მოაწეროთ ყველაფერს, რომ ეს ნამდვილად თქვენი სქემაა.

გარდა ამისა, Helm კლიენტი მხარს უჭერს TLS (არა სერვერის მხარეს HTTP გაგებით, არამედ ორმხრივი TLS). თქვენ შეგიძლიათ გამოიყენოთ სერვერის და კლიენტის კლავიშები კომუნიკაციისთვის. მართალი გითხრათ, მე არ ვიყენებ ასეთ მექანიზმს, რადგან არ მიყვარს ორმხრივი სერთიფიკატები. ძირითადად, ჩარტმუზეუმი - Helm Repo-ის დაყენების მთავარი ინსტრუმენტი Helm 2-ისთვის - ასევე მხარს უჭერს ძირითად ავტორიზაციას. შეგიძლიათ გამოიყენოთ ძირითადი ავტორიზაცია, თუ ეს უფრო მოსახერხებელი და მშვიდია.

ასევე არის მოდული საჭე-გცს, რომელიც საშუალებას გაძლევთ მართოთ Chart Repos Google Cloud Storage-ზე. ეს საკმაოდ მოსახერხებელია, მუშაობს შესანიშნავად და საკმაოდ უსაფრთხოა, რადგან ყველა აღწერილი მექანიზმი გადამუშავებულია.

თუ ჩართავთ HTTPS ან TLS-ს, იყენებთ mTLS-ს და ჩართავთ ძირითად ავტორიზაციას რისკების შემდგომი შესამცირებლად, თქვენ მიიღებთ უსაფრთხო საკომუნიკაციო არხს Helm CLI-ით და Chart Repo-ით.

gRPC API

შემდეგი ნაბიჯი ძალიან მნიშვნელოვანია - Tiller-ის დაცვა, რომელიც მდებარეობს კლასტერში და არის, ერთი მხრივ, სერვერი, მეორეს მხრივ, ის თავად წვდება სხვა კომპონენტებს და ცდილობს თავი მოაჩვენოს ვინმეს.

როგორც უკვე ვთქვი, Tiller არის სერვისი, რომელიც ავლენს gRPC-ს, Helm კლიენტი მასზე მოდის gRPC-ის მეშვეობით. ნაგულისხმევად, რა თქმა უნდა, TLS გამორთულია. რატომ გაკეთდა ეს სადავო საკითხია, მეჩვენება, რომ თავიდანვე ინსტალაცია გავამარტივეთ.

წარმოებისთვის და თუნდაც დადგმისთვის, გირჩევთ, ჩართოთ TLS gRPC-ზე.

ჩემი აზრით, სქემებისთვის mTLS-ისგან განსხვავებით, ეს აქ მიზანშეწონილია და კეთდება ძალიან მარტივად - შექმენით PQI ინფრასტრუქტურა, შექმენით სერტიფიკატი, გაუშვით Tiller, გადაიტანეთ სერთიფიკატი ინიციალიზაციის დროს. ამის შემდეგ, თქვენ შეგიძლიათ შეასრულოთ Helm-ის ყველა ბრძანება, წარმოადგინოთ გენერირებული სერტიფიკატი და პირადი გასაღები.

ამ გზით თქვენ დაიცავთ თავს ყველა თხოვნისაგან Tiller-ის მიმართ კლასტერის გარედან.

ასე რომ, ჩვენ დავიცვათ კავშირის არხი Tiller-თან, ჩვენ უკვე განვიხილეთ RBAC და მოვარგეთ Kubernetes აპისერვერის უფლებები, შევამცირეთ დომენი, რომელთანაც მას შეუძლია ურთიერთქმედება.

დაცული ჩაფხუტი

მოდით შევხედოთ საბოლოო დიაგრამას. ეს არის იგივე არქიტექტურა იგივე ისრებით.

ყველა კავშირი ახლა უსაფრთხოდ შეიძლება დახატოს მწვანეში:

• Chart Repo-სთვის ჩვენ ვიყენებთ TLS ან mTLS და ძირითადი ავტორიზაცია;
• mTLS Tiller-ისთვის და ის გამოქვეყნებულია როგორც gRPC სერვისი TLS-ით, ჩვენ ვიყენებთ სერთიფიკატებს;
• კლასტერი იყენებს სპეციალურ სერვის ანგარიშს Role და RoleBinding. 

ჩვენ მნიშვნელოვნად დავიცავით კლასტერი, მაგრამ ვიღაც ჭკვიანმა თქვა:

"არსებობს მხოლოდ ერთი აბსოლუტურად უსაფრთხო გამოსავალი - გამორთული კომპიუტერი, რომელიც მოთავსებულია ბეტონის ყუთში და მას ჯარისკაცები იცავენ."

მონაცემების მანიპულირებისა და ახალი თავდასხმის ვექტორების პოვნის სხვადასხვა გზა არსებობს. თუმცა, დარწმუნებული ვარ, რომ ეს რეკომენდაციები მიაღწევს უსაფრთხოების ძირითად ინდუსტრიულ სტანდარტს.

ბონუს

ეს ნაწილი პირდაპირ არ არის დაკავშირებული უსაფრთხოებასთან, მაგრამ ასევე სასარგებლო იქნება. მე გაჩვენებთ რამდენიმე საინტერესო რამეს, რომლის შესახებაც ცოტამ თუ იცის. მაგალითად, როგორ მოძებნოთ სქემები - ოფიციალური და არაოფიციალური.

საცავში github.com/helm/charts ახლა დაახლოებით 300 სქემა და ორი ნაკადია: სტაბილური და ინკუბატორი. ვინც წვლილს შეიტანს, მშვენივრად იცის, რა ძნელია ინკუბატორიდან თავლაში მოხვედრა და რამდენად ადვილია საჯინიბოდან გაფრენა. თუმცა, ეს არ არის საუკეთესო ინსტრუმენტი პრომეთესა და რაც მოგწონთ სქემების მოსაძებნად, ერთი მარტივი მიზეზის გამო - ეს არ არის პორტალი, სადაც შეგიძლიათ მოხერხებულად მოძებნოთ პაკეტები.

მაგრამ არის სერვისი hub.helm.sh, რაც ბევრად უფრო მოსახერხებელს ხდის სქემების პოვნას. რაც მთავარია, კიდევ ბევრი გარე საცავი და თითქმის 800 ხიბლია ხელმისაწვდომი. გარდა ამისა, შეგიძლიათ დააკავშიროთ თქვენი საცავი, თუ რაიმე მიზეზით არ გსურთ თქვენი სქემების გაგზავნა სტაბილურად.

სცადეთ hub.helm.sh და მოდით ერთად განვავითაროთ. ეს სერვისი Helm პროექტის ფარგლებშია და თქვენ შეგიძლიათ წვლილი შეიტანოთ მის ინტერფეისში, თუ თქვენ ხართ წინა დეველოპერი და უბრალოდ გსურთ გარეგნობის გაუმჯობესება.

ასევე მინდა თქვენი ყურადღება გავამახვილო გახსენით სერვის ბროკერის API ინტეგრაცია. ეს უხერხულად და გაურკვეველად ჟღერს, მაგრამ ის წყვეტს პრობლემებს, რომლებიც ყველას აწყდება. ნება მომეცით ავხსნა მარტივი მაგალითით.

არის Kubernetes კლასტერი, რომელშიც გვინდა გავატაროთ კლასიკური აპლიკაცია – WordPress. ზოგადად, სრული ფუნქციონირებისთვის საჭიროა მონაცემთა ბაზა. არსებობს მრავალი განსხვავებული გადაწყვეტილება, მაგალითად, შეგიძლიათ გაუშვათ თქვენი საკუთარი სახელმწიფო სერვისი. ეს არ არის ძალიან მოსახერხებელი, მაგრამ ბევრი ადამიანი ამას აკეთებს.

სხვები, ისევე როგორც ჩვენ Chainstack-ში, იყენებენ მართულ მონაცემთა ბაზებს, როგორიცაა MySQL ან PostgreSQL თავიანთი სერვერებისთვის. ამიტომ ჩვენი მონაცემთა ბაზები მდებარეობს სადღაც ღრუბელში.

მაგრამ ჩნდება პრობლემა: ჩვენ უნდა დავაკავშიროთ ჩვენი სერვისი მონაცემთა ბაზასთან, შევქმნათ მონაცემთა ბაზის არომატი, გადავიტანოთ რწმუნებათა სიგელები და როგორმე ვმართოთ იგი. ეს ყველაფერი ჩვეულებრივ კეთდება ხელით სისტემის ადმინისტრატორის ან დეველოპერის მიერ. და არ არის პრობლემა, როდესაც რამდენიმე აპლიკაციაა. როდესაც ბევრი მათგანია, საჭიროა კომბაინი. არის ასეთი კომბაინი - ეს არის სერვის ბროკერი. ის საშუალებას გაძლევთ გამოიყენოთ სპეციალური დანამატი საჯარო ღრუბლოვანი კლასტერისთვის და შეუკვეთოთ რესურსები პროვაიდერისგან ბროკერის საშუალებით, თითქოს ეს იყოს API. ამისათვის შეგიძლიათ გამოიყენოთ მშობლიური Kubernetes ინსტრუმენტები.

ძალიან მარტივია. თქვენ შეგიძლიათ მოითხოვოთ, მაგალითად, Managed MySQL Azure-ში საბაზისო ფენით (ამის კონფიგურაცია შესაძლებელია). Azure API-ს გამოყენებით შეიქმნება მონაცემთა ბაზა და მომზადდება გამოსაყენებლად. თქვენ არ გჭირდებათ ამაში ჩარევა, ამაზე პასუხისმგებელია მოდული. მაგალითად, OSBA (Azure plugin) დააბრუნებს რწმუნებათა სიგელებს სერვისს და გადასცემს მას Helm-ს. თქვენ შეძლებთ გამოიყენოთ WordPress ღრუბლოვანი MySQL-ით, საერთოდ არ გაუმკლავდეთ მართულ მონაცემთა ბაზებს და არ ინერვიულოთ შიგნით სახელმწიფო სერვისებზე.

შეიძლება ითქვას, რომ Helm მოქმედებს როგორც წებო, რომელიც, ერთი მხრივ, საშუალებას გაძლევთ განათავსოთ სერვისები, ხოლო მეორეს მხრივ, მოიხმაროთ ღრუბლოვანი პროვაიდერების რესურსები.

შეგიძლიათ დაწეროთ თქვენი საკუთარი მოდული და გამოიყენოთ მთელი ეს ამბავი ადგილზე. მაშინ თქვენ უბრალოდ გექნებათ თქვენი საკუთარი მოდული კორპორატიული Cloud პროვაიდერისთვის. გირჩევთ სცადოთ ეს მიდგომა, განსაკუთრებით თუ გაქვთ დიდი მასშტაბი და გსურთ სწრაფად განათავსოთ დეველოპმენტი, დადგმა ან მთელი ინფრასტრუქტურა ფუნქციისთვის. ეს გაამარტივებს თქვენს ოპერაციებს ან DevOps-ს.

კიდევ ერთი აღმოჩენა, რომელიც უკვე აღვნიშნე, არის helm-gcs მოდული, რომელიც საშუალებას გაძლევთ გამოიყენოთ Google-buckets (ობიექტების საცავი) Helm-ის სქემების შესანახად.

მისი გამოყენების დასაწყებად საჭიროა მხოლოდ ოთხი ბრძანება:

1. დააინსტალირეთ დანამატი;
2. წამოიწყო იგი;
3. დააყენეთ ბილიკი თაიგულისკენ, რომელიც მდებარეობს gcp-ში;
4. გამოაქვეყნეთ სქემები სტანდარტული გზით.

სილამაზე ის არის, რომ ავტორიზაციისთვის გამოყენებული იქნება მშობლიური gcp მეთოდი. შეგიძლიათ გამოიყენოთ სერვისის ანგარიში, დეველოპერის ანგარიში, რაც გინდათ. ძალიან მოსახერხებელია და ფუნქციონირება არ ღირს. თუ თქვენ, ისევე როგორც მე, ხელს უწყობთ უსუსურ ფილოსოფიას, მაშინ ეს ძალიან მოსახერხებელი იქნება, განსაკუთრებით მცირე გუნდებისთვის.

ალტერნატივები

Helm არ არის ერთადერთი სერვისის მართვის გადაწყვეტა. მასზე ბევრი კითხვაა, ალბათ ამიტომაც გამოჩნდა მესამე ვერსია ასე სწრაფად. რა თქმა უნდა, არსებობს ალტერნატივები.

ეს შეიძლება იყოს სპეციალიზებული გადაწყვეტილებები, მაგალითად, Ksonnet ან Metaparticle. თქვენ შეგიძლიათ გამოიყენოთ თქვენი კლასიკური ინფრასტრუქტურის მართვის ინსტრუმენტები (Ansible, Terraform, Chef და ა.შ.) იმავე მიზნებისთვის, რაზეც მე ვისაუბრე.

საბოლოოდ არის გამოსავალი ოპერატორის ჩარჩო, რომლის პოპულარობაც იზრდება.

ოპერატორის ჩარჩო არის მთავარი ალტერნატივა, რომელიც გასათვალისწინებელია.

ის უფრო მშობლიურია CNCF-სა და Kubernetes-ში, მაგრამ შესვლის ბარიერი გაცილებით მაღალია, საჭიროა მეტი დაპროგრამება და ნაკლები მანიფესტების აღწერა.

არსებობს სხვადასხვა დამატებები, როგორიცაა Draft, Scaffold. ისინი ბევრად აადვილებენ ცხოვრებას, მაგალითად, ამარტივებს Helm-ის გაგზავნისა და გაშვების ციკლს დეველოპერებისთვის, რათა განათავსონ სატესტო გარემო. მე მათ გაძლიერებულებს დავარქმევდი.

აქ არის ვიზუალური სქემა, სადაც ყველაფერია.

x-ღერძზე არის თქვენი პირადი კონტროლის დონე იმაზე, რაც ხდება, y-ღერძზე არის კუბერნეტის მშობლიურობის დონე. Helm ვერსია 2 მოდის სადღაც შუაში. მე-3 ვერსიაში, არა უზომოდ, მაგრამ გაუმჯობესებულია კონტროლიც და ბუნებრიობის დონეც. Ksonnet-ის დონეზე გადაწყვეტილებები ჯერ კიდევ ჩამოუვარდება Helm 2-ს. თუმცა, ღირს მათი ნახვა იმის გასაგებად, თუ რა არის ამ სამყაროში. რა თქმა უნდა, თქვენი კონფიგურაციის მენეჯერი იქნება თქვენი კონტროლის ქვეშ, მაგრამ ის აბსოლუტურად არ არის კუბერნეტის მშობლიური.

Operator Framework აბსოლუტურად მშობლიურია Kubernetes-ისთვის და გაძლევთ საშუალებას მართოთ იგი ბევრად უფრო ელეგანტურად და სკრუპულოზურად (მაგრამ გახსოვდეთ შესვლის დონე). უფრო მეტიც, ეს შესაფერისია სპეციალიზებული აპლიკაციისთვის და მისთვის მენეჯმენტის შესაქმნელად, ვიდრე მასიური მოსავლის აღჭურვილობის შესაფუთი აპლიკაციების დიდი რაოდენობით Helm-ის გამოყენებით.

ექსტენდერები უბრალოდ ოდნავ აუმჯობესებენ კონტროლს, ავსებენ სამუშაო პროცესს ან ჭრიან კუთხეებს CI/CD მილსადენებზე.

ჰელმის მომავალი

კარგი ამბავი ის არის, რომ Helm 3 მოდის. Helm 3.0.0-alpha.2-ის ალფა ვერსია უკვე გამოვიდა, შეგიძლიათ სცადოთ. ის საკმაოდ სტაბილურია, მაგრამ ფუნქციონირება მაინც შეზღუდულია.

რატომ გჭირდებათ Helm 3? პირველ რიგში, ეს არის ამბავი ტილერის გაუჩინარება, როგორც კომპონენტი. ეს, როგორც უკვე გესმით, უზარმაზარი წინგადადგმული ნაბიჯია, რადგან არქიტექტურის უსაფრთხოების თვალსაზრისით, ყველაფერი გამარტივებულია.

როდესაც Helm 2 შეიქმნა, რომელიც დაახლოებით Kubernetes 1.8-ის ან უფრო ადრე იყო, ბევრი კონცეფცია გაუაზრებელი იყო. მაგალითად, CRD კონცეფცია ახლა აქტიურად განხორციელდება და Helm ამას გააკეთებს გამოიყენეთ CRDსტრუქტურების შესანახად. შესაძლებელი იქნება მხოლოდ კლიენტის გამოყენება და არა სერვერის ნაწილის შენარჩუნება. შესაბამისად, გამოიყენეთ მშობლიური Kubernetes ბრძანებები სტრუქტურებთან და რესურსებთან მუშაობისთვის. ეს არის უზარმაზარი წინგადადგმული ნაბიჯი.

Გამოჩნდება მშობლიური OCI საცავების მხარდაჭერა (Open Container Initiative). ეს არის უზარმაზარი ინიციატივა და ჰელმი დაინტერესებულია, პირველ რიგში, თავისი ჩარტების გამოქვეყნების მიზნით. საქმე იქამდე მიდის, რომ, მაგალითად, Docker Hub მხარს უჭერს ბევრ OCI სტანდარტს. მე არ ვხვდები, მაგრამ, შესაძლოა, კლასიკური Docker საცავების პროვაიდერები მოგცენ შესაძლებლობას ჰქონდეთ მათი Helm სქემები.

ჩემთვის საკამათო ამბავია ლუას მხარდაჭერა, როგორც შაბლონის ძრავა სკრიპტების დასაწერად. მე არ ვარ ლუას დიდი გულშემატკივარი, მაგრამ ეს სრულიად არჩევითი ფუნქცია იქნება. ეს 3-ჯერ გადავამოწმე - ლუას გამოყენება არ იქნება საჭირო. ამიტომ, ვისაც სურს ლუას გამოყენება, ვისაც Go მოსწონს, შემოუერთდით ჩვენს უზარმაზარ ბანაკს და ამისათვის გამოიყენეთ go-tmpl.

საბოლოოდ, ის, რაც მე ნამდვილად მაკლდა იყო სქემის გაჩენა და მონაცემთა ტიპის დადასტურება. აღარ იქნება პრობლემები int-თან ან სტრიქონთან დაკავშირებით, არ არის საჭირო ნულის გადატანა ორმაგ ბრჭყალებში. გამოჩნდება JSONS სქემა, რომელიც საშუალებას მოგცემთ ნათლად აღწეროთ ეს მნიშვნელობებისთვის.

მძიმედ გადამუშავდება მოვლენებზე ორიენტირებული მოდელი. ეს უკვე კონცეპტუალურად არის აღწერილი. შეხედეთ Helm 3-ის ფილიალს და ნახავთ, რამდენი მოვლენა, კაკვები და სხვა რამ დაემატა, რაც მნიშვნელოვნად გაამარტივებს და, მეორე მხრივ, დაამატებს კონტროლს განლაგების პროცესებზე და მათზე რეაქციებზე.

Helm 3 იქნება უფრო მარტივი, უსაფრთხო და უფრო სახალისო, არა იმიტომ, რომ ჩვენ არ მოგვწონს Helm 2, არამედ იმიტომ, რომ Kubernetes უფრო მოწინავე ხდება. შესაბამისად, ჰელმს შეუძლია გამოიყენოს Kubernetes-ის განვითარება და შექმნას მასზე Kubernetes-ისთვის შესანიშნავი მენეჯერები.

კიდევ ერთი კარგი ამბავი ის არის DevOpsConf ალექსანდრე ხაიოროვი გეტყვით, შეიძლება კონტეინერები იყოს უსაფრთხო? შეგახსენებთ, რომ კონფერენცია განვითარების, ტესტირებისა და ექსპლუატაციის პროცესების ინტეგრაციის შესახებ მოსკოვში გაიმართება 30 სექტემბერს და 1 ოქტომბერს. ამის გაკეთება შეგიძლიათ 20 აგვისტომდე ანგარიშის წარდგენა და გვითხარით თქვენი გამოცდილების შესახებ გადაწყვეტის შესახებ ერთ-ერთი მრავალი DevOps მიდგომის ამოცანები.

მიჰყევით კონფერენციის საგუშაგოებს და სიახლეებს მისამართზე საფოსტო სია и ტელეგრამის არხი.

წყარო: www.habr.com