AuthZ& AuthN - Docker Access Authorization Plugin
Model autoryzacji Docker'a "out-of-the-box" to "wszystko albo nic". Każdy użytkownik mający uprawnienia dostępu do demona Docker może uruchamiać dowolne polecenia klienta Docker. To samo dotyczy wywołań korzystających z interfejsu API silnika Docker do kontaktu z demonem. Jeśli wymagasz większej kontroli dostępu, możesz tworzyć wtyczki autoryzacji i dodawać je do konfiguracji demona Docker. Dzięki wtyczce autoryzacji administrator Docker'a może konfigurować szczegółowe polityki dostępu do zarządzania dostępem do demona Docker.
Podstawowa architektura
Wtyczki autoryzacji Docker są zewnętrznymi wtyczkami, które można używać do zezwolenia/odmowy działań żądanych przez demona Docker, w zależności od użytkownika, który je żąda, i działania żądanego.
Następujące informacje pochodzą z dokumentacji
Kiedy żądanie HTTP jest przesyłane do demona Docker przez CLI lub za pośrednictwem interfejsu API silnika, podsystem autoryzacji przekazuje żądanie zainstalowanym wtyczkom autoryzacji. Żądanie zawiera użytkownika (wywołującego) i kontekst polecenia. Wtyczka jest odpowiedzialna za decyzję, czy zezwolić czy odmówić żądania.
Poniższe diagramy sekwencji przedstawiają przepływ autoryzacji zezwalającej i odmawiającej:
Każde żądanie wysłane do wtyczki zawiera uwierzytelnionego użytkownika, nagłówki HTTP i treść żądania/odpowiedzi. Do wtyczki przekazywane są tylko nazwa użytkownika i metoda uwierzytelniania użyta. Co najważniejsze, nie przekazywane są żadne dane uwierzytelniające użytkownika ani tokeny. Wtyczce autoryzacji przekazywane są tylko te treści żądania/odpowiedzi, w których Content-Type
to text/*
lub application/json
.
Dla poleceń, które mogą potencjalnie przejąć połączenie HTTP (HTTP Upgrade
), takich jak exec
, wtyczka autoryzacji jest wywoływana tylko dla początkowych żądań HTTP. Po zatwierdzeniu polecenia przez wtyczkę, autoryzacja nie jest stosowana do reszty przepływu. W szczególności, dane strumieniowe nie są przekazywane do wtyczek autoryzacji. Dla poleceń, które zwracają odpowiedź HTTP w postaci porcjowanej (chunked), takich jak logs
i events
, tylko żądanie HTTP jest przekazywane do wtyczek autoryzacji.
Podczas przetwarzania żądania/odpowiedzi niektóre przepływy autoryzacji mogą wymagać dodatkowych zapytań do demona Docker. Aby ukończyć takie przepływy, wtyczki mogą wywoływać interfejs API demona podobnie jak zwykły użytkownik. Aby umożliwić te dodatkowe zapytania, wtyczka musi zapewnić środki umożliwiające administratorowi skonfigurowanie odpowiednich polityk uwierzytelniania i zabezpieczeń.
Wiele wtyczek
Jesteś odpowiedzialny za zarejestrowanie swojej wtyczki jako części uruchamiania demona Docker. Możesz zainstalować wiele wtyczek i połączyć je ze sobą. Ta łańcuchowa konfiguracja może być uporządkowana. Każde żądanie do demona przechodzi przez łańcuch w określonej kolejności. Dostęp jest przyznawany tylko wtedy, gdy wszystkie wtyczki zezwalają na dostęp do zasobu.
Przykłady wtyczek
Twistlock AuthZ Broker
Wtyczka authz pozwala na utworzenie prostego pliku JSON, który wtyczka będzie odczytywać w celu autoryzacji żądań. Daje to możliwość łatwej kontroli, które punkty końcowe API mogą osiągnąć poszczególni użytkownicy.
Oto przykład, który pozwoli Alice i Bobowi tworzyć nowe kontenery: {"name":"policy_3","users":["alice","bob"],"actions":["container_create"]}
Na stronie route_parser.go znajdziesz zależność między żądanym adresem URL a działaniem. Na stronie types.go znajdziesz zależność między nazwą działania a działaniem.
Prosty samouczek wtyczki
Możesz znaleźć łatwą do zrozumienia wtyczkę z szczegółowymi informacjami na temat instalacji i debugowania tutaj: https://github.com/carlospolop-forks/authobot
Przeczytaj plik README
i kod plugin.go
, aby zrozumieć, jak działa.
Ominięcie wtyczki autoryzacji Docker
Wyliczanie dostępu
Główne rzeczy do sprawdzenia to jakie punkty końcowe są dozwolone i jakie wartości HostConfig są dozwolone.
Aby przeprowadzić to wyliczanie, możesz użyć narzędzia https://github.com/carlospolop/docker_auth_profiler.
niedozwolone run --privileged
run --privileged
Minimalne uprawnienia
Uruchamianie kontenera, a następnie uzyskiwanie uprzywilejowanej sesji
W tym przypadku administrator systemu zakazał użytkownikom montowania woluminów i uruchamiania kontenerów z flagą --privileged
lub nadawania kontenerowi dodatkowych uprawnień:
Jednak użytkownik może utworzyć powłokę wewnątrz działającego kontenera i nadać jej dodatkowe uprawnienia:
Teraz użytkownik może uciec z kontenera, korzystając z dowolnej z wcześniej omówionych technik i podnieść uprawnienia wewnątrz hosta.
Zamontuj folder z możliwością zapisu
W tym przypadku administrator systemu zakazał użytkownikom uruchamiania kontenerów z flagą --privileged
lub nadawania kontenerowi dodatkowych uprawnień, a jedynie umożliwił zamontowanie folderu /tmp
:
Zauważ, że być może nie możesz zamontować folderu /tmp
, ale możesz zamontować inny folder z możliwością zapisu. Możesz znaleźć foldery z możliwością zapisu, używając polecenia: find / -writable -type d 2>/dev/null
Należy pamiętać, że nie wszystkie foldery w systemie Linux obsługują bit suid! Aby sprawdzić, które foldery obsługują bit suid, uruchom polecenie mount | grep -v "nosuid"
. Na przykład zazwyczaj foldery /dev/shm
, /run
, /proc
, /sys/fs/cgroup
i /var/lib/lxcfs
nie obsługują bitu suid.
Należy również zauważyć, że jeśli można zamontować folder /etc
lub inny folder zawierający pliki konfiguracyjne, można je zmienić z kontenera Docker jako root, aby wykorzystać je na hoście i eskalować uprawnienia (może to obejmować modyfikację pliku /etc/shadow
).
Niezweryfikowany punkt końcowy API
Odpowiedzialność administratora systemu konfigurującego ten plugin polega na kontrolowaniu, jakie działania i z jakimi uprawnieniami może wykonywać każdy użytkownik. Dlatego jeśli administrator podejmuje czarną listę punktów końcowych i atrybutów, może pominąć niektóre z nich, które mogą umożliwić atakującemu eskalację uprawnień.
Możesz sprawdzić API Dockera pod adresem https://docs.docker.com/engine/api/v1.40/#
Niezweryfikowana struktura JSON
Binds w katalogu root
Możliwe jest, że podczas konfigurowania zapory ogniowej Dockera, administrator systemu pominął pewien ważny parametr API, taki jak "Binds". W poniższym przykładzie można wykorzystać tę nieprawidłową konfigurację do utworzenia i uruchomienia kontenera, który montuje folder root (/) hosta:
Zauważ, że w tym przykładzie używamy parametru Binds
jako klucza na poziomie głównym w JSON, ale w interfejsie API występuje on pod kluczem HostConfig
Binds w HostConfig
Postępuj zgodnie z tymi samymi instrukcjami jak w przypadku Binds w root, wykonując to żądanie do interfejsu API Docker:
Montowanie w katalogu głównym
Postępuj zgodnie z tymi samymi instrukcjami jak w przypadku Montowania w katalogu głównym, wykonując ten żądanie do interfejsu API Docker:
Montaże w HostConfig
Postępuj zgodnie z tymi samymi instrukcjami co w przypadku Binds w root, wykonując to żądanie do interfejsu API Docker:
Niezweryfikowany atrybut JSON
Możliwe, że podczas konfigurowania zapory dockerowej przez sysadmina, zapomniał o pewnym ważnym atrybucie parametru API, takim jak "Capabilities" wewnątrz "HostConfig". W poniższym przykładzie można wykorzystać tę nieprawidłową konfigurację, aby utworzyć i uruchomić kontener z uprawnieniem SYS_MODULE:
HostConfig
to klucz, który zazwyczaj zawiera interesujące uprawnienia, które umożliwiają ucieczkę z kontenera. Jednak, jak już wcześniej omówiliśmy, zauważ, że korzystanie z Binds poza nim również działa i może umożliwić ominiecie ograniczeń.
Wyłączanie wtyczki
Jeśli sysadmin zapomniał zakazać możliwości wyłączenia wtyczki, możesz z tego skorzystać, aby ją całkowicie wyłączyć!
Pamiętaj, aby ponownie włączyć wtyczkę po eskalacji, w przeciwnym razie restart usługi docker nie zadziała!
Opisy omijania wtyczki autoryzacji
Odwołania
Last updated