Zmienne środowiskowe i sekrety aplikacji
Oddzielisz konfigurację od kodu, przygotujesz chroniony plik .env dla usługi systemd i nauczysz się sprawdzać konfigurację bez ujawniania sekretów.
1. Krótka teoria
Kod opisuje zachowanie aplikacji, a konfiguracja określa wartości zależne od środowiska, takie jak tryb pracy, adres bazy lub klucz używany do podpisywania danych. Zmienne środowiskowe są parami nazwa-wartość przekazywanymi procesowi. Sekret to wartość wymagająca szczególnej ochrony, na przykład hasło, token lub klucz. Nie należy zapisywać sekretów w repozytorium, ponieważ pozostają w historii Git nawet po usunięciu z bieżącego pliku. Plik /opt/example-app/.env może przechowywać konfigurację konkretnego serwera, a .env.example tylko nazwy wymaganych zmiennych i bezpieczne wartości przykładowe. Prawdziwy .env należy dodać do .gitignore. Plik na serwerze powinien należeć do użytkownika usługi i mieć uprawnienia 600. W jednostce systemd dyrektywa EnvironmentFile=/opt/example-app/.env wczytuje wartości bez umieszczania ich w ExecStart. Aplikacja powinna odczytać konfigurację przy starcie, sprawdzić wymagane pola i zakończyć się czytelnym błędem bez drukowania sekretu. Brak zmiennej, pusty ciąg i wartość o błędnym formacie to trzy różne przypadki, które wymagają osobnej walidacji. Po zmianie pliku trzeba zrestartować usługę, ponieważ działający proces zwykle nie odczyta go ponownie. Obecność zmiennej można sprawdzić przez grep -q, który zwraca kod wyjścia bez drukowania wartości. Rotacja sekretu polega na wygenerowaniu nowej wartości, bezpiecznym podmienieniu jej w źródle konfiguracji, restarcie usługi, weryfikacji działania i unieważnieniu starej wartości, gdy dany system to umożliwia. Plik .env jest prostym rozwiązaniem dla pojedynczego serwera, ale nie zapewnia centralnego audytu ani dystrybucji. Bardziej rozbudowane środowiska mogą używać zewnętrznych menedżerów sekretów.
2. Przykłady komend
sudo install -o example-app -g example-app -m 600 /dev/null /opt/example-app/.env
Tworzy pusty plik konfiguracji z ograniczonym dostępem i właściwym właścicielem.
$ sudo install -o example-app -g example-app -m 600 /dev/null /opt/example-app/.env
test -f /opt/example-app/.env
Sprawdza istnienie pliku bez wyświetlania jego zawartości.
$ test -f /opt/example-app/.env
grep -q '^SECRET_KEY=' /opt/example-app/.env
Sprawdza obecność wpisu SECRET_KEY wyłącznie przez kod wyjścia.
$ grep -q '^SECRET_KEY=' /opt/example-app/.env
sudo systemctl show example-app --property=EnvironmentFiles
Pokazuje, z jakiego pliku środowiskowego korzysta jednostka systemd.
$ sudo systemctl show example-app --property=EnvironmentFiles
sudo systemctl restart example-app
Uruchamia proces ponownie, aby odczytał zaktualizowaną konfigurację.
$ sudo systemctl restart example-app
sudo stat -c '%U %G %a' /opt/example-app/.env
Sprawdza właściciela, grupę i tryb pliku bez ujawniania sekretów.
$ sudo stat -c '%U %G %a' /opt/example-app/.env
example-app example-app 6003. Zadanie praktyczne
.env.example zawierający nazwy APP_ENV, DATABASE_URL i SECRET_KEY bez prawdziwego sekretu. Dodaj .env do .gitignore. Na serwerze utwórz /opt/example-app/.env z właścicielem example-app i trybem 600, a jako wartości laboratoryjne użyj APP_ENV=production, DATABASE_URL=sqlite:////opt/example-app/data/app.db i SECRET_KEY=change-me-in-production. Dodaj EnvironmentFile do przykładowej jednostki, zrestartuj usługę i sprawdź jedynie obecność wymaganych wpisów.
4. Typowe błędy
- Dodawanie prawdziwego pliku .env lub sekretu do repozytorium Git.
- Nadawanie plikowi .env zbyt szerokich uprawnień odczytu.
- Wpisywanie sekretu bezpośrednio w ExecStart jednostki systemd.
- Wyświetlanie pełnych wartości zmiennych w logach lub poleceniach diagnostycznych.
- Brak restartu usługi po zmianie konfiguracji środowiskowej.
- Traktowanie brakującej, pustej i błędnej wartości jako tego samego przypadku.
5. Podsumowanie
Konfiguracja zależna od środowiska powinna być oddzielona od kodu, a sekrety nie mogą trafiać do repozytorium ani logów. Plik .env na pojedynczym serwerze wymaga właściwego właściciela i trybu 600, natomiast .env.example dokumentuje wymagane nazwy. Systemd może wczytać plik przez EnvironmentFile, a po zmianie wartości usługę trzeba zrestartować i bezpiecznie zweryfikować.