PLNOG 21: Piotr Wojciechowski - ANSIBLE_I_AUTOMATYZACJA_W_ŚRODOWISKACH_SZCZEGÓLNIE_CHRONIONYCH

ANSIBLE I AUTOMATYZACJA W
ŚRODOWISKACH SZCZEGÓLNIE
CHRONIONYCH
Piotr Wojciechowski (CCIE #25543)

www.it-playground.pl
ABOUT ME
¢ Independent Network Architect and IT Consultant owning
“IT Playground” business
¢ Blogger – https://blog.it-playground.eu
¢ Previously Network Solutions Architect at one of top polish IT
integrator
¢ CCIE #25543 (Routing & Switching)
¢ PLNOG Advisory Board member
¢ CCIE.PL General Admin

ABOUT CCIE.PL
¢ The biggest Cisco community in Europe
¢ Over 8300 users, over 21000 topics, over 156000 posts
¢ Strong staff
— 3 general admins
— 1 board admin
— 3 servers admins
— 3 moderators
¢ Over 60 polish CCIEs as members
— over 20 of them actively posting!
¢ About 100 new topics per month
¢ About 800 posts per month

AGENDA
¢ Środowiska przetwarzające dane wrażliwe
¢ Troszkę o samej automatyzacji
¢ Przykładowa infrastruktura oraz zautomatyzowane zadanie
¢ Wybrane kluczowe aspekty automatyzacji środowisk przetwarzających
dane wrażliwe
¢ Automatyzacja budowy i utrzymania infrastruktury do automatyzacji

ZANIM ZACZNIEMY ZAJMOWAĆ SIĘ AUTOMATYZACJĄ

Nie da się odpowiedzialnie zająć automatyzacją bez…
¢ Znajomości podstaw programowania

¢ Rozumienia nowoczesnych struktur danych (JSON, XML)

¢ Rozumienia różnicy pomiędzy frontend i backend

¢ Zrozumienia i zaakceptowania, że nie trzeba wymyślać koła na nowo

CHARAKTERYSTYKA ŚRODOWISK PRZETWARZAJĄCYCH
DANE WRAŻLIWE

CZYM SĄ DANE WRAŻLIWE?
¢ Każda informacja przetwarzana elektronicznie, którą:
— należy chronić ze względu na wymogi prawne,
— należy chronić ze względu na wymogi certyfikacji
— stanowi tajemnicę handlową przedsiębiorstwa
— stanowi tajemnicę technologiczną przedsiębiorstwa
— lub jej ujawnienie może spowodować negatywny wpływ na procesy biznesowe
przedsiębiorstwa
jest z punktu widzenia przedsiębiorstwa daną wrażliwą i jej przetwarzanie
powinno podlegać szczególnej ochronie

PO CO NAM TA CAŁA AUTOMATYZACJA?
¢ Najczęściej powtarzane argument za automatyzacją zadań na poziomie
infrastruktury IT
— Szybsze wprowadzanie powtarzalnych zmian w ustandaryzowanych
środowiskach
— Szybkie tworzenie i usuwanie wirtualnych środowisk do testów
developerskich, oddanie zarządzania procesem developerom
— Redukcja kosztów operacyjnych działu IT - zwiększenie efektywności i
płynności operacyjnej

SZCZEGÓLNE ZAGADNIENIA W CHRONIONYCH
ŚRODOWISKACH
¢ Specjalistyczne certyfikacje czy wymogi prawne eksponują wagę
szczególnej kontroli wybranych zadań, takich jak:
— Change control, czyli proces akceptacji zmian zgodnie z narzuconymi
wymogami
— Kontrola nad infrastrukturą wykonującą operacje
— Nadzór nad procesem wykonywania zautomatyzowanych zmian
— Hardening komponentów infrastruktury

INFRASTRUKTURA NARZĘDZI AUTOMATYZACJI
Docker Image
Server

DEV VS. BAU
¢ Automatyzacja procesu budowy i usuwania środowisk już jest dobrze
opisana i zdefiniowana w standardach czy wytycznych
¢ Automatyzacja procesu utrzymania i diagnostyki nadal traktowana
jest jako temat poboczny

INFRASTRUKTURA AUTOMATYZACJI PROCESÓW
GIT Server
Ansible/AWX
Server
Production DC

WEBINARIA I KONKURS!
¢ „Infrastruktura
automatyzacji, która sama
się buduje”
18.10.2018 (czwartek)
godz. 10:00

CHANGE CONTROL

CHANGE CONTROL
¢ Change Control to usystematyzowany proces zgłoszenia, opisania,
zaakceptowania, wdrożenia i przetestowania zmiany w infrastrukturze
lub oprogramowaniu
Zgłoszenie potrzeby
zmiany
•Otwarcie
zgłoszenia
•Opis wymaganych
zmian
•Uzasadnienie dla
wprowadzenia
zmiany
Zgłoszenie zmian w
infrastrukturze
•Na podstawie
zgłoszenia
rejestracja zadań
konkretnych
zmian
•Przypisanie
zmian do
konkretnych
zespołów
•Ustalenie
harmonogramu
Akceptacja
zgłoszenia zmiany
•Weryfikacja
poprawności
zgłoszenia
•Akceptacja
techniczna
•Akceptacja
biznesowa
•Akceptacja działu
security
Wdrożenie zmiany
•Rekonfiguracja
urządzeń
Testowanie
poprawności
wdrożenia
•Testy
funkcjonalne
•Testy
akceptacyjne

CHANGE CONTROL
¢ Change Control to usystematyzowany proces zgłoszenia, opisania,
zaakceptowania, wdrożenia i przetestowania zmiany w infrastrukturze
lub oprogramowaniu
zmiany
•Project manager:
„Proszę o dostęp
do aplikacji X dla
użytkownika o
adresie 10.10.9.9”
•Uzasadnienie:
nowy pracownik
działu HR
Zgłoszenie zmian w
infrastrukturze
•Inżynier sieciowy:
Dodanie adresu
10.10.9.9 do ACL
o naziwe CRM na
firewallu DMZ-1
•Zmiana w
poniedziałek 10
stycznia o 4 rano
Akceptacja
zgłoszenia zmiany
•Weryfikacja
poprawności
zgłoszenia
•Akceptacja
techniczna
•Akceptacja
biznesowa
security
Wdrożenie zmiany
•Rekonfiguracja
urządzeń 24
lutego o 6 rano
przez inżyniera
sieciowego
Testowanie
poprawności
wdrożenia
•Nowy pracownik
o godzinie 10
sprawdza, czy ma
dostęp do CRM

zmiany
•Project manager:
do aplikacji X dla
użytkownika o
adresie 10.10.9.9”
•Uzasadnienie:
nowy pracownik
działu HR
Zgłoszenie zmian w
infrastrukturze
Dodanie adresu
10.10.9.9 do ACL
o naziwe CRM na
firewallu DMZ-1
•Zmiana w
poniedziałek 21
lutego o 4 rano
Akceptacja
zgłoszenia zmiany
•Weryfikacja
poprawności
zgłoszenia
•Akceptacja
techniczna
•Akceptacja
biznesowa
security
Wdrożenie zmiany
•Rekonfiguracja
urządzeń 24
lutego o 4 rano
przez inżyniera
sieciowego
Testowanie
poprawności
wdrożenia
•Nowy pracownik
o godzinie 10
sprawdza, czy ma
dostęp do CRM
CHANGE CONTROL
Otwarcie zgłoszenia:
1 lutego
Otwarcie zgłoszenia
zmiany:
7 lutego
Akceptacja zmiany:
Weryfikacja - 7 lutego
Akceptacja techniczna - 8 lutego
Akceptacja biznesowa - 7 lutego
Akceptacja security - 14 lutego
Wdrożenie zmiany:
24 lutego, 4 rano
Przetestowanie zmiany:
24 lutego, 10 rano

zmiany
•Project manager:
do aplikacji X dla
użytkownika o
adresie 10.10.9.9”
•Uzasadnienie:
nowy pracownik
działu HR
Zgłoszenie zmian w
infrastrukturze
Dodanie adresu
10.10.9.9 do ACL
o naziwe CRM na
firewallu DMZ-1
•Zmiana w
poniedziałek 21
lutego o 4 rano
Akceptacja
zgłoszenia zmiany
•Weryfikacja
poprawności
zgłoszenia
•Akceptacja
techniczna
•Akceptacja
biznesowa
security
Wdrożenie zmiany
•Rekonfiguracja
urządzeń 24
lutego o 4 rano
przez inżyniera
sieciowego
Testowanie
poprawności
wdrożenia
•Nowy pracownik
o godzinie 10
sprawdza, czy ma
dostęp do CRM
CHANGE CONTROL – USPRAWNIAMY I AUTOMATYZUJEMY
1 lutego
zmiany:
7 lutego
Akceptacja zmiany:
Wdrożenie zmiany:
24 lutego, 4 rano
24 lutego, 10 rano
Zakończony proces akceptacji
powoduje utworzenie zadania
zautomatyzowanej aktualizacji
ACL we wskazanym oknie

zmiany
•Project manager:
do aplikacji X dla
użytkownika o
adresie 10.10.9.9”
•Uzasadnienie:
nowy pracownik
działu HR
Zgłoszenie zmian w
infrastrukturze
Dodanie adresu
10.10.9.9 do ACL
o nazwe CRM na
firewallu DMZ-1
•Zmiana w
poniedziałek 21
lutego o 4 rano
Akceptacja
zgłoszenia zmiany
•Weryfikacja
poprawności
zgłoszenia
•Akceptacja
techniczna
•Akceptacja
biznesowa
security
Wdrożenie zmiany
•Rekonfiguracja
urządzeń 24
lutego o 4 rano
przez inżyniera
sieciowego
Testowanie
poprawności
wdrożenia
•Nowy pracownik
o godzinie 10
sprawdza, czy ma
dostęp do CRM
CHANGE CONTROL – USPRAWNIAMY I AUTOMATYZUJEMY
1 lutego
zmiany:
1 lutego
Akceptacja zmiany:
Wdrożenie zmiany:
24 lutego, 4 rano
24 lutego, 10 rano
Zakończony proces akceptacji
powoduje utworzenie zadania
zautomatyzowanej aktualizacji
ACL we wskazanym oknie
Project manager wpisuje dane
do formularza wybierając
aplikację z listy
Zgłoszenie zmiany tworzy się
automatycznie

NADZÓR NAD WPROWADZANIEM ZMIAN

Wdrożenie
zmiany
•Rekonfiguracja
urządzeń 24
lutego o 4 rano
przez inżyniera
sieciowego
¢ 24 lutego
— 3:30 – dzwoni budzik
— 3:40 – inżynier łączy się z data
center
— 4:05 – inżynier dopisuje adres IP
do ACL
— 4:06 – inżynier weryfikuje ACL
na urządzeniu
— 4:15 – inżynier zamyka zadanie
w systemie i wysyła maila do
użytkownika z prośbą o
przetestowanie
— 4:20 – inżynier wraca spać (o ile
mu się uda)

¢ Zamiast budzić inżyniera
zadanie wykonuje się jako
playbook Ansible
¢ Wywołanie playbooka z
odpowiednim parametrem
możemy zaprogramować w
Ansible Tower (AWX)
¢ Inżynier nie jest już niezbędny
by wprowadzić zmianę!
Ansible/AWX
Server
Production DC

¢ Skąd pewność, że ktoś nie
podmienił playbooka?
¢ Jedynym miejscem z kodem
playbooka jest repozytorium
GIT!
GIT Server
Ansible/AWX
Server
Production DC

¢ Ansible Tower pobiera kod
playbooka z repozytorium GIT
przy każdej próbie jego
wykonania
¢ Lokalna kopia playbooka jest
usuwana po jego wykonaniu
GIT Server
Ansible/AWX
Server
Production DC

¢ „(Pół)automatyczny
operator NOC”
25.10.2018 (czwartek)
godz. 10:00

NADZÓR NAD KODEM

NADZÓR NAD KODEM - DEVELOPMENT
Private
branches
Devel
Test
Master
Kod dopuszczony
do DC
produkcyjnych
Kod dopuszczony
do DC testowych
Kod dopuszczony
do testowych
środowisk
developerskich
Branch Piotra Branch Jancka
Branch zespołu
od ACLek
¢ Praca nad playbookiem
przebiega na tych samych
zasadach co praca nad kodem
aplikacji
¢ Podział na branche zapewnia
separację i mechanizmy
kontroli

Private
branches
Devel
Test
Master
Kod dopuszczony
do DC
produkcyjnych
Kod dopuszczony
do DC testowych
Kod dopuszczony
do testowych
środowisk
developerskich
Branch zespołu
od ACLek
¢ Wielka zmiana z punktu widzenia
działu security!
— Było bez automatyzacji:
akceptujemy każdorazowo sposób
wykonania zadania opisamy w
żądaniu zmiany
— Po wprowadzeniu automatyzacji:
akceptujemy zmiany w kodzie
wykonującym rekonfigurację oraz
parametry jego wywołania

Private
branches
Devel
Test
Master
Kod dopuszczony
do DC
produkcyjnych
Kod dopuszczony
do DC testowych
Kod dopuszczony
do testowych
środowisk
developerskich
Branch zespołu
od ACLek
Zadanie Bezpieczeństwo
Zmiana kodu Zalgowany użytkownik
właściciel gałęzi
Operacja zmiany kodu Commit
Wykonanie kodu Laptop developera
Change control Brak

Zmiana kodu Zalogowany użytkownik
Operacja zmiany kodu Commit, Merge
Wykonanie kodu Środowisko
developersskie
Change control Brak
Private
branches
Devel
Test
Master
Kod dopuszczony
do DC
produkcyjnych
Kod dopuszczony
do DC testowych
Kod dopuszczony
do testowych
środowisk
developerskich
Branch zespołu
od ACLek

Zmiana kodu Zalogowany użytkownik
Operacja zmiany kodu Merge only z gałęzi
Devel
Wykonanie kodu Środowisko
developerskie i testowe
Change control Wymaga akceptacji
zgodnie z procedurą na
zmianę i wykonaniePrivate
branches
Devel
Test
Master
Kod dopuszczony
do DC
produkcyjnych
Kod dopuszczony
do DC testowych
Kod dopuszczony
do testowych
środowisk
developerskich
Branch zespołu
od ACLek

Zmiana kodu Zalgowany użytkownik
Operacja zmiany kodu Merge z Test jedynie
Wykonanie kodu Środowisko testowe,
środowisko produkcyjne
Change control Wymaga akceptacji
zgodnie z procedurą na
zmianę i wykonanie
Private
branches
Devel
Test
Master
Kod dopuszczony
do DC
produkcyjnych
Kod dopuszczony
do DC testowych
Kod dopuszczony
do testowych
środowisk
developerskich
Branch zespołu
od ACLek

NADZÓR NAD KODEM – WYKONANIE (I)
¢ Uruchomienie playbooka
— Inżynier programuje datę,
godzinę i parametry wywołania
playbooka
— Kod playbooka pobierany z
repozytorium GIT ze wskazanej
gałęzi tylko na czas działania
playbooka
GIT Server
Ansible/AWX
Server
Production DC

NADZÓR NAD KODEM – WYKONANIE (II)
— Akceptacja zgłoszenia wywołuje
zautomatyzowaną czynność
dodanie wykonania playbooka
wraz z parametrami na
wskazaną datę, godzinę
playbooka
GIT Server
Ansible/AWX
Server
Production DC

NADZÓR NAD KODEM – WYKONANIE (III)
— Akceptacja zgłoszenia wywołuje
zautomatyzowaną czynność dodanie
wykonania playbooka wraz z
parametrami na wskazaną datę,
godzinę
playbooka
— Po implementacji uruchamiany jest
zestaw automatycznych testów
potwierdzający jej skuteczność czy
brak wpływu na inne mechanizmy
GIT Server
Ansible/AWX
Server
Production DC

¢ „Jak zbierać i wyświetlać
dane w playbookach
Ansible”
30.10.2018 (wtorek)
godz. 10:00

NADZÓR NAD INFRASTRUKTURĄ

¢ Rekomendowany sposób -
KONTENERY!
¢ Docker
— Izolacja
— Bezpieczeństwo (gdy jest
prawidłowo skonfigurowany)
— Upraszcza zarządzanie
aplikacjami

¢ Docker – jak nie zrobić sobie
kuku:
— Wszędzie używaj
docker-compose, a pliki
konfiguracyjne trzymaj na GIT i
poddawaj kontroli zmian
— Własne repozytorium obrazów
(docker registry)
— Sam buduj obrazy!

NADZÓR NAD INFRASTRUKTURĄ – OBRAZY
¢ VMware Harbor – darmowa
aplikacja repozytorium
obrazów Dockera (odpowiednik
Docker Registry)
— Działa w kontenerach
— Łatwy w instalacji
— Kontrola dostępu
— Podpisywanie i skan security w
pakiecie
— Prostszy w obsłudze niż Docker
Registry
Vmware Harbor + Clair + Notary

¢ Budujmy własne obrazy
możliwie od podstaw
¢ Jeżeli chcemy wykorzystać
oficjalne obrazy na przykład z
Docker Hub to wykonajmy ich
kopię do naszego repozytorium
¢ Zawsze weryfikuj sumy
kontrolne
Vmware Harbor + Clair + Notary

NADZÓR NAD INFRASTRUKTURĄ – BUDOWA OBRAZÓW
¢ Proces budowy powinien być
zautomatyzowany – Jenkins!
¢ Budujmy obrazy cyklicznie
nawet jeżeli nie będziemy ich
wykorzystywali
¢ Staraj się aby punktem wyjścia
dla obrazu kontenera był
Linux Alpine

NADZÓR NAD INFRASTRUKTURĄ – BUDOWA OBRAZÓW
¢ Kod projektu budującego
kontener przechowuj na
repozytorium i poddaj takiej
samej regule kontroli zmian
¢ Dodaj testy akceptacyjne
GIT Server

NADZÓR NAD INFRASTRUKTURĄ – WYKORZYSTANIE OBRAZÓW
¢ Twórz kontenery w zależności
od potrzeby
¢ Korzystaj z obrazów z
własnego repozytorium
¢ Sprawdzaj sumy kontrolne
¢ Stosuj wszystkie dobre
praktyki związane z
kontenerami

PODSUMOWANIE

RÓŻA BEZ KOLCÓW?
¢ Automatyzacja infrastruktury i zadań w każdym środowisku wymaga:
— Nauczenia inżynierów odpowiedzialnych za infrastrukturę pracy nad kodem
takiej samej jak wykonują programiści
— Wprowadzenia nowych lub modyfikacji istniejących mechanizmów kontroli
— Dostosowania procedur i parametrów bezpieczeństwa – przeniesienie ciężaru
akceptacji z każdorazowego akceptowania czynności czy kodu do akceptacji
wykonania zatwierdzonego i zabezpieczonego kodu z repozytorium
— Wdrożenia środowiska testowego
— Wdrożenia narzędzi weryfikujących działanie automatycznie wykonywanych
zadań
— Rozwiązanie musi być kompleksowe a nie punktowe

RÓŻA BEZ KOLCÓW?
¢ Dodatkowo tam gdzie występują szczególne warunki i przetwarzane są
szczególnie wrażliwe dane:
— Zapewnienie zgodności z wymaganiami certyfikacji
— Automatyzacja zadań audytowych
— Niektóre operacje nigdy nie będą mogły być poddane automatyzacji – należy
jednak zadbać by nie degradowały znacząco automatyzacji w innych
obszarach
— Wymaga starannej edukacji inżynierów wszystkich działów

CHCESZ WIEDZIEĆ WIĘCEJ?
¢ Jesienne webinaria!
— Szczegółowe spojrzenie na wybrane aspekty wdrażania automatyzacji i
programowania playbooków Ansible – z punktu widzenia sieciowca nie
zawodowego debvelopera
— Harmonogram już wkrótce na https://webinaria.proidea.pl/
— Możliwość zadawania pytań live, dostęp do nagrań archiwalnych

¢ Śledź mojego bloga - https://blog.it-playground.eu
— Opublikowane już artykuły z zakresu automatyzacji:
¢ Let Jenkins build the Jenkins image
¢ Run Jenkins in the container
¢ Repository with Docker templates
¢ Automated scripts can send commands faster than RP can process
¢ Dynamic inventory from GIT on AWX
¢ Why I use VMware Photon OS for Docker
¢ Container names and docker-compose
¢ Use Ansible to check SNMP on remote device
— Kolejne w przygotowaniu

Zapraszam do kontaktu i dyskusji na żywo czy przez social media
Lub mailowo: piotr [at] it-playground.pl
Piotr.Wojciechowski.CCIE
PiotrW_CCIE
Piotr Wojciechowski

Piotr.Wojciechowski.CCIE
PiotrW_CCIE
Piotr Wojciechowski
DZIĘKUJĘ ZA UWAGĘ

PLNOG 21: Piotr Wojciechowski - ANSIBLE_I_AUTOMATYZACJA_W_ŚRODOWISKACH_SZCZEGÓLNIE_CHRONIONYCH

Recommended

Recommended

More Related Content

Similar to PLNOG 21: Piotr Wojciechowski - ANSIBLE_I_AUTOMATYZACJA_W_ŚRODOWISKACH_SZCZEGÓLNIE_CHRONIONYCH

Similar to PLNOG 21: Piotr Wojciechowski - ANSIBLE_I_AUTOMATYZACJA_W_ŚRODOWISKACH_SZCZEGÓLNIE_CHRONIONYCH (20)

PLNOG 21: Piotr Wojciechowski - ANSIBLE_I_AUTOMATYZACJA_W_ŚRODOWISKACH_SZCZEGÓLNIE_CHRONIONYCH