Gestion de l'accès inter instance sur EC2

Question

Nous sommes en train de configurer notre infrastructure informatique sur Amazon EC2. Supposons une configuration le long des lignes de: serveurs de production X serveurs de mise en scène Y de classement du journal et Monitoring Server Création du serveur Il est évident que nous avons besoin d'avoir différents serveurs parler les uns aux autres. Une nouvelle version doit être ajoutée à un serveur de transfert. Le collecteur de journaux doit extraire les journaux des serveurs de production. Nous réalisons rapidement que nous avons des problèmes de gestion des clés d'accès. Chaque serveur a sa propre paire de clés et éventuellement son propre groupe de sécurité. Nous finissons par copier des fichiers * .pem d'un serveur à un autre, en se moquant de la sécurité. Le serveur de construction a les clés d'accès des serveurs de transfert afin de se connecter via ssh et de pousser une nouvelle construction. Les serveurs de mise en scène ont de même les clés d'accès des instances de production (gulp!) J'ai fait des recherches approfondies sur le net mais je n'ai pas vraiment trouvé quelqu'un parlant d'un moyen sensé de gérer ce problème. Comment les personnes ayant une configuration similaire à la nôtre traitent-elles ce problème? Nous savons que notre façon de travailler actuelle est mauvaise. La question est - quelle est la bonne façon? Appréciez votre aide! Merci

[Mise à jour] Notre situation est compliquée par le fait qu'au moins le serveur de construction doit être accessible à partir d'un serveur externe (en particulier, github). Nous utilisons Jenkins et le hook post commit nécessite une URL accessible au public. L'approche du bastion suggérée par @rook échoue dans cette situation.

Answer 1

Une très bonne méthode de gestion de l'accès à une collection d'instances EC2 est l'utilisation d'un Bastion Host.

Toutes les machines que vous utilisez sur EC2 doivent interdire l'accès SSH à Internet ouvert, à l'exception de l'hôte Bastion. Créez une nouvelle stratégie de sécurité appelée "Bastion Host" et autorisez uniquement le port 22 entrant du bastion à toutes les autres instances EC2. Toutes les clés utilisées par votre collection EC2 sont hébergées sur l'hôte du bastion. Chaque utilisateur a son propre compte sur l'hôte du bastion. Ces utilisateurs doivent s'authentifier auprès du bastion à l'aide d'un fichier clé protégé par mot de passe. Une fois qu'ils se connectent, ils devraient avoir accès à toutes les clés dont ils ont besoin pour faire leur travail. Lorsque quelqu'un est renvoyé, vous supprimez son compte d'utilisateur au bastion. Si un utilisateur copie des clés depuis le bastion, cela n'aura aucune importance, car il ne peut pas se connecter à moins d'être connecté au bastion.

Answer 2

Créez deux paires de clés, une pour vos serveurs de transfert et une pour vos serveurs de production. Vous pouvez donner aux développeurs les clés de transfert et garder les clés de production privées.

Je voudrais mettre les nouvelles constructions sur S3 et avoir un script Perl qui s'exécute sur les boîtes pour tirer le dernier code de vos seaux S3 et les installer sur les serveurs respectifs. De cette façon, vous n'avez pas à scp manuellement toutes les builds à chaque fois. Vous pouvez également automatiser ce processus en utilisant un certain type d'outils d'automatisation de génération continue qui créeraient et déverseraient la construction dans vos compartiments S3 respectivement. Espérons que cela aide ..