Transmission de secrets à un conteneur Docker

26

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?

PrestonM
la source
Coffre Hashicorp
030

Réponses:

23

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.

BoomShadow
la source
2
Cela favorise les silos. DevOps fait des choses ensemble au lieu de jeter des choses par-dessus le mur.
030
2
Le code doit être séparé des composants de l'infrastructure. Les personnes réelles peuvent coder à la fois l'automatisation de l'infrastructure et la base de code de l'application, mais les tâches elles-mêmes doivent être distinctes. Je vois que la dernière phrase de ma réponse originale cloisonnait les développeurs, les gens. C'est une erreur. Je vais modifier cela pour être plus clair.
BoomShadow
7
Mettre des secrets dans des variables d'environnement offre diverses possibilités de fuite. Quelques exemples: Toute personne ayant accès au démon Docker sur la machine exécutant le conteneur peut les voir à l'aide des commandes inspectou exec. Les variables d'environnement sont souvent transférées vers stdoutou dans des fichiers journaux lors de l'exécution dans un mode de débogage. Tous les processus enfants générés peuvent les lire et les exposer, ce qui peut être hors de votre contrôle. Plus d'informations par exemple ici: diogomonica.com/2017/03/27/…
Dirk
1
Je suis également aux prises avec cette question. La chose que je ne comprends pas, c'est que même si vous utilisez un coffre d'informations d'identification pour sécuriser vos secrets, vous devez toujours vous authentifier pour accéder à ce coffre-fort, et cela nécessite probablement un secret. La même préoccupation s'applique à l'utilisation d'un fichier KeyStore protégé par mot de passe. Sommes-nous toujours coincés à passer au moins la «méta-accréditation» dans l'environnement?
Wheezil
1
@Wheezil, une méta-identification est plus facile à sécuriser que de nombreuses informations d'identification spécifiques. vous pouvez fréquemment et automatiquement faire pivoter les informations d'identification de méta. les informations d'identification méta peuvent aller vers un coffre-fort qui se trouve sur un hôte sécurisé et peuvent avoir des éléments tels que la liste blanche d'IP afin qu'il n'accepte que les connexions de vos sous-réseaux de production. vous pouvez également vous assurer que le coffre-fort utilise le chiffrement au repos et le chiffrement en vol et le tsl mutuel et l'épinglage de certificats et toutes les autres meilleures pratiques qui rendent les choses plus sécurisées.
simbo1905
1

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.

James ZM Gao
la source