Sekrety w chmurze

Nurtuje mnie pytanie dotyczące zarządzania sekretami.

Przypuśćmy, że mamy jakąś usługę (vaulta), w której sekrety (hasła,certyfikaty itp.) przechowywane są w sposób bezpieczny. Podnosimy kontener w ramach providera i te sekrety są udostępniane w kontenerze. Z tego co rozumiem, mogą być udostępniane jako zmienne środowiskowe widoczne wewnątrz kontenera, czy wolumeny, pliki z tym sekretem etc.
W każdym razie taki sekret robi się jawny wewnątrz kontenera i "wisi" przez okres życia tego kontenera.

Czy istnieją jakieś mechanizmy "cloud native", które udostępniałby te sekrety jednorazowo, tj. aplikacja czyta sekret przy rozruchu i taki sekret znika z kontenera?

A co gdy zrobisz restart kontenera?

Ja takich mechanizmów nie znam, od biedy pewnie mógłbyś spróbować skasować plik z wolumenu po tym jak apka go odczyta przy starcie.

Tylko przed czym wtedy tak na prawdę się chronisz? Bo jak zakładasz, że ktoś się wbije do kontenera i odczyta sekrety, to po wczytaniu ich do pamięci też pewnie jak ktoś zrobi dumpa to sobie je odczyta.

Na pewno mógłbyś po prostu programowo, z poziomu aplikacji odczytać ten sekret z usługi trzymającej sekrety - na pewno AWS Parameter Store (czy teraz nowy Secrets Manager) ma taką opcję, po cli czy po HTTP czy z SDK jakiegoś języka. Ewentualnie zaczytać go w jakimś sidecarze (jeśli mowa o k8s) jeśli nie chcesz wiązać aplikacji z infrą za bardzo.

Sekret nie musi wisieć jako env ciągle - po prostu jest to często wygodne dla aplikacji/frameworka i się to stosuje. Pytanie co w sytuacji jak się kontener zrestartuje, albo aplikacja odpyta vaulta dwukrotnie.

some_ONE napisał(a):

Ja takich mechanizmów nie znam, od biedy pewnie mógłbyś spróbować skasować plik z wolumenu po tym jak apka go odczyta przy starcie.

Jak wolumen będzie montowany jako read-only, to kasowanie pliku raczej się nie uda.

Tylko przed czym wtedy tak na prawdę się chronisz? Bo jak zakładasz, że ktoś się wbije do kontenera i odczyta sekrety, to po wczytaniu ich do pamięci też pewnie jak ktoś zrobi dumpa to sobie je odczyta.

Rozważam teoretycznie w ramach dokształcania się z clouda :-) Taki sekret przecież nie musiałby być trzymany w pamięci, tylko np. okazany raz przy nawiązaniu połączenia, czy przy dostępnie do keystora. Coś na zasadzie walletu otwieranego raz w ramach sesji (tu sesja trwałaby przez czas działania kontenera).

Takie zabezpieczenie przed odczytaniem sekretów można ogarnąć via SE Linux policy, pozwalające na odczyt /etc/my-sweet-secret tylko procesom X użytkownika Y, a procesy X pozwalać uruchamiać tylko z entry pointa. No ale to SELinux, a nie rozwiązania cloud native, a tu głównie o takie mi chodzi w ramach poszerzania wiedzy.