Cześć. Jeśli zastanawiasz się, czy w chmurze AWS można się bezpiecznie dostać do S3 z poziomu maszyny wirtualnej EC2 bez podawania hasła, to mam dla ciebie dobrą wiadomość. MOŻNA. Poniżej przygotowałem tutorial, który pokaże Ci krok po kroku co trzeba zrobić. Nie musisz przechowywać hasła w żadnym magazynie kluczy, KMS,HashiCorp Vault czy innym miejscu. Można zrobić to bez podawania hasła. Koniec z ukrywaniem loginów i haseł.
Wszystko, co musisz zrobić, to wykonać 5 poniższych kroków 🙂
1) Utworzenie roli IAM
Na początku utwórz rolę IAM. Będzie nam ona potrzebna po to, by dodać do niej uprawnienia i przypisać ją do docelowej maszyny EC2.
Wyszukaj IAM, z menu wybierz „Roles” i kliknij na „Create Role”.
Świetnie. Teraz wybierz EC2 i kliknij na Next. Ponieważ chcesz, żeby była ona widziana przez twoje maszyny EC2. W tym miejscu możesz także wybrać kontenery lub inne komponenty AWS, którym chcesz pozwolić na używanie tej roli.
Możesz wybrać dodatkowe polityki, które chcesz, żeby były przypisane do tej roli. My tworzeniem polityki zajmiemy się jednak w kolejnym kroku. Gdy skończysz, to kliknij na Next.
Teraz możesz dodać Tagi do tworzonej roli, ale nie musisz tego robić, jeśli nie chcesz. Gdy skończysz, to kliknij na Next.
Na ostatniej karcie tworzysz nazwę roli i zalecam wpisanie opisu, żebyś wiedział za rok, do czego służy ta polityka i poco ją utworzyłeś. Gdy skończysz, to kliknij na Create role.
2) Dodanie polityki do roli IAM
Teraz zajmiemy się dodaniem polityki do utworzonej roli. Można to był stworzyć w poprzednim kroku. Ja jednak nie chciałem tworzyć dodatkowej polityki widocznej na liście polityk, tylko stworzyć coś dedykowanego dla określonej roli.
W tym celu przechodzimy do IAM, z menu wybieramy „Roles” i wyszukujemy po nazwie naszą rolę utworzoną w poprzednim kroku w moim przypadku „EC2-accessS3-testwojtek” i klikamy „Add inline policy„.
Wybieramy zakładkę JSON i wklejamy kod widoczny pod obrazkiem.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": "s3:*",
"Resource": "arn:aws:s3:::testwojtek",
"Condition": {
"StringLike": {
"s3:prefix": [
"folder1/*"
]
}
}
}
]
}
Kod, który właśnie dodałeś, pozwala na wykonanie dowolnej operacji na S3 o nazwie „testwojtek”, ale tylko w folderze „folder1”.
Gdy już wkleiłeś powyższy kod, to popraw w nim nazwę S3 by odpowiadała twoim zasobom. Ja dodatkowo ograniczyłem możliwość akcji tylko do specyficznego folderu o nazwie folder1, który znajduje się w moim S3.
- Jeśli potrzebujesz, to możesz umożliwić tylko zapis albo odczyt z określonego folderu, co uczyni rozwiązanie jeszcze bardziej bezpiecznym.
- Jeśli chcesz, to możesz umożliwić dostęp do całego bucketu, w tym celu usuń sekcję „Condition” z JSONa.
W dokumentacji na stronie AWS znajdziesz dużo przydatnych informacji dotyczących pracy z bucketami S3.
Gdy skończysz tworzyć swoją idealną politykę, to kliknij Review policy. Teraz możesz nadać nazwę swojej polityce i kliknąć Create policy.
3) Dodanie roli do EC2
Gdy już stworzyłeś odpowiednią rolę z politykami, których potrzebujesz czas dodać ją do twojej wirtualnej maszyny. Będziesz miał z niej dostęp do wybranego przez Ciebie zasobu w S3.
W tym celu wyszukujemy interesującą nas maszynę z listy naszych EC2, zaznaczamy ją i klikamy na Action/ Security/ Modify IAM role.
Teraz z rozwijanej listy wybieramy utworzoną przez nas rolę i klikamy Save.
4) Przygotowanie EC2
Logujemy się na naszą EC2 i instalujemy z linii poleceń narzędzia do AWS.
Na Ubuntu wygląda to w ten sposób:
#aktualizacja
sudo apt-get update
#instalacja awscli
sudo apt-get install awscli
#sprawdzenie poprawności np przez wyświetlenie wersji
aws --version
Jeśli masz inny system, to postępuj według wskazówek dla twojego systemu, dostępnych na stronie AWS w sekcji instalacji awscli.
5) Testy
To już wszystko, teraz trzeba tylko sprawdzić, czy mamy dostęp do S3, bez podawania jakichkolwiek poświadczeń. W tym celu możemy wylistować pliki będące w naszym folderze na S3, za pomocą polecenia:
aws s3 ls s3://testwojtek/folder1/
Ty użyj oczywiście własnej nazwy S3 i folderu.
Jak widać na poniższym obrazku, zgodnie z przewidywaniami mam dostęp do folder1, nawet bez podawania poświadczeń (niestety brak w nim plików). Do folder2 już tego dostępu nie mam, ponieważ uprawnienia dotyczyły tylko folderu1.
Uwaga szyfrowanie!
Drobna rzecz na którą zwrócono mi uwagę, dotycząca szyfrowania S3. Drobna, ale bardzo istotna, jeśli masz S3 szyfrowane kluczem w KMS, to musisz dodać utworzonej roli z punktu 1 także uprawnienia do tego klucza.
Podsumowanie
Podsumowując, dodawanie w ten sposób uprawnień do maszyn EC2 poprawia pod pewnym względem bezpieczeństwo i upraszcza sporo rzeczy. Jeśli ktoś skopiuje taką maszynę, to nie będzie miał dostępu do naszych danych na S3 i nie uda mu się wyciągnąć w żaden sposób loginu i hasła do S3 z naszej EC2, ponieważ ich tam niema 🙂
Musimy pamiętać natomiast o tym, że każdy, kto będzie miał dostęp do tej EC2 to po zalogowaniu będzie miał także dostęp do S3 w takim zakresie jaki nadaliśmy roli.
Idealnych rozwiązań nie ma, ale zawsze warto wiedzieć, jakie mamy możliwości i jakie zagrożenia one niosą.
Jeśli podobał Ci się artykuł zapraszam do zapoznania się z resztą artykułów dotyczących chmury AWS i Azure.
W celu ograniczenia uprawnień możesz użyć polityki z takim blokiem Action:
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:ListBucket",
"s3:DeleteObject"
],
Możliwość komentowania została wyłączona.