J'ai une image Docker de base qui est utilisée pour exécuter un logiciel d'analyse d'image. Pour chaque conteneur créé à partir de l'image, il existe un ensemble de paramètres de configuration dont certains sont secrets (clés de chiffrement, informations client, etc.) qui sont utilisés par le logiciel pour analyser et distribuer les images traitées. Comment puis-je transmettre ces secrets en toute sécurité à un conteneur?

Vous disposez de 3 méthodes pour obtenir des secrets sur une application dans un conteneur Docker. Les 2 premiers impliquent une configuration de docker. La dernière consiste à demander à vos applications de récupérer directement les secrets d'une boutique secrète.

1 - Variables d'environnement

Selon le guide "The 12 Factor App" , les secrets ne sont que des configurations et doivent toujours être définis dans l'environnement. Vous pouvez définir vos secrets comme variables d'environnement pendant l'exécution du docker et votre application y accède à partir de là.

2 - Volumes montés

Vous pouvez avoir tous vos secrets dans un fichier de configuration / secrets particulier, puis le monter sur votre instance en tant que volume monté .

3 - Récupérer dans un magasin secret

Comme @ 030 l'a mentionné, vous pouvez utiliser Hashicorp Vault (ou «Amazon Secrets Manager», ou tout autre service comme celui-ci).
Votre application ou une application sidecar peut récupérer directement les secrets dont elle a besoin, sans avoir à gérer de configuration sur le conteneur Docker. Cette méthode vous permettrait d'utiliser des secrets créés dynamiquement (une caractéristique très attrayante de ces systèmes) et sans avoir à vous soucier des secrets pouvant être visualisés à partir du système de fichiers ou à inspecter les variables env du conteneur Docker.

Opinion personnelle

Je crois que les variables env sont la voie à suivre. C'est plus facile à gérer, et vous pouvez toujours tirer depuis un magasin secret comme Hashicorp Vault, si vous avez votre système de build CI récupérer les secrets pendant la build et les définir lors du déploiement. Vous obtenez le meilleur des deux mondes et l'avantage supplémentaire de vos développeurs n'ayant pas besoin d'écrire du code d'application pour récupérer des secrets. Les développeurs doivent se concentrer sur leur fonctionnalité de code, et non sur les tâches d'administration telles que la récupération des mots de passe.

Le code de votre application doit se concentrer sur sa propre fonctionnalité d'application elle-même, et non sur les tâches back-end comme la récupération des mots de passe. Tout comme l'indique l'application 12 Factor.

Edit: modification de la dernière phrase pour supprimer l'implication de Developer vs SysAdmin silo-ing. Les tâches elles-mêmes doivent être séparées du point de vue du code, mais DevOps concerne les mêmes personnes en gardant à l'esprit les deux et sans être limité.

Opinion personnelle (mise à jour)

Selon l'excellent commentaire de @ Dirk ( Passer des secrets à un conteneur Docker ), il y a un argument très fort pour donner la priorité à un magasin secret sur les vars ENV, car il ne veut pas les divulguer.

Il existe une autre option utilisant uniquement pipe:

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_

Tout d'abord, créez le démon docker avec -i, la commande read Ase bloquera en attendant l'entrée de /proc/1/fd/0; Exécutez ensuite la deuxième commande docker, en lisant le secret de stdin et redirigez-le vers le dernier processus suspendu.