Jednym z punktów migracji klienta do Amazon Web Services było włączenie SSO (Single Sign On) – co jest bardzo wygodnym rozwiązaniem. Po szybkiej weryfikacji (jakie mamy możliwości), okazało się, że możemy użyć ADFS. Klient już wykorzystywał ADFS pod inne usługi, zatem mogliśmy pominąć etap przekonywania Security Team.

Po kilku dniach walki z różnymi zawiłościami Ping Federate udało się włączyć SSO, zrobić ładną pętlę przekierowań przez wspomnianego ADFS. Zwracany SAML miał wszystko czego potrzebujemy, a Windchill na to odpowiedział… „Error 500”.

Bardziej dogłębna lektura dokumentacji ujawniła, że SSO z ADFS jest jak najbardziej przez Windchilla wspierane, ale tworzenie nowego użytkownika na podstawie otrzymanego z ADFS SAML’a już nie. Windchill potrzebuje bazy użytkowników do porównania, a to najwygodniej dostarczyć odpytując kontroler domeny jakimś ldap’em, jeszcze lepiej z SSL.

Infrastruktura w AWS i kontrolery domeny w serwerowniach klienta

 

Wystawienie kontrolera na świat raczej nie przejdzie przez Security Team, a przecież musimy je jakoś odpytać.

Trzeba się spiąć z klientem VPN i przez tunel odpytywać kontrolery bezpiecznym ldaps. Niestety, żeby nie było tak prosto, to w AWS już kilka środowisk działa, każde w innym VPC i każde musi się dostać ze swoim zapytaniem do AD.

Co zrobić, jak żyć?

Wariantów było wiele (to tylko kilka):

  • Użyć Transit Gateway i robić NAT po stronie klienta

Niestety, istniejące już VPC pokrywały się adresami z tym, co klient miał w swojej sieci. Oczywiście dałoby się to obejść, natomiast naglił nas czas, a zabawy z routingiem w globalnej organizacji mogły ciągnąć się latami.

  • Dodać nowe VPC z siecią, której klient jeszcze nie ma, zrobić routing, peering między pozostałymi VPC, dodać VPN Gateway do tego VPC.

Krótka prezentacja (która naświetliła klientowi problem), zaowocowała wypracowaniem stanowiska, że tworzymy nowe VPC, robimy routing, peering między pozostałymi VPC, łączymy VPN i stawiamy w tym VPC AWS Directory Service.

Tak też było, ale niestety okazało się, że ograniczenia tego ostatniego nie bardzo pozwalają na odpytywanie protokołem ldap o obiekty w domenie klienta. Tak – mała porażka… Nie wspominając już o ustawiania Trust Relationship między domenami.

W między czasie, żeby nie blokować developmentu jakiegoś dodatkowego narzędzia, wystawiliśmy w VPC zwykłego Amazon Linux i prostym tunelem SSH ominęliśmy kilka ograniczeń związanych z brakiem tranzytowych VPC w AWS.

Kolejnym podejściem było wystawienie w AWS Kontrolera domeny klienta w trybie tylko do odczytu. Takie rozwiązanie zapewniało dostęp do aplikacji nawet w przypadku problemów z tunelami VPN. Zorganizowanie VPN poszło nadspodziewanie dobrze.

Już myśleliśmy, że jesteśmy blisko: kontroler tylko do odczytu, dało się go odpytać ldap i wszystko było pięknie, ale nie dla Security klienta, które wcześniej zgodziło się na taką opcje. Co poradzić, Security wie swoje i klucza publicznego do wewnętrznego CA nam nie dadzą – ehh te PKI.

Niesieni pewną emocją, uznaliśmy, że dość już tego pięknego tańca. Szybki przegląd stanu:

  • VPC spięte VPN z siecią klienta – jest
  • Dane logowania do AD przez ldap – jest

 

Czego brakuje?

Czegoś na kształt proxy ldap do Active Direcotry. Stawiamy VPC z VPN, ciskamy zapytaniami ldap w to proxy, następnie ono nas gładko przekierowało do AD klienta i byliśmy w domu.

Kolejne 5 godzin prób i TAADAAM – działa. OpenLDAP daje radę. Weryfikacja w Windchillu i po problemie. EC2 z OpenLdap działa i… w zasadzie to się nudzi.

Hmm, a może by tak to wsadzić w kontener docker?

Hmm, a może by ten kontener uruchomić w ECS?

Hmm, w sumie persistent storage to nie potrzebuje, to może Fargate?

Zbudowanie kontenera z LDAP Proxy na z CentOS to w sumie kilka linijek. Potem szybki upload do ECR, definicja Taska i można tworzyć serwis.
Tylko jak kierować ruch na ten serwis? Przecież IP będzie za każdym razem inny. Może przez LoadBalancer? – nie.

Definiując Serwis można użyć opcji „Service Discovery”, która to opcja tworzy Hosted Zone w Route53 i aktualizuje rekord A prowadzący do serwisu – genialne. Teraz tylko wystarczy taką Hosted Zone przypiąć do VPC z Windchillem i strzelać zapytania ldaps do zarejestrowanej tam nazwy.

Na koniec (żeby się specjalnie później tym nie interesować) wystarczy zdefiniować prosty healthcheck, dzięki któremu ECS będzie podmieniał nam niedziałający kontener na nowy – zwykle w ciągu minuty.

Ile wyniosły koszty?

  • Opcja 1 z AWS AD Service – około $90/miesiąc
  • Opcja 2 z EC2, która była Kontrolerem domeny w trybie Read-Only – około $80/miesiąc
  • Opcja 3 z kontenerem w trybie uruchamiania Fargate – około $10 (0,25CPU z 1GB RAM)

 

How useful was this post?

Click on a star to rate it!

Average rating 5 / 5. Vote count: 14

No votes so far! Be the first to rate this post.

W przypadku naruszenia Regulaminu Twój wpis zostanie usunięty.
Twoje imię i nazwisko

    _Wszystkie wpisy z tej kategorii

    Co musisz wiedzieć o serverless computing?

    Jednym z punktów migracji klienta do Amazon Web Services było włączenie SSO (Single Sign On) – co jest bardzo wygodnym rozwiązaniem. Po szybkiej…
    Czytaj dalej

    Czym jest DevOps as a service i czemu warto z tego skorzystać?

    Jednym z punktów migracji klienta do Amazon Web Services było włączenie SSO (Single Sign On) – co jest bardzo wygodnym rozwiązaniem. Po szybkiej…
    Czytaj dalej

    9 powodów, dla których powinno się wykorzystywać chmurę w prowadzeniu biznesu

    Jednym z punktów migracji klienta do Amazon Web Services było włączenie SSO (Single Sign On) – co jest bardzo wygodnym rozwiązaniem. Po szybkiej…
    Czytaj dalej

    Jak zacząć przygodę z Azure i przygotować się do certyfikacji AZ-900

    Jednym z punktów migracji klienta do Amazon Web Services było włączenie SSO (Single Sign On) – co jest bardzo wygodnym rozwiązaniem. Po szybkiej…
    Czytaj dalej

    Chmura na czas kryzysu, czyli jak usprawnić pracę w swojej firmie

    Jednym z punktów migracji klienta do Amazon Web Services było włączenie SSO (Single Sign On) – co jest bardzo wygodnym rozwiązaniem. Po szybkiej…
    Czytaj dalej

    Jak zadbać o bezpieczeństwo aplikacji serverless w AWS?

    Jednym z punktów migracji klienta do Amazon Web Services było włączenie SSO (Single Sign On) – co jest bardzo wygodnym rozwiązaniem. Po szybkiej…
    Czytaj dalej

    Parametry SSM w automatyzacji AWS

    Jednym z punktów migracji klienta do Amazon Web Services było włączenie SSO (Single Sign On) – co jest bardzo wygodnym rozwiązaniem. Po szybkiej…
    Czytaj dalej

    Jak dotknęliśmy chmur - relacja z AWS re:invent 2019

    Jednym z punktów migracji klienta do Amazon Web Services było włączenie SSO (Single Sign On) – co jest bardzo wygodnym rozwiązaniem. Po szybkiej…
    Czytaj dalej

    Najważniejsze nowości z AWS re:Invent 2019

    Jednym z punktów migracji klienta do Amazon Web Services było włączenie SSO (Single Sign On) – co jest bardzo wygodnym rozwiązaniem. Po szybkiej…
    Czytaj dalej

    Jak wykorzystać Talend Open Studio w branży medycznej?

    Jednym z punktów migracji klienta do Amazon Web Services było włączenie SSO (Single Sign On) – co jest bardzo wygodnym rozwiązaniem. Po szybkiej…
    Czytaj dalej

    Czym jest chmura Amazon Web Services?

    Jednym z punktów migracji klienta do Amazon Web Services było włączenie SSO (Single Sign On) – co jest bardzo wygodnym rozwiązaniem. Po szybkiej…
    Czytaj dalej

    Dlaczego serverless jest przyszłością aplikacji

    Jednym z punktów migracji klienta do Amazon Web Services było włączenie SSO (Single Sign On) – co jest bardzo wygodnym rozwiązaniem. Po szybkiej…
    Czytaj dalej

    Windchill Single Sign On – jak z Amazon Web Services dostać się do Active Directory w sieci klienta?

    Jednym z punktów migracji klienta do Amazon Web Services było włączenie SSO (Single Sign On) – co jest bardzo wygodnym rozwiązaniem. Po szybkiej…
    Czytaj dalej

    Budujemy własne AWS Echo (z AWS Alexa na pokładzie)

    Jednym z punktów migracji klienta do Amazon Web Services było włączenie SSO (Single Sign On) – co jest bardzo wygodnym rozwiązaniem. Po szybkiej…
    Czytaj dalej

    Dlaczego rozwiązania Cloud?

    Jednym z punktów migracji klienta do Amazon Web Services było włączenie SSO (Single Sign On) – co jest bardzo wygodnym rozwiązaniem. Po szybkiej…
    Czytaj dalej

    Rosnąca popularność modelu usług Serverless

    Jednym z punktów migracji klienta do Amazon Web Services było włączenie SSO (Single Sign On) – co jest bardzo wygodnym rozwiązaniem. Po szybkiej…
    Czytaj dalej

    Chmura to przyszłość

    Jednym z punktów migracji klienta do Amazon Web Services było włączenie SSO (Single Sign On) – co jest bardzo wygodnym rozwiązaniem. Po szybkiej…
    Czytaj dalej

    Transition Technologies PSC uzyskało tytuł Standard Consulting Partner Amazon Web Services (AWS)

    Jednym z punktów migracji klienta do Amazon Web Services było włączenie SSO (Single Sign On) – co jest bardzo wygodnym rozwiązaniem. Po szybkiej…
    Czytaj dalej

    _Zostańmy w kontakcie

    Skontaktuj się