Konfiguracja, hasła i Vault

01

1. Co należy umieścić w .env

• Adres URL usługi, wybór trybu, strefa czasowa, nazwy baz danych i inne parametry niebędące tajne.
• Pełny odnośnik do obrazu ze streszczeniem, jeśli plik jest komponentem objętym kontrolą wydania.
• Zmiany funkcji, które wersja wyraźnie obsługuje i weryfikuje.
• Nigdy nie umieszczaj swojego prawdziwego hasła, klucza prywatnego, tokena dostępu, tajnego klucza klienta ani loginu do rejestru w pliku wersjonowanym Git.

02

2. Zalecany układ na hoście

/etc/sifybox/
├── env/
│   ├── release.env       # image + digest, bez hesel
│   └── site.env          # URL, režimy a nesekretní parametry
└── secrets/              # root:root, adresář 0700, soubory 0400
    ├── db_password
    └── oidc_client_secret

Uwaga: Plik .env nie jest menedżerem sekretów. Logowanie do rejestru jest obsługiwane przez pomocnika ds. poświadczeń lub zarządzane logowanie do Dockera z tokenem wdrażania; sam sekret Compose nie autoryzuje pobierania obrazów. Wartości wrażliwe pozostają poza Gitem, z minimalnymi uprawnieniami i opisaną rotacją.

03

3. Wariant sekretów Dockera

Standard docelowy — nazwy plików i obsługa zmiennych _FILE muszą zostać potwierdzone w manifeście konkretnej wersji.

1. DERS dostarczy listę oczekiwanych sekretów i potwierdzoną metodę ich pobierania.
2. Administrator tworzy każdy sekret poza procesem realizacji transakcji i ustala właściciela oraz uprawnienia.
3. Compose doda klucz tajny tylko do usługi, która go potrzebuje.
4. Aplikacja nie może drukować wartości podczas uruchamiania lub w przypadku wystąpienia błędu walidacji.
5. Rotacja odbywa się zgodnie z podręcznikiem usługi i jest weryfikowana przez nowe logowanie lub połączenie.

04

4. Wariant HashiCorp Vault

Standard docelowy — metoda uwierzytelniania, odnawiania dzierżawy i doładowywania musi zostać potwierdzona przez konkretną usługę i wydanie.

1. Usługa lub agent Vault uwierzytelnia się przy użyciu tożsamości maszyny powiązanej ze określonym środowiskiem. Nie korzysta ze współdzielonego tokena osobistego.
2. Polityka ta będzie zezwalać wyłącznie na określone ścieżki i operacje niezbędne dla danej usługi.
3. Agent Vault zapisuje klucz tajny do pliku tmpfs lub udostępnia go aplikacji za pośrednictwem obsługiwanego mechanizmu.
4. Przywrócenie danych krótkoterminowych spowoduje ponowne uruchomienie lub kontrolowane ponowne uruchomienie.
5. Audyt skarbca, audyt aplikacji i dzienniki operacyjne są korelowane bez zapisywania samej wartości tajnej.

05

5. Kolejność ładowania i walidacji

1. Załaduj domyślne wartości wbudowane w wydanie tylko dla opcji nieobjętych klauzulą ​​tajności.
2. Załaduj release.env i site.env.
3. Pobieraj sekrety z plików lub Skarbca; wartość sekretu nigdy nie ma bezpiecznej, uniwersalnej wartości domyślnej.
4. Jeśli brakuje obowiązkowej wartości, zakończ przed rozpoczęciem od nazwy parametru, a nie jego zawartości.
5. Wydrukuj oczyszczone podsumowanie konfiguracji: tryb, adres URL docelowy, wersję i źródło tajnego klucza, ale nie sam klucz.
6. Dopiero potem przeprowadź testy łączności i zaakceptuj wymagania operacyjne.

06

6. Rotacja bez ręcznego przepisywania

• Każdy sekret ma właściciela, źródło, datę ważności i metodę odzyskiwania.
• Dane Dynamic Vault są objęte umową dzierżawy i automatycznym odnawianiem.
• Tajemnice klienta OIDC są zmieniane poprzez nałożenie starych i nowych wartości, jeśli jest to obsługiwane przez dostawcę tożsamości i aplikację.
• Rotacja awaryjna przebiega według własnej procedury i jest niezależna od osoby, która pierwotnie dokonała instalacji.
• Po rotacji weryfikowana jest funkcja usługi i audyt; stara wartość jest unieważniana dopiero po potwierdzeniu.