Gestion des informations d'identification de sécurité IAM pour plusieurs conteneurs Docker

11

Dans un environnement EC2 standard, la gestion de l'accès aux autres ressources AWS est assez simple avec les rôles et informations d'identification IAM (récupérés automatiquement à partir des métadonnées d'instance). Encore plus facile avec CloudFormation, où vous pouvez créer des rôles à la volée lorsque vous attribuez un rôle d'application particulier à une instance.

Si je voulais migrer vers Docker et avoir une sorte de déploiement M-to-N, où j'ai M machines et N applications en cours d'exécution, comment dois-je procéder pour restreindre l'accès aux ressources AWS par application? Les métadonnées d'instance sont accessibles par n'importe qui sur l'hôte, de sorte que chaque application puisse voir / modifier les données de toutes les autres applications dans le même environnement de déploiement.

Quelles sont les meilleures pratiques pour fournir des informations d'identification de sécurité aux conteneurs d'applications exécutés dans un tel environnement?

Alex B
la source

Réponses:

5

Il y a ce projet: https://github.com/dump247/docker-ec2-metadata

Il agit comme un proxy pour le point de terminaison des métadonnées d'instance, renvoyant un rôle spécifique au conteneur. Je ne l'ai pas utilisé auparavant, mais cela semble résoudre le cas d'utilisation que vous décrivez.

pbitty
la source
1

L'application du moindre privilège à l'aide de rôles et de groupes de sécurité (même si vous ne les avez pas mentionnés) dans AWS avec EC2 sont les deux meilleures pratiques pour fournir un environnement sécurisé pour vos applications d'hébergement, en particulier lorsque vous utilisez CloudFormation. Cependant, lorsque vous superposez un environnement Docker à locataires multiples, c'est lorsque les choses commencent à s'effondrer.

La meilleure réponse à l'heure actuelle pour continuer à bénéficier des rôles tout en appliquant le moindre privilège est de ne pas utiliser une approche multi-locataire. Utilisez essentiellement un mappage un à un entre l'instance EC2 et l'application, mais vous pouvez toujours utiliser des clusters / ASG. Docker est toujours un outil extrêmement utile et puissant que vous pouvez utiliser pour gérer et déployer vos applications, mais pour l'instant les rôles s'appliquent à l'instance EC2 et non au conteneur. Cela signifie utiliser pour l'instant des machines virtuelles distinctes pour chaque application.

Si être multi-locataire est plus important que les rôles, la réponse est de ne pas utiliser les rôles et de distribuer les informations d'identification AWS à vos applications à l'aide d'une autre méthode.

Malheureusement, aucune de ces solutions n'est très souhaitable et je m'attends à ce que ce problème spécifique soit résolu par AWS à l'avenir, principalement en raison de la popularité croissante des conteneurs.

JaredHatfield
la source