Firma Amazon o ostatecznej wersji — specjalistycznej dystrybucji do uruchamiania kontenerów i efektywnego zarządzania nimi.
Bottlerocket (nota bene, tak nazywa się małe, ręcznie robione rakiety na proch dymny) — nie jest pierwszym systemem operacyjnym dla kontenerów, ale z dużym prawdopodobieństwem zyska szerokie zastosowanie dzięki domyślnej integracji z usługami AWS. Choć system jest zaprojektowany z myślą o chmurze Amazon, otwarty kod źródłowy pozwala na jego uruchomienie wszędzie: lokalnie na serwerze, na Raspberry Pi, w dowolnej konkurencyjnej chmurze, a nawet w środowisku bez kontenerów.
To całkiem przyzwoita alternatywa dla dystrybucji CoreOS, którą zabiła firma Red Hat.
W rzeczywistości, jednostka Amazon Web Services ma już Amazon Linux, która niedawno doczekała się drugiej wersji: to uniwersalna dystrybucja, którą można uruchomić w kontenerze Docker lub z hipernadzorcami Linux KVM, Microsoft Hyper-V i VMware ESXi. Została zoptymalizowana do pracy w chmurze AWS, ale z wydaniem Bottlerocket wszystkim zaleca się aktualizację do nowego systemu, który jest bezpieczniejszy, nowocześniejszy i zużywa mniej zasobów.
AWS ogłosiło Bottlerocket . Od razu przyznano, że to nie pierwszy „Linux dla kontenerów”, wspominając jako źródła inspiracji CoreOS, Rancher OS i Project Atomic. Programiści napisali, że system operacyjny jest „wynikiem lekcji, które wyciągnęliśmy z długoletniej pracy produkcyjnych usług w skali Amazon oraz z doświadczenia, które zdobyliśmy przez ostatnie sześć lat w uruchamianiu kontenerów”.
Ekstremalny minimalizm
Linux został oczyszczony ze wszystkiego, co nie jest potrzebne do uruchomienia kontenerów. Taki projekt, według firmy, zmniejsza powierzchnię ataku.
Oznacza to, że w podstawowym systemie zainstalowanych jest mniej pakietów, co ułatwia utrzymanie i aktualizację systemu operacyjnego, a także zmniejsza prawdopodobieństwo wystąpienia problemów związanych z zależnościami, a także zmniejsza wykorzystanie zasobów. W zasadzie wszystko działa w oddzielnych kontenerach, a podstawowy system jest praktycznie goły.
Amazon usunęła również wszystkie powłoki i interpretery, aby wyeliminować ryzyko ich użycia lub przypadkowego podniesienia uprawnień przez użytkowników. W podstawowym obrazie, dla minimalizmu i bezpieczeństwa, brak jest powłoki, serwera SSH i języków interpretowanych, takich jak Python. Narzędzia dla administratora zostały przeniesione do oddzielnego kontenera serwisowego, który jest domyślnie wyłączony.
Zarządzanie systemem odbywa się na dwa sposoby: przez API i orkiestrację.
Zamiast menedżera pakietów, który aktualizuje poszczególne części oprogramowania, Bottlerocket pobiera kompletny obraz systemu plików i restartuje się w tym obrazie. W przypadku awarii podczas ładowania automatycznie cofa się, a awaria obciążenia roboczego może zainicjować ręczne wycofanie (polecenie przez API).
Ramowy schemat (The Update Framework) ładował aktualizacje na podstawie obrazów do alternatywnych lub „odmontowanych” partycji. Dla systemu przydzielone są dwie partycje dyskowe, z których jedna zawiera aktywny system, a na drugiej kopiowana jest aktualizacja. Przy tym główna partycja jest montowana w trybie tylko do odczytu, a partycja /etc jest montowana z systemem plików w pamięci operacyjnej i przywraca pierwotny stan po ponownym uruchomieniu. Bezpośrednia zmiana plików konfiguracyjnych w /etc nie jest wspierana: aby zachować ustawienia, należy używać API lub przenosić funkcjonalność do oddzielnych kontenerów.
Schemat aktualizacji przez API
Bezpieczeństwo
Kontenery są tworzone przez standardowe mechanizmy jądra Linux — cgroups, przestrzenie nazw oraz seccomp, a jako system wymuszania kontroli dostępu, czyli dla dodatkowej izolacji, używa się w trybie 'enforcing'.
Domyślnie włączone są polityki dla podziału zasobów między kontenerami a jądrem. Pliki binarne są chronione flagami, aby użytkownicy lub programy nie mogły ich wykonywać. A jeśli ktoś uzyska dostęp do systemu plików, Bottlerocket oferuje narzędzie do weryfikacji i śledzenia wszelkich wprowadzonych zmian.
Tryb 'zweryfikowanego uruchamiania' realizowany jest przez funkcję device-mapper-verity (), która sprawdza integralność głównej partycji podczas uruchamiania. AWS opisuje dm-verity jako „funkcję jądra Linux, zapewniającą weryfikację integralności, aby zapobiec uruchamianiu złośliwego oprogramowania w systemie operacyjnym, takiego jak nadpisywanie podstawowego oprogramowania systemowego.”
W systemie znajduje się także filtr (rozszerzone BPF, ), który umożliwia zastępowanie modułów jądra bezpieczniejszymi programami BPF do niskopoziomowych operacji systemowych.
Model wykonania
Określa użytkownik
Kompilacja
Bezpieczeństwo
Tryb awarii
Dostęp do zasobów
Użytkownik
zadanie
tak
jakakolwiek
prawa użytkowników
przerwanie wykonania
wywołanie systemowe, błąd
Jądro
zadanie
nie
statyczny
nie
panika jądra
bezpośredni
BPF
zdarzenie
tak
JIT, CO-RE
weryfikacja, JIT
wiadomość o błędzie
ograniczone pomocnicy
Różnica między BPF a zwykłym kodem poziomu użytkownika lub jądra,
AWS stwierdziło, że Bottlerocket "stosuje model operacyjny, który jeszcze bardziej zwiększa bezpieczeństwo, uniemożliwiając połączenie z serwerami produkcyjnymi z uprawnieniami administratora" oraz "jest odpowiedni do dużych systemów rozproszonych, w których kontrola nad każdym pojedynczym hostem jest ograniczona."
Dla administratorów systemu przewidziano kontener administratora. Jednak AWS nie uważa, że administratorzy często będą musieli pracować wewnątrz Bottlerocket: "Akcja wejścia do oddzielnej instancji Bottlerocket jest przeznaczona do rzadkich operacji: zaawansowanego debugowania i rozwiązywania problemów", — programiści.
Język Rust
Narzędzia systemu operacyjnego nad jądrem są w głównej mierze napisane w Rust. Ten język z natury , a także .
Podczas kompilacji domyślnie stosowane są flagi --enable-default-pie i --enable-default-ssp w celu włączenia losowości przestrzeni adresowej plików wykonywalnych (, PIE) i ochrony przed przepełnieniem stosu.
Dla pakietów w C/C++ dodatkowo włączane są flagi -Wall, -Werror=format-security, -Wp,-D_FORTIFY_SOURCE=2, -Wp,-D_GLIBCXX_ASSERTIONS i -fstack-clash-protection.
Oprócz Rust i C/C++, niektóre pakiety są napisane w języku Go.
Integracja z usługami AWS
Różnica w porównaniu do podobnych kontenerowych systemów operacyjnych polega na tym, że Amazon zoptymalizował Bottlerocket do pracy na AWS oraz integracji z innymi usługami AWS.
Najpopularniejszym orkiestratorem kontenerów jest Kubernetes, dlatego AWS wprowadziło integrację z własną usługą Enterprise Kubernetes Service (EKS). Narzędzia do orkiestracji znajdują się w oddzielnym kontenerze sterującym , który jest włączony domyślnie i zarządzany przez API oraz AWS SSM Agent.
Ciekawe, czy Bottlerocket odniesie sukces, biorąc pod uwagę porażki niektórych podobnych inicjatyw w przeszłości. Na przykład PhotonOS od Vmware okazało się niepotrzebne, a RedHat przejęło CoreOS i , który uznawano za pioniera w tej dziedzinie.
Integracja Bottlerocket z usługami AWS czyni ten system unikalnym. Możliwe, że to główny powód, dla którego niektórzy użytkownicy mogą preferować Bottlerocket przed innymi dystrybucjami, takimi jak CoreOS czy Alpine. System został początkowo zaprojektowany do pracy z EKS i ECS, ale powtórzmy, że nie jest to konieczne. Po pierwsze, Bottlerocket można użyć na przykład jako rozwiązanie hostingowe. Po drugie, użytkownicy EKS i ECS wciąż będą mieli możliwość wyboru systemu operacyjnego.
Kod źródłowy Bottlerocket został opublikowany na GitHubie na licencji Apache 2.0. Programiści już .
Reklama
VDSina oferując . Można zainstalować dowolny system operacyjny, w tym z własnego obrazu. Każdy serwer jest podłączony do łącza internetowego o prędkości 500 Megabitów i jest bezpłatnie chroniony przed atakami DDoS!
Źródło: habr.com
