Kto, gdzie i z jakim hasłem? Discovery · Config · Secrets

▶ Pierwszy dzień

1. zapisz 10.0.1.7Ktoś wpisuje adres serwisu B do pliku konfiguracyjnego serwisu A.
2. czytaj przy starcieSerwis A czyta plik raz, przy starcie.
3. GET /ordersDziała — B rzeczywiście jest pod 10.0.1.7.

💥 Autoskaling w nocy

1. węzeł znikaWęzeł z instancją B pada. Orkiestrator uruchamia B gdzie indziej.
2. B pod 10.0.9.3Nowa instancja B dostaje nowy adres. Plik o tym nie wie.
3. GET /ordersA dalej strzela w stary adres: timeout. Ktoś musi ręcznie zmienić plik i zrestartować A.
4. potrzebny rejestrWniosek: adres trzeba odkrywać w chwili wywołania, z miejsca, które śledzi żywe instancje. To jest service discovery.

▶ Client-side

1. rejestruję sięInstancja (albo platforma za nią) wpisuje swój adres do rejestru.
2. lista instancji?Klient pyta rejestr o instancje serwisu i trzyma wynik w cache.
3. wybór instancjiKlient sam wybiera instancję (round robin, least requests, strefa). Logika jest w bibliotece lub sidecarze.
4. żądanie bezpośrednioRuch idzie prosto do instancji — bez dodatkowego hopu.

▶ Server-side

1. rejestracjaInstancja trafia do rejestru (najczęściej robi to platforma: third-party registration).
2. żądanie na stały adresKlient zna tylko jeden stabilny adres (DNS load balancera lub wirtualny IP).
3. kto żyje?Load balancer zna zdrowe instancje z rejestru lub własnych health checków.
4. przekazanieLoad balancer przekazuje żądanie. Klient może być „głupi” i w dowolnym języku.

▶ Normalnie

1. A? ordersKlient pyta lokalny resolver o orders.internal.
2. brak w cacheResolver nie ma odpowiedzi, więc pyta serwer autorytatywny.
3. A, B · TTL 30 sSerwer zwraca adresy A i B z TTL. Resolver trzyma je w cache przez TTL.
4. połączenieKlient wybiera adres (zwykle pierwszy z listy) i łączy się.

💥 Instancja A pada

1. A umieraInstancja A znika. Serwer DNS wkrótce usuwa jej rekord (jeśli ma health check).
2. A? ordersResolver ma jeszcze ważną odpowiedź w cache: dalej zwraca A i B.
3. timeoutKlient łączy się z martwym A. Do wygaśnięcia TTL część ruchu trafia w próżnię — chyba że klient ma retry na inny adres.
4. po TTL tylko BPo wygaśnięciu cache resolver pobiera świeżą odpowiedź. Krótszy TTL skraca okno, ale zwiększa liczbę zapytań.

▶ Rejestracja i śmierć

1. grant lease TTL 10 sInstancja uwierzytelnia się (mTLS lub token) i dostaje lease z TTL.
2. put klucz + leaseInstancja zapisuje swój adres pod kluczem przypiętym do lease.
3. replikacjaLider zatwierdza zapis dopiero, gdy potwierdzi go większość węzłów.
4. event PUTKlient z watchem na prefiksie /services/orders/ dostaje nowy adres.
5. instancja zamarzaInstancja przestaje odnawiać lease (keep-alive).
6. event DELETEPo TTL lease wygasa, a klucz znika. Klient dostaje DELETE i usuwa adres z puli.

💥 Podział sieci

1. partycjaLider zostaje w mniejszości (np. 1 z 3 węzłów).
2. put → błądLider w mniejszości nie zbierze quorum, więc zapis nie przechodzi. Nowa instancja nie zarejestruje się po tej stronie.
3. nowy liderWiększość wybiera nowego lidera i dalej przyjmuje zapisy.
4. ostatni znany stanKlienci mają w pamięci ostatnią listę. Dobra biblioteka używa jej dalej, zamiast zerować pulę.

▶ Normalnie

1. registerInstancja rejestruje się w jednym z serwerów (self-registration przez bibliotekę klienta).
2. replikacja asyncSerwer przekazuje wpis do pozostałych serwerów. Do zakończenia replikacji serwery mogą widzieć różne stany.
3. heartbeat co 30 sInstancja odnawia lease.
4. fetch delta co 30 sKlient pobiera zmiany z dowolnego serwera i zapisuje je w lokalnym cache.
5. wywołanie z cacheKlient wybiera instancję z lokalnej kopii — nawet gdy Eureka chwilowo nie odpowiada.

💥 Podział sieci

1. heartbeaty ginąPołowa heartbeatów nie dociera. Wygląda, jakby połowa floty umarła.
2. self-preservationLiczba odnowień spadła poniżej progu, więc serwer wstrzymuje usuwanie wpisów.
3. część wpisów martwaKlient może trafić na naprawdę martwą instancję — dlatego potrzebuje timeoutów i retry na inną instancję.
4. ale ruch płynieAlternatywa (wyrzucić połowę floty z rejestru) byłaby gorsza: zdrowe instancje straciłyby ruch.

▶ Pod staje się gotowy

1. pod ReadyKubelet raportuje, że readiness probe przechodzi.
2. EndpointSlice += podKontroler dopisuje adres poda (ready) do EndpointSlice serwisu.
3. watch EndpointSlicekube-proxy na każdym węźle obserwuje zmiany i aktualizuje reguły jądra.
4. DNS → ClusterIPKlient rozwiązuje nazwę serwisu przez CoreDNS i dostaje stały ClusterIP.
5. ruch → podReguły jądra na węźle klienta zamieniają ClusterIP na adres jednego z gotowych podów.

💥 Readiness pada

1. pod NotReadyReadiness probe przestaje przechodzić (np. pod jest przeciążony).
2. endpoint ready=falseKontroler oznacza endpoint jako niegotowy. ClusterIP i DNS się nie zmieniają.
3. reguły bez podakube-proxy usuwa poda z puli. Nowe połączenia omijają go; pod nie jest restartowany (to robi liveness).

▶ Normalnie

1. watch Service/EndpointSliceControl plane obserwuje serwisy i endpointy.
2. CSR + token SAAgent obok proxy A tworzy klucz prywatny i wysyła CSR z poświadczeniami (w Kubernetesie: token konta usługi). istiod weryfikuje poświadczenia i podpisuje krótko żyjący certyfikat z tożsamością SPIFFE.
3. xDS: CDS/EDS/LDS/RDSControl plane przesyła strumieniem gRPC klastry, endpointy, listenery i trasy.
4. mTLS handshakeProxy A i B wymieniają certyfikaty i sprawdzają nawzajem tożsamość.
5. AuthorizationPolicyProxy B sprawdza politykę: czy tożsamość A może wołać tę ścieżkę.
6. localhostDopiero teraz żądanie trafia do aplikacji B.

💥 Control plane padł

1. istiod niedostępnyControl plane nie działa.
2. brak nowych zmianDokumentacja Istio: proxy niepołączone z istiod nie dostaje żadnej nowej konfiguracji. Certyfikaty odnawia agent okresowo u CA (domyślnie istiod), więc długa awaria grozi ich wygaśnięciem.

▶ Normalnie

1. DNS nazwy serwisuA rozwiązuje nazwę DNS serwisu Lattice z sieci VPC powiązanej z siecią serwisów (service network).
2. żądanie z SigV4A podpisuje żądanie swoimi tymczasowymi poświadczeniami roli IAM (Signature Version 4).
3. ewaluacja politykiLattice sprawdza auth policy: czy ten principal może wywołać tę usługę i ścieżkę.
4. routing do celuLattice kieruje żądanie do zdrowego celu (instancja, kontener, Lambda).

💥 Obcy principal

1. żądanie bez uprawnieńInny serwis (inna rola) próbuje wołać B.
2. denyPolityka nie zezwala na ten principal. Lattice odrzuca żądanie, zanim dotrze do B.

▶ Deploy

1. obraz + manifestCI publikuje jeden obraz. Manifest środowiska zawiera wartości, np. DB_POOL_SIZE=20.
2. start z envOrkiestrator uruchamia proces z ustawionym środowiskiem.
3. odczyt przy starcieAplikacja czyta zmienne raz, przy starcie, i waliduje je (fail fast przy złej wartości).

💥 Zmiana w biegu

1. nowa wartośćOperator chce zmienić DB_POOL_SIZE na 40.
2. proces nie widziŚrodowisko działającego procesu nie zmienia się z zewnątrz.
3. rolling restartZmiana wymaga nowego deployu. Zaleta: zmiana przechodzi przez ten sam pipeline co kod.

▶ Montaż jako wolumen

1. kubectl applyOperator zmienia ConfigMapę. RBAC sprawdza, czy może edytować obiekty w tym namespace.
2. syncKubelet przy okresowej synchronizacji zauważa nową wersję.
3. nowe plikiKubelet aktualizuje pliki w wolumenie. Dokumentacja mówi, że klucze są aktualizowane „ostatecznie” (eventually) — nie natychmiast.
4. reloadAplikacja musi sama wykryć zmianę pliku (watch na katalog) i przeładować konfigurację.

💥 ConfigMap jako env

1. kubectl applyTa sama zmiana.
2. stara wartośćKontener ma środowisko z chwili startu. Pody działają ze starą wartością, aż do restartu.
3. rollout restartTypowe rozwiązanie: wymusić rolling update po każdej zmianie ConfigMapy, np. adnotacją z hashem konfiguracji w szablonie poda.

▶ Start i odświeżenie

1. pobranie konfiguracjiInstancja pobiera konfigurację swojej aplikacji i profilu (domyślnie przy starcie), uwierzytelniając się w serwerze (np. HTTP Basic lub OAuth2).
2. git fetchSerwer czyta pliki z repozytorium (gałąź lub tag = wersja).
3. merge zmianyKtoś merguje PR ze zmianą timeoutu. Review i historia są w Git.
4. /actuator/busrefreshWebhook z repozytorium (np. przez endpoint /monitor) albo operator wyzwala odświeżenie na szynie.
5. refresh na każdej instancjiKażda instancja dostaje zdarzenie odświeżenia: czyści cache RefreshScope i ponownie wiąże @ConfigurationProperties.

💥 Config Server leży przy starcie

1. serwer niedostępnyAwaria serwera konfiguracji.
2. start bez konfiguracjiNowa instancja nie dostaje konfiguracji. Z fail-fast nie wystartuje; bez niego użyje wartości lokalnych.
3. działające instancje OKUruchomione instancje mają konfigurację w pamięci. Dlatego serwer konfiguracji uruchamia się w kilku replikach, a klient ma retry.

▶ Udane wdrożenie

1. nowa wersjaOperator z uprawnieniami IAM tworzy nową wersję konfiguracji.
2. walidacjaAppConfig uruchamia walidator. Zła składnia lub wartość spoza zakresu zatrzymuje wdrożenie, zanim cokolwiek się stanie.
3. StartDeploymentWdrożenie ze strategią, np. liniowo co kilka minut, z czasem obserwacji (bake time) na końcu.
4. GetLatestConfigurationAplikacje (lub AppConfig Agent obok nich) pobierają konfigurację. Każda instancja niezależnie sprawdza stan wdrożenia, więc nowa wersja trafia do rosnącej części klientów.
5. alarmy OKAlarmy są zielone przez cały rollout, więc wdrożenie się kończy.

💥 Błędy po zmianie

1. część klientów ma nową wersjęRollout jest w toku.
2. błędy rosnąOdsetek błędów 5xx przekracza próg alarmu.
3. ALARMAppConfig monitoruje alarm przypisany do środowiska.
4. rollbackAppConfig automatycznie cofa wdrożenie; klienci wracają do poprzedniej wersji przy kolejnym odpytaniu.

▶ Włączenie dla 10%

1. init z kluczem SDKSDK łączy się z serwisem flag kluczem SDK po stronie serwera i pobiera wszystkie reguły.
2. rollout 10%Produkt ustawia flagę new-checkout na 10% użytkowników. Zmiana ma autora w logu audytu.
3. stream: zmiana regułySerwis wysyła nową regułę do SDK.
4. żądanie użytkownikaAplikacja pyta SDK o flagę dla użytkownika.
5. hash(user) → bucketSDK liczy lokalnie: hash klucza użytkownika daje stały bucket, więc ten sam użytkownik zawsze dostaje ten sam wariant.

💥 Serwis flag niedostępny

1. awariaSerwis flag nie odpowiada.
2. ostatnie regułySDK ewaluuje na ostatnich znanych regułach z pamięci.
3. zimny start → defaultNowa instancja bez połączenia dostaje wartość domyślną z kodu. Wartość domyślna musi być bezpieczna (zwykle: funkcja wyłączona).

▶ Zmiana

1. źródło + kompilacjaInżynier zmienia źródło konfiguracji. Kompilator generuje JSON, a walidator sprawdza niezmienniki.
2. review i commitZmiana przechodzi code review. Git zapisuje autora i historię.
3. automatyczny canaryUsługa canary wdraża zmianę na małą grupę serwerów, potem większą, i porównuje metryki z grupą kontrolną.
4. dystrybucjaPo udanym canary zmiana idzie przez Zeus i obserwatory do proxy na serwerach.
5. odczyt lokalnyAplikacja dostaje nową wartość z lokalnego proxy.

💥 Centrala niedostępna

1. proxy bez połączeniaProxy traci kontakt z obserwatorami.
2. cache na dyskuAplikacja dalej czyta ostatnią konfigurację z lokalnego cache. Awaria systemu konfiguracji nie zatrzymuje produkcji.

▶ Zdrowa zmiana

1. schema + testyWalidacja składni, typów i reguł biznesowych. Test, czy kod czytający konfigurację przyjmie nową wartość.
2. canaryZmiana trafia do małej części floty. Metryki porównuje się z grupą kontrolną.
3. jeden regionPo czasie obserwacji zmiana rozszerza się na jeden region (jedna domena awarii).
4. globalnieDopiero na końcu wszystkie regiony.

💥 Zła wartość

1. przechodzi walidacjęWartość jest poprawna składniowo, ale wywołuje błąd w nowym kodzie.
2. canary chorujeWzrost błędów w grupie canary.
3. auto-rollbackSystem cofa zmianę. Ucierpiał tylko 1% floty, a nie wszystkie regiony.

▶ Pierwsze uruchomienie

1. tożsamośćPlatforma wydaje serwisowi krótko żyjący, podpisany dowód tożsamości (np. token konta usługi albo poświadczenia roli).
2. login dowodemSerwis loguje się do managera tym dowodem. Manager weryfikuje podpis u wystawcy.
3. sekret o krótkim TTLManager wydaje sekret zgodnie z polityką dla tej tożsamości.
4. użycieSerwis łączy się z bazą.
5. rotacjaPrzed wygaśnięciem manager rotuje sekret; serwis pobiera nowy.

💥 Wyciek

1. sekret w loguSekret wycieka (np. do logów).
2. odwołanieManager odwołuje sekret; krótki TTL i tak ograniczał okno ataku.

▶ Zapis i montaż

1. create SecretRBAC sprawdza prawo tworzenia Secretów w namespace.
2. szyfrowanie DEKAPI server szyfruje dane lokalnym kluczem danych (DEK).
3. DEK zaszyfrowany KEKPlugin KMS szyfruje DEK kluczem z zewnętrznego KMS (KEK nigdy nie opuszcza KMS).
4. szyfrogram w etcdW etcd ląduje szyfrogram i zaszyfrowany DEK. Kopia zapasowa etcd sama w sobie nie zdradza sekretu.
5. kubelet pobieraKubelet dostaje Secret tylko dla podów na swoim węźle (Node authorizer).
6. tmpfsSecret montowany jako wolumen trafia do tmpfs (pamięć), a nie na dysk węzła.

💥 Bez szyfrowania w spoczynku

1. base64 w etcdSecret leży w etcd jako czytelne dane.
2. wyciek backupuWyciek kopii zapasowej etcd = wyciek wszystkich Secretów klastra.

▶ Normalnie

1. login: rola + JWTPod wysyła do Vaulta token swojego konta usługi i nazwę roli.
2. TokenReviewVault pyta API Kubernetesa, czy token jest ważny, i sprawdza, czy konto usługi i namespace pasują do roli.
3. token Vaulta + politykiVault wydaje token z TTL i politykami przypisanymi do roli.
4. read database/creds/ordersPod prosi o poświadczenia do bazy.
5. CREATE ROLE … VALID UNTILVault tworzy w bazie nowego użytkownika według szablonu SQL z roli.
6. user/hasło + lease 1 hPod dostaje unikalne poświadczenia z lease.

💥 Lease wygasa / wyciek

1. hasło w loguPoświadczenia wyciekły albo pod zniknął bez odnowienia lease.
2. revokePo wygaśnięciu lease (lub ręcznym vault lease revoke) Vault usuwa użytkownika z bazy. Wyciek dotyczy jednego poda i ma termin ważności.

▶ Rotacja według harmonogramu

1. createSecretFunkcja generuje nowe hasło i zapisuje je jako wersję z etykietą AWSPENDING.
2. setSecretFunkcja ustawia nowe hasło w bazie.
3. testSecretFunkcja sprawdza, czy nowe hasło działa.
4. finishSecretEtykieta AWSCURRENT przechodzi na nową wersję, a stara dostaje AWSPREVIOUS.
5. GetSecretValue (cache)Aplikacja z rolą IAM pobiera bieżącą wersję, zwykle przez bibliotekę z cache odświeżanym co jakiś czas.

💥 Aplikacja z hasłem w pamięci

1. stare hasłoW strategii jednego użytkownika stare hasło przestaje działać po rotacji. Aplikacja z hasłem w pamięci dostaje błędy logowania.
2. ponów z nowymRozwiązanie: przy błędzie uwierzytelnienia pobierz sekret ponownie albo użyj strategii naprzemiennych użytkowników (dwa konta, rotowane na zmianę).

▶ External Secrets Operator

1. odczyt (rola operatora)Operator, według SecretStore i ExternalSecret, czyta sekret tożsamością przypisaną do SecretStore.
2. zapis SecretOperator tworzy lub aktualizuje Secret w Kubernetesie.
3. env / wolumenPod używa zwykłego Secretu — bez zmian w aplikacji.
4. refreshIntervalOperator cyklicznie synchronizuje zmiany (np. po rotacji).

▶ Secrets Store CSI Driver

1. start podaKubelet montuje wolumen CSI zdefiniowany przez SecretProviderClass.
2. odczyt tożsamością podaDostawca pobiera sekret, zwykle tożsamością (workload identity) tego poda.
3. plik w wolumenieSekret trafia jako plik do wolumenu poda. Bez synchronizacji nie powstaje kopia w etcd.

▶ Normalnie

1. kubesealDeveloper szyfruje Secret kluczem publicznym kontrolera. Domyślnie szyfrogram jest związany z nazwą i namespace.
2. commit SealedSecretDo repozytorium trafia tylko szyfrogram.
3. syncNarzędzie GitOps aplikuje SealedSecret do klastra.
4. odszyfrowanieKontroler odszyfrowuje kluczem prywatnym i tworzy zwykły Secret.

💥 Kopiowanie do innego namespace

1. ten sam szyfrogram, inny namespaceKtoś kopiuje SealedSecret do namespace, do którego nie powinien mieć sekretu.
2. odmowaW domyślnym zakresie (strict) odszyfrowanie się nie uda, bo nazwa i namespace są częścią szyfrowania.

▶ Szyfrowanie

1. GenerateDataKeyAplikacja z uprawnieniem IAM do klucza prosi KMS o klucz danych.
2. DEK jawny + DEK zaszyfrowanyKMS zwraca DEK w dwóch postaciach.
3. AES-GCM lokalnieAplikacja szyfruje dane jawnym DEK i od razu usuwa go z pamięci.
4. zapis: szyfrogram + zaszyfrowany DEKZapisywane jest tylko to, co bez KMS jest bezużyteczne.

▶ Odszyfrowanie

1. odczytAplikacja czyta szyfrogram i zaszyfrowany DEK.
2. Decrypt(DEK)KMS sprawdza IAM i politykę klucza, loguje operację i zwraca jawny DEK.
3. odszyfrowanie lokalneAplikacja odszyfrowuje dane.

💥 Kradzież bazy

1. dump bazyAtakujący kradnie magazyn: ma szyfrogramy i zaszyfrowane DEK.
2. brak dostępu do KMSBez uprawnień do klucza w KMS nie odszyfruje DEK, więc dane są bezużyteczne. Odebranie uprawnień do klucza „wyłącza” dostęp do wszystkich danych naraz.

▶ EKS IRSA

1. projektowany token SAKubelet montuje w podzie krótko żyjący token konta usługi z audience dla STS, podpisany przez klaster.
2. AssumeRoleWithWebIdentitySDK AWS wysyła token do STS. STS weryfikuje podpis przez dostawcę OIDC klastra i warunki zaufania roli (namespace i konto usługi).
3. poświadczenia tymczasoweSTS zwraca poświadczenia roli z terminem wygaśnięcia. SDK odświeża je samo.
4. wywołanie APIPod woła np. S3 lub Secrets Manager. Żaden klucz dostępu nie istnieje.

▶ SPIFFE / SPIRE

1. atestacja węzłaAgent SPIRE udowadnia serwerowi SPIRE, na jakim węźle działa (np. przez dokument tożsamości instancji chmury).
2. Workload API (gniazdo Unix)Proces pyta lokalnego agenta o tożsamość — bez żadnego hasła.
3. atestacja workloaduAgent sprawdza, kim jest proces (np. namespace, konto usługi i obraz z kubeleta).
4. X.509-SVIDProces dostaje certyfikat z SPIFFE ID, np. spiffe://acme.com/ns/prod/sa/orders, rotowany automatycznie przed wygaśnięciem.
5. mTLS / federacjaCertyfikatem robi mTLS z innym serwisem; JWT-SVID może służyć do federacji z chmurą.