Sekrety w Docker Compose: zmienna środowiskowa może trafić do logów

Hasło lub token przekaż kontenerowi Docker Compose jako plik: zdefiniuj lokalne źródło w głównej sekcji secrets pliku compose.yaml, a dostęp przyznaj w sekcji secrets konkretnej usługi. Instrukcja Docker Compose opisuje montowanie przyznanego sekretu pod /run/secrets w kontenerze. Wartość nie musi wtedy znaleźć się w obrazie, kodzie ani zmiennej środowiskowej aplikacji. Przykład poniżej dotyczy kontenerów linuksowych.

Ta zmiana usuwa jedną drogę przypadkowego ujawnienia, lecz nie chroni sekretu przed każdym wyciekiem. Zalecenia OWASP wskazują, że sekrety przekazane przez zmienne środowiskowe mogą być dostępne procesom oraz trafiać do logów lub zrzutów systemowych. Po zamontowaniu pliku aplikacja musi odczytać go bez wypisywania zawartości w komunikatach diagnostycznych.

Przygotuj plik źródłowy

W przykładzie sekret nazywa się api_token, a jego wartość znajduje się w pliku ./secrets/api_token na hoście. To umowna nazwa i ścieżka: plik ma zawierać właściwy token, nie wpis z nazwą zmiennej. Przygotuj go przed uruchomieniem Compose. Nie zapisuj wartości w compose.yaml, pliku Dockerfile ani w repozytorium; jeśli katalog secrets leży w katalogu projektu, wyklucz go z kontroli wersji.

Ogranicz możliwość odczytu pliku na hoście do kont, które rzeczywiście go potrzebują. Dla pliku przeznaczonego wyłącznie dla właściciela przykładowe uprawnienia to 0600, a dla katalogu 0700. To ustawienie trzeba jednak pogodzić z tożsamością użytkownika, pod którym działa program w kontenerze: plik zamontowany z hosta musi być dla niego czytelny. Zbyt szeroki dostęp ujawni wartość innym użytkownikom hosta, a zbyt wąski uniemożliwi aplikacji odczyt.

Dodaj sekret do compose.yaml

Poniższa konfiguracja jest przykładem warunkowym. Zastąp twoja-aplikacja:tag własnym obrazem i zachowaj wcięcia; zawartość tokenu pozostaje wyłącznie w przygotowanym pliku źródłowym.

compose.yaml

services:

  api:

    image: twoja-aplikacja:tag

    secrets:

      - api_token

secrets:

  api_token:

    file: ./secrets/api_token

Główna sekcja secrets wiąże nazwę api_token z plikiem na hoście. Wpis pod usługą api nadaje tej usłudze dostęp do wartości pod ścieżką /run/secrets/api_token. W compose.yaml widoczna jest ścieżka do pliku, a nie token. Sama definicja na poziomie głównym nie montuje sekretu w żadnej usłudze; potrzebny jest również wpis przy usłudze, która ma z niego korzystać.

W tym wariancie nazwa pliku w kontenerze odpowiada nazwie sekretu. Dzięki temu aplikacja może otrzymać stałą ścieżkę, podczas gdy sposób dostarczenia pliku źródłowego na hosta pozostaje częścią procesu wdrożenia. Jeśli program oczekuje innej ścieżki, trzeba dostosować jego konfigurację albo użyć odpowiedniej definicji montowania.

Skieruj aplikację do /run/secrets

Samo zamontowanie pliku nie zmienia sposobu, w jaki program pobiera poświadczenie. Aplikacja powinna otworzyć /run/secrets/api_token i użyć odczytanej wartości do uwierzytelnienia. Jeżeli dotąd pobierała token ze zmiennej API_TOKEN, zmień jej konfigurację lub kod odpowiedzialny za odczyt. Kopiowanie zawartości pliku z powrotem do zmiennej środowiskowej procesu przywróci drogę ujawnienia, którą ta konfiguracja miała ograniczyć.

Niektóre obrazy przyjmują zmienną konfiguracyjną z końcówką _FILE, której wartością jest ścieżka, a nie sam sekret. Wtedy można wskazać /run/secrets/api_token, ale wyłącznie pod nazwą przewidzianą w dokumentacji danego obrazu. Przykładowe API_TOKEN_FILE nie jest uniwersalną funkcją Compose. Gdy obraz rozumie tylko zmienną zawierającą gotowy token, montowanie pliku nie wystarczy bez zmiany aplikacji lub sposobu jej uruchamiania.

Przyznaj dostęp każdej usłudze osobno

Jeżeli tokenu potrzebuje także worker, dodaj api_token do listy secrets tej usługi. Usługa bez takiego wpisu nie otrzyma montowania, choć sekret jest zdefiniowany w głównej części compose.yaml. W ten sposób dostęp można ograniczyć do kontenerów, których zadania naprawdę wymagają poświadczenia, zamiast udostępniać ten sam plik całemu zestawowi usług.

To rozdzielenie działa na poziomie usług, nie poszczególnych procesów wewnątrz kontenera. Proces z prawem odczytu zamontowanego pliku może poznać jego zawartość. Dlatego przy usłudze wykonującej kilka zadań trzeba uwzględnić również użytkownika procesu i uprawnienia systemu plików. Nie zastępuje to kontroli tego, co aplikacja robi z tokenem po jego odczytaniu.

Uwzględnij granice lokalnego pliku

Sekret ze źródłem file pozostaje plikiem na hoście. Specyfikacja usług Compose wyjaśnia, że przy takim źródle Compose używa montowania pliku hosta i ignoruje ustawienia uid, gid oraz mode podane przy sekrecie usługi. Sam wpis secrets nie szyfruje więc pliku źródłowego na dysku ani nie naprawia jego uprawnień. Ochrona katalogu, kopii zapasowych i dostępu do hosta pozostaje osobnym zadaniem.

Lokalny plik nie jest zarządzanym magazynem sekretów: deklaracja w Compose nie zapewnia automatycznej rotacji, audytu dostępu ani dostarczenia nowej wartości z zewnętrznego systemu. Jeśli token trafił już do historii repozytorium lub logów, przeniesienie go do pliku nie cofa ujawnienia. W takiej sytuacji rozważ unieważnienie starego tokenu i wydanie nowego, a także ograniczenie dostępu do miejsc, w których stara wartość została zapisana.

Po uruchomieniu usługi sprawdź możliwość odczytu /run/secrets/api_token bez wyświetlania jego zawartości; jeśli obraz zawiera odpowiednie narzędzie, wystarczy test prawa odczytu wykonany jako użytkownik aplikacji. Sprawdź też obsługę błędów i logowanie: program może wypisać poświadczenie już po pobraniu go z pliku. Montowanie ogranicza sposób przekazania wartości do kontenera, a bezpieczne użycie tej wartości zależy nadal od programu i ochrony hosta.

Przeczytaj także:

• Docker Compose czy Kubernetes? Wysoka dostępność ma koszt operacyjny
• Link „każdy, kto go ma” może wyciec — ogranicz dostęp do pliku
• GitHub wykrywa sekrety Lovable i Supabase — klucz może zniknąć szybciej