Klaster uruchomiony w domyślnej konfiguracji działa poprawnie i jest otwarty. Zamykamy go, nie psując tego, co na nim stoi.
Zmiany wprowadzamy etapami, żeby nie zatrzymać tego, co już działa.
Tak wygląda punkt wyjścia w wielu firmach, które dowożą szybko i podlegają regulacjom.
Kubernetes wstaje szybko i działa od razu — dlatego konfiguracja z pierwszego dnia często zostaje na lata. Kontenery chodzą z nadmiarowymi uprawnieniami, ruch między nimi jest nieograniczony, a nikt nie kontroluje, jaki obraz wolno uruchomić.
Zakres ustalamy po diagnozie — zaczynamy od elementu, który najszybciej obniży Wasze ryzyko.
Zamykamy klaster, nie psując tego, co na nim działa.
Przeglądamy konfigurację klastra — uprawnienia, izolację przestrzeni nazw, dostęp do interfejsu zarządzania — i wskazujemy, co jest otwarte tylko dlatego, że tak było pierwszego dnia. Zamiast wyłapywać niebezpieczne wdrożenia ręcznie, wprowadzamy polityki, które blokują je automatycznie. Ruch między usługami ograniczamy do tego, co rzeczywiście musi się komunikować, żeby przejęcie jednego kontenera nie otwierało drogi do reszty. Na końcu włączamy wykrywanie w czasie działania — sygnał, gdy w kontenerze dzieje się coś, czego tam nigdy nie było.
Po każdym etapie zostaje u Was konkretny rezultat, a nie notatka ze spotkania.
Uprawnienia, izolacja przestrzeni nazw, dostęp do interfejsu zarządzania.
RezultatLista tego, co jest otwarte tylko dlatego, że tak było pierwszego dnia
Reguły, które automatycznie blokują niebezpieczne wdrożenia — zamiast wyłapywać je ręcznie.
RezultatPolityki, które same zatrzymują niebezpieczne wdrożenia
Usługa rozmawia tylko z tym, z czym rzeczywiście musi.
RezultatReguły ruchu: każda usługa rozmawia tylko z tym, z czym musi
Sygnał, gdy w kontenerze dzieje się coś, czego tam nigdy nie było.
RezultatAlerty, gdy w kontenerze dzieje się coś, czego tam nigdy nie było
Wdrożenie kończy się działającą konfiguracją i dowodami, a nie raportem z listą zaleceń. Tak to wygląda na przykładzie.
# niebezpieczne wdrożenie zostaje odrzucone
apiVersion: v1
kind: Namespace
metadata:
name: platnosci
labels:
pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/enforce-version: latestKontener z uprawnieniami roota nie wystartuje — nikt nie musi go wyłapywać ręcznie.
| Z | Do | Port |
|---|---|---|
| frontend | api | 8443 |
| api | baza danych | 5432 |
| api | kolejka | 5672 |
| pozostały ruch | — | zablokowany |
Przejęcie jednej usługi nie otwiera drogi do całej reszty.
Sygnał przychodzi w chwili zdarzenia, a nie przy przeglądzie logów po fakcie.
Ilustracja. Zakres i narzędzia dobieramy po diagnozie.
Zakres ustalamy po rozmowie i diagnozie. Mniejsze wdrożenia zamykają się w kilku tygodniach, większe dzielimy na etapy, żeby efekt był widoczny po pierwszym.
Zwykle nie do całego. W większości przypadków wystarczy dostęp do konfiguracji procesu budowania i ustawień organizacji. Zakres ustalamy pisemnie przed startem.
Tak, ale nie na pełen etat. Potrzebujemy kontaktu z osobą, która zna system, i przeglądu naszych zmian. Reszta jest po naszej stronie.
Wpinamy się w to, co u Was działa. Wymiana narzędzia to najdroższy i najrzadziej potrzebny sposób poprawy bezpieczeństwa.
Nie. Pracujemy na standardach i narzędziach, które Wasz zespół zna albo szybko pozna — nie na autorskiej metodyce, którą rozumiemy wyłącznie my. Wszystko jest udokumentowane i przekazane.
Tak wpinamy kontrole, żeby działały w tle. Jeśli któraś zaczyna blokować pracę, dostrajamy ją albo zmieniamy jej miejsce w procesie.