Sembra che l'approccio corretto per fornire segreti ai contenitori Docker sia discutibile. Questa domanda è la più vicina alla mia, a cui una persona ha risposto che le variabili di ambiente sono ok, ma un commento ha citato il Docker come dire il contrario.
Non abbiamo accesso alla funzionalità "segreti" di Docker, per quanto ne so.
Utilizziamo il servizio di contenitori elastici Amazon Services (ECS) di Amazon Web Services (AWS) con il tipo di lancio Fargate, che automatizza il ridimensionamento per noi. Stiamo memorizzando i segreti nel Parameter Store, all'interno dell'utilità di gestione dei sistemi di Amazon.
Ci sono due opzioni proposte:
- Abbassa i segreti non cifrati * come parte dell'avvio del processo. Questi valori verranno quindi inseriti nel file delle variabili di ambiente (.env) e importati nel processo al momento dell'avvio.
- Avvia il processo e carica i segreti al suo interno. Questo verrà fatto direttamente dall'SDK di AWS o tramite un altro dei nostri servizi autenticati.
La seconda opzione garantisce che i segreti rimangano nella memoria del processo, impedendo l'uso del flag inspect su una console Docker. Tuttavia, in entrambi i casi, non conosco abbastanza bene l'attuale configurazione di ECS per sapere quali vulnerabilità di sicurezza possono esistere se viene eseguita in questo modo. Voglio garantire la sicurezza dei miei segreti.
In entrambi i casi, questo verrà eseguito correntemente una volta, all'avvio del processo. La seconda opzione sarebbe utile per l'attivazione degli aggiornamenti, ma questa è una discussione diversa.
* So che potrei abbassare i valori crittografati nella prima opzione, quindi far sì che il processo utilizzi l'SDK di AWS per decrittografarli, ma a quel punto sembra meno lavoro (cpu + rete) fare l'opzione 2, con tutti i valori restituiti sono decrittografati.