Udostępniasz plik Compose sieci VPN? Usuń sekrety z wyrenderowanej kopii

Za każdym razem, gdy udostępniasz plik Compose, istnieją dwa artefakty: ten, który napisałeś, i ten, który narzędzie renderuje po podstawieniu zmiennych. Drugi jest często wrażliwszy od pierwszego i to jego ludzie wklejają do zgłoszenia problemu bez czytania. Jeśli przeglądasz tylko plik źródłowy, przeglądasz niewłaściwy dokument.

Zanim zdecydujesz, co usunąć, porównaj, co może zawierać każda kopia.

Wyrenderowany model to inny dokument

Compose rozwiązuje zmienne środowiskowe, scala pliki nadpisujące i tworzy skuteczną konfigurację, której czytelnik nie potrafi już odróżnić od wartości zapisanych ręcznie. Odwołanie, na przykład nazwa zmiennej w źródle, staje się w danych wyjściowych samym tokenem konta. Struktura, która czyni plik użytecznym do diagnostyki, przeżywa tę transformację; przeżywa też wszystko, czego nigdy nie powinno w nim być.

Wyrenderuj plik samodzielnie, zanim go załączysz, i traktuj te dane wyjściowe jako artefakt podlegający przeglądowi. Jeśli nie możesz go wyrenderować, nie możesz wiedzieć, co zamierzasz opublikować.

Sekrety tkwią w więcej miejscach niż w polu klucza

Zacznij od oczywistości: kluczy prywatnych, kluczy wcześniej udostępnionych, tokenów, haseł i adresów URL połączeń, które zawierają dane uwierzytelniające. Potem spójrz na wszystko, na co wskazuje plik, bo odwołanie nie jest redakcją. Plik środowiskowy zamontowany w usłudze, plik konfiguracyjny podłączony z hosta, etykieta niosąca token i argument polecenia zawierający hasło podróżują razem z wdrożeniem nawet wtedy, gdy YAML wygląda czysto. Klucz wklejony do zmiennej o uspokajającej nazwie nadal jest kluczem.

Ścieżki hosta i nazwy usług ujawniają drugi rodzaj informacji. Nazwa katalogu domowego, wewnętrzna nazwa hosta lub zakres sieci mogą zidentyfikować osobę albo organizację bez ani jednych danych uwierzytelniających, a ten kontekst warto usunąć z tego samego powodu.

Deklaracja sekretu nie jest sekretem

Obiekty sekretów Compose oddzielają deklarację od materiału: usługa otrzymuje ścieżkę lub cel, a treść żyje gdzie indziej. Zachowanie deklaracji przy zastąpieniu materiału jest zwykle właściwą wymianą, bo recenzent musi zobaczyć, że sekret istnieje i jak jest zamontowany. To, co nie może przetrwać, to sama treść.

Etykiety i komentarze zasługują na takie samo traktowanie. Komentarz mówiący, która ścieżka w skarbcu przechowuje klucz produkcyjny, wskazuje atakującemu, gdzie patrzeć, nawet jeśli nie zawiera klucza.

Zachowaj kształt, aby plik nadal diagnozował

Redakcja, która usuwa tryb sieciowy, wersję obrazu lub ustawienia możliwości, daje plik, z którym nikt nie potrafi debugować. Zastąp wrażliwe wartości i zachowaj relacje: która usługa co montuje, do której sieci dołącza, jakiego urządzenia potrzebuje. To jest ta część, której czytelnik używa, aby wyjaśnić brakującą trasę lub niedostępne urządzenie. To także wersja, którą współpracownik może porównać z własnym działającym wdrożeniem.

docker compose -f compose.yaml config > rendered.yaml
grep -nE 'PRIVATE_KEY|PASSWORD|TOKEN|PSK|PrivateKey|passphrase' rendered.yaml
wc -l rendered.yaml

Nie wdrażaj zredagowanej kopii tak, jakby była działającym oryginałem. To opis, a opis zmieniony tak, by wyglądał bezpiecznie, zawiedzie w sposób przypominający błędy konfiguracji.

Jeśli materiał został ujawniony, wymień go

Usunięcie załącznika nie usuwa kopii, które inni już zrobili, a lustra i pamięci podręczne trzymają własne. Użyj procesu unieważnienia i wymiany wydawcy dla wszystkiego, co wyciekło, a następnie zaktualizuj wdrożenie. Kolejność ma znaczenie, bo wymiana najpierw i unieważnienie później zostawia okno z dwoma ważnymi danymi uwierzytelniającymi.

W wątkach pomocy zacznij od dokładnego błędu, wersji obrazu, trybu sieciowego i jednego nie-sekretnego ustawienia, które ma znaczenie. Ta kombinacja wyjaśnia brakujące urządzenie lub zepsutą trasę znacznie częściej niż klucz.