Zdalny dostęp do zasobów to jeden z kluczowych elementów codziennej pracy administratorów, czy inżynierów wsparcia. Zdalny dostęp przydaje się zawsze, gdy lokalna administracja nie jest możliwa, lub gdy zasoby znajdują się np. w chmurze.
Właśnie ten drugi przypadek, to częsty element rozważań gdy pracuje z moimi klientami.
W tym wpisie chciałbym pokazać Ci w jaki zdalny dostęp dzięki AWS Session Manager może być alternatywną do dobrze znanego SSH.
Zdalny dostęp z 0.0.0.0/0
Dzisiaj pozostaniemy przy klasycznych wirtualnych maszynach (ukłony do miłośników serverless). W przypadku zasobów w chmurze, kwestia zdalnego dostępu bywa czasem problematyczna.
Jeśli zdecydujemy się podeście, w którym korzystamy ze standardowych metod dostępu (SSH/RDP), to mamy do zaadresowania następujące wyzwania takie jak np.:
- Konfiguracja firewall: a dokładnie, to z jakich adresów IP będzie możliwy zdalny dostęp (bo przecież nie chcemy aby dostęp był z całego Internetu, prawda 😎),
- W jaki sposób łączyć się do zasobów, które nie są bezpośrednio dostępne z Internetu (ulokowane są w sieciach prywatnych),
- itp.
Zdarzają się firmy w których polityki bezpieczeństwa zabraniają w ogóle możliwości łączenia się po SSH/RDP z zasobami znajdującymi się poza fizyczną lokalizacją i wtedy trzeba szukać zupełnie innego rozwiązania.
Zdalny dostęp do zasobów w chmurze
Teraz do tego wszystkiego dołożymy aspekt tego, że nasze zasoby są ulokowane gdzieś tam daleko i nie mamy możliwości podejść i fizycznie „pogłaskać” naszych serwerów.
Zatem jeśli interesują Cię alternatywy, to dzisiaj pokaże Ci w jaki sposób z wykorzystaniem AWS Session Manager łatwo i przyjemnie zrobić sobie „wjazd” na wirtualne serwery.
AWS Systems Manager
Usługa AWS Systems Manager jest rozwiązaniem, które adresuje różne aspekty operacyjnego zarządzania infrastrukturą chmurową, a także tą lokalną.
Jednym narzędzi wchodzących w skład tej usługi jest Session Manager, który pozwala dostać się do shell’a czy zdalnego desktopu z wykorzystaniem zwykłej przeglądarki Internetowej.
Let’s Play
Przejdźmy zatem do części praktycznej i w dalszej części skupimy się na przygotowaniu i zdalnym dostępie do naszego przykładowego serwera.
Wymagania
Do poprawnego działania usługi potrzebne jest kilka elementów:
- Wspierany system operacyjny: na ten moment praktycznie wszystkie wersje linuxa, Mac OS, oraz Windows od 2012 do 2019.
- SSM Agent: Aby usługa mogła prawidłowo komunikować się z zarządzaną maszyną, trzeba zainstalować na niej SSM Agent.
- Połączenie do usługi – agenty musi być w stanie połączyć się z odpowiednimi end pointami usługi. Komunikacja odbywa się po HTTPS (443) z:
-
ec2messages.
region.amazonaws.com -
ssm.
region.amazonaws.com -
ssmmessages.
region.amazonaws.com
-
- Uprawnienia: Dodatkowo zostaje jeszcze kwestia uprawnień: w przypadku maszyn EC2 potrzebne jest przygotowanie odpowiedniej IAM Roli wraz z uprawnieniami do usługi Session Managera. Oczywiście zakładam, że nasz użytkownik również posiada niezbędne uprawnienia pozwalające na korzystanie z tej usługi.
Zatem, do dzieła….
Krok 1: Przygotowanie IAM Roli na usługi EC2.
Czyli aby agent na naszej maszynie mógł „legalni” skomunikować się z usługą Session Managera, przechodzą do usługi IAM i tam w zakładce Roles tworzę rolę dla usługi EC2.
Następnie dodaje uprawnienia pozwalające na komunikację z usługą Session Manager. W tym celu na potrzeby mojego DEMO wykorzystam gotową już IAM Policy AmazonEC2RoleforSSM.
Dalej już pozostaje tylko nadać odpowiednia nazwę i utworzyć role.
Krok 2: Konfiguracja serwera i SSM Agent.
Teraz przygotuję sobie serwer, do którego będę się łączył. W tym wypadku uruchomię wirtualny serwer z wykorzystaniem obrazu AWS AMI, który ma już zainstalowanego SSM Agenta.
W przypadku innych obrazów, możesz bez problemu doinstalować takiego agenta. W tym wypadku pomocne mogą być te dwa linki:
- Manually installing SSM Agent on EC2 instances for Linux
- Manually installing SSM Agent on EC2 instances for Windows Server
Krok 3: Przypięcie IAM Roli do maszyny wirtualnej.
Teraz aby SSM Agent na Twoim serwerze mógł się komunikować z usługą AWS System Manager należy przypiąć utworzoną w Krok 1 IAM Role (a dokładnie to IAM Profile, który został utworzony w trakcie tworzenia IAM Roli).
Jeśli uruchamiasz nowy serwer z obrazu, który ma już zainstalowanego agenta, to wystarczy w trakcie jego tworzenia rozwinąć sekcję Advanced details i tam przypiąć utworzony wcześniej profil.
Z kolei jeśli chcesz dopiąć rolę do istniejącego już serwera, to wystarczy w konsoli zaznaczyć serwer i z menu po wyżej wybrać Actions -> Security -> Modify IAM Role.
I tak samo wybrać IAM Role z Kroku pierwszego.
Czas sprawdzić połączenie.
Czas na szybki test, w konsoli zaznaczasz swój serwer, z menu na górze wybierasz przycisk Connect.
Następnie przełączasz się do zakładki Session Manager, jeśli wszystko jest poprawnie skonfigurowane powinno pojawić się poniższe okno.
Jeśli coś jednak będzie nie tak, to tutaj również pojawi się informacja, że trzeba zweryfikować konfiguracje.
Zatem jeśli jest ok, wystarczy kliknąć Connect i za moment powinno się otworzyć okno konsoli.
I to tyle…
A co z serwerami w sieciach prywatnych?
To jeszcze jedno na koniec…
…..a co gdy mamy serwery, które nie mają dostępu do Internetu lub wymagany jest ograniczony i kontrolowany dostęp?
Jak pamiętasz powyżej mowa była o konieczności komunikacji z odpowiednimi end pointami usługi SSM.
Aby zapewnić taką komunikację mamy dwie opcje:
- Realizacja komunikacji z wykorzystaniem NAT Gateway.
- Użycie VPC Endpoint do zapewnienia prywatnego połączenia do SSM.
To teraz już powinno Ci zadziałać…. Cheers 😎
Zbuduje swoje bezpieczne środowisko AWS.
