Maison > Questions et réponses > le corps du texte
P粉3995850242023-08-28 11:42:57
Docker a beaucoup changé depuis que cette question a été posée, voici donc une tentative de mise à jour de la réponse.
Tout d'abord, en particulier pour les informations d'identification AWS sur les conteneurs déjà exécutés dans le cloud, utiliser un rôle IAM comme Vor recommande est vraiment un bon choix. Si vous pouvez le faire, ajoutez un plus un à sa réponse et ignorez le reste.
Une fois que vous commencez à exécuter des choses en dehors du cloud ou que vous possédez différents types de secrets, je vous déconseille de stocker les secrets à deux endroits clés :
Variables d'environnement : lorsque ces variables sont définies sur un conteneur, tous les processus du conteneur peuvent y accéder, elles sont visibles via /proc, les applications peuvent vider leur environnement sur la sortie standard et le stocker dans le journal. Et mieux encore, lorsque vous inspectez le conteneur, ils apparaissent en texte clair.
Dans l'image elle-même : les images sont souvent transférées vers des registres où de nombreux utilisateurs ont un accès en extraction, parfois sans aucune information d'identification requise pour extraire l'image. Même si vous supprimez le secret d'une couche, l'image peut être désassemblée avec des utilitaires Linux courants comme. tar et le secret peut être trouvé dès l'étape où il a été ajouté pour la première fois à l'image.
Alors, quelles autres options existe-t-il pour les secrets dans les conteneurs Docker ?
Option A : Si vous n'avez besoin de cette clé que lors de la création de l'image, que vous ne pouvez pas l'utiliser avant le démarrage de la construction et que vous n'avez pas encore accès à BuildKit, Construction en plusieurs étapes est la meilleure mauvaise option. Vous pouvez ajouter le secret à l'étape initiale de la construction, l'utiliser ici, puis copier la sortie de cette étape sans le secret dans votre étape de publication et transmettre uniquement cette étape de publication au serveur de registre. Le secret est toujours dans le cache d'images sur le serveur de build, j'ai donc tendance à ne l'utiliser qu'en dernier recours.
Option B : Également pendant la construction, si vous pouvez utiliser la version 18.09 de BuildKit, il existe actuellement une fonctionnalité expérimentalequi permet une injection secrète en tant que montage de volume pour une seule ligne d'exécution. Le montage n'écrit pas sur la couche d'image, vous pouvez donc accéder au secret pendant la construction sans vous soucier de son transfert vers le serveur de registre public. Le Dockerfile généré ressemble à ceci :
# syntax = docker/dockerfile:experimental FROM python:3 RUN pip install awscli RUN --mount=type=secret,id=aws,target=/root/.aws/credentials aws s3 cp s3://... ...
Vous pouvez le construire à l'aide des commandes de la version 18.09 ou supérieure, par exemple :
DOCKER_BUILDKIT=1 docker build -t your_image --secret id=aws,src=$HOME/.aws/credentials .
Option C : Lors de l'exécution sur un seul nœud, sans mode Swarm ou autre orchestration, vous pouvez monter les informations d'identification en tant que volume en lecture seule. L'accès à ces informations d'identification nécessite le même accès que l'accès au même fichier d'informations d'identification en dehors de Docker, ce n'est donc ni meilleur ni pire que la situation sans Docker. L'essentiel est que le contenu de ce fichier ne doit pas être visible lorsque vous inspectez le conteneur, affichez les journaux ou transférez l'image vers le serveur de registre, car dans chaque cas, il se trouve en dehors du volume. Cela nécessite que vous copiez les informations d'identification sur l'hôte Docker, indépendamment du déploiement du conteneur. (Notez que toute personne ayant la possibilité d'exécuter un conteneur sur cet hôte peut afficher vos informations d'identification, car l'accès à l'API Docker se fait avec root sur l'hôte et root peut afficher les fichiers de n'importe quel utilisateur. Si vous ne faites confiance à personne sur l'hôte utilisateur root, alors ne leur donnez pas l'accès à l'API Docker)
Pour un docker run, cela ressemble à :
docker run -v $HOME/.aws/credentials:/home/app/.aws/credentials:ro your_image
Ou pour composer un document il vous faut :
version: '3'
services:
app:
image: your_image
volumes:
- $HOME/.aws/credentials:/home/app/.aws/credentials:ro
Option D : Avec le mode Swarm et des outils d'orchestration comme Kubernetes, nous disposons désormais d'un meilleur support pour les secrets que pour les volumes. Avec le mode Swarm, les fichiers sont chiffrés sur le système de fichiers du gestionnaire (bien que la clé de déchiffrement soit généralement également présente, permettant au gestionnaire d'être redémarré sans que l'administrateur saisisse la clé de déchiffrement). De plus, le secret est uniquement envoyé au travailleur qui en a besoin (pour exécuter le conteneur avec ce secret), il est uniquement stocké dans la mémoire du travailleur, pas sur le disque, et il est injecté sous forme de fichier dans le conteneur avec tmpfs. Les utilisateurs sur des hôtes extérieurs à l'essaim ne peuvent pas monter le secret directement dans leurs propres conteneurs. Cependant, avec un accès ouvert à l'API Docker, ils peuvent extraire le secret des conteneurs en cours d'exécution sur le nœud, limitant ainsi à nouveau qui a accès au secret. API. D'après composer, cette injection secrète ressemble à :
version: '3.7'
secrets:
aws_creds:
external: true
services:
app:
image: your_image
secrets:
- source: aws_creds
target: /home/user/.aws/credentials
uid: '1000'
gid: '1000'
mode: 0700
Vous activez le mode essaim avec docker swarm init for a single node, then follow the directions for adding additional nodes. You can create the secret externally with docker secret create aws_creds $HOME/.aws/credentials. And you deploy the compose file with docker stack deploy -c docker-compose.yml stack_name.
J'utilise souvent le script suivant pour versionner mes secrets : https://github.com/sudo-bmitch/docker-config-update
Option E : Il existe d'autres outils pour gérer les secrets, mon préféré est Vault en raison de sa capacité à créer des secrets limités dans le temps qui expirent automatiquement. Chaque application obtient ensuite son propre ensemble de jetons pour demander des secrets, ce qui leur permet de demander ces secrets à durée limitée si elles peuvent atteindre le serveur du coffre-fort. Cela réduit le risque si un secret est retiré de votre réseau, car soit il ne fonctionnera pas, soit il expirera rapidement. Les fonctionnalités spécifiques d'AWS pour Vault sont documentées sur https://www.vaultproject.io /docs/secrets/aws/index.html
P粉5236250802023-08-28 10:29:34
La meilleure façon est d'utiliser les rôles IAM et de ne pas gérer du tout les informations d'identification. (Voir http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html)
Les informations d'identification peuvent être récupérées à partir de http://169.254.169.254..... Puisqu'il s'agit d'une adresse IP privée, elle ne peut être accessible qu'à partir des instances EC2
Toutes les bibliothèques clientes AWS modernes « savent » comment obtenir, actualiser et utiliser les informations d'identification à partir de là. Ainsi, dans la plupart des cas, vous n’avez même pas besoin de le savoir. Exécutez simplement ec2 avec le rôle IAM correct.
En option, vous pouvez les transmettre au moment de l'exécution en tant que variables d'environnement (c'est-à-dire docker run -e AWS_ACCESS_KEY_ID=xyz -e AWS_SECRET_ACCESS_KEY=aaa myimage)
Vous pouvez accéder à ces variables d'environnement en exécutant printenv dans le terminal.