რატომ არის პრივილეგირებული რეჟიმი უფრო ფართო, ვიდრე VPN-ს სჭირდება

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

რას ცვლის დროშა სინამდვილეში

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

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

შეუსაბამეთ ყოველი შეცდომა ერთ წინაპირობას

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

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

შეამოწმეთ მოთხოვნა და არა სიმპტომი

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

ls -l /dev/net/tun
docker run --rm --cap-add NET_ADMIN --device /dev/net/tun image:tag
ip -br link show type tun

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

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

ჩაწერეთ ყველაზე ვიწრო მომუშავე ნებართვა

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

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