Mam podstawowy obraz dokera, który służy do uruchamiania oprogramowania do analizy obrazu. Dla każdego kontenera utworzonego z obrazu istnieje zestaw ustawień konfiguracyjnych, z których niektóre są tajne (klucze szyfrowania, informacje o kliencie itp.), Które są używane przez oprogramowanie do analizy i dystrybucji przetworzonych obrazów. Jak mogę bezpiecznie przekazać te tajemnice do kontenera?

Masz 3 metody na uzyskanie tajemnic do aplikacji w kontenerze dokera. Pierwsze 2 dotyczą konfiguracji dokera. Ostatnim jest, aby Twoje aplikacje bezpośrednio pobierały sekrety z tajnego sklepu.

1 - Zmienne środowiskowe

Zgodnie z przewodnikiem „The 12 Factor App” sekrety są jedynie konfiguracją i zawsze powinny być ustawione w środowisku. Możesz ustawić swoje sekrety jako zmienne środowiskowe podczas uruchamiania dokera, a aplikacja będzie od nich uzyskiwać dostęp.

2 - Zamontowane woluminy

Możesz mieć swoje sekrety w jednym pliku konfiguracji / sekretów, a następnie zamontować je w instancji jako zamontowany wolumin .

3 - Pobierz z tajnego sklepu

Jak wspomniano w @ 030, możesz korzystać z Hashicorp Vault (lub „Amazon Secrets Manager” lub dowolnej podobnej usługi).
Twoja aplikacja lub aplikacja pomocnicza może pobrać sekrety, których potrzebuje bezpośrednio, bez konieczności zajmowania się jakąkolwiek konfiguracją kontenera Docker. Ta metoda pozwoliłaby Ci korzystać z dynamicznie tworzonych sekretów (bardzo atrakcyjna funkcja takich systemów) i bez obawy, że sekrety będą widoczne z systemu plików lub ze sprawdzenia zmiennych env kontenera dokera.

Osobista opinia

Wierzę, że zmienne env to droga. Łatwiej jest nim zarządzać i nadal możesz pobierać z tajnego sklepu, takiego jak Hashicorp Vault, jeśli masz system kompilacji CI, wyciągaj sekrety podczas kompilacji i ustaw je podczas wdrażania. Dostajesz to, co najlepsze z obu światów, a także dodatkową korzyść dla programistów, którzy nie muszą pisać kodu aplikacji w celu uzyskania tajemnic. Deweloperzy powinni skupić się na swojej funkcjonalności kodu, a nie na zadaniach administracyjnych, takich jak pobieranie haseł.

Kod aplikacji powinien koncentrować się na samej funkcjonalności aplikacji, a nie na zadaniach zaplecza, takich jak pobieranie haseł. Podobnie jak w przypadku 12 aplikacji Factor.

Edycja: zmieniono ostatnie zdanie, aby usunąć wpływ silosu na programistę vs SysAdmin. Same zadania powinny być oddzielone od perspektywy kodu, ale DevOps dotyczy tych samych osób, pamiętając o nich i nie ograniczając się do nich.

Osobista opinia (aktualizacja)

Według doskonałego komentarza @ Dirka ( Przekazywanie tajemnic do kontenera Docker ) istnieje bardzo silny argument, aby nadać priorytet tajnemu sklepowi nad zmiennymi ENV, ponieważ nie chce się ich ujawniać.

Jest inna opcja tylko przy użyciu potoku:

docker run -d -i --name $n alpine sh -c 'read A; echo "[$A]"; exec some-server'
docker exec -i $n sh -c 'cat > /proc/1/fd/0' <<< _a_secret_

Najpierw utwórz demona dokera -i, polecenie read Azawiesi się, czekając na dane wejściowe z /proc/1/fd/0; Następnie uruchom drugie polecenie dokera, odczytując sekret ze standardowego wejścia i przekierowując do ostatniego zawieszającego się procesu.