Quelle est la meilleure méthode pour transmettre les informations d'identification AWS en tant que données utilisateur à une instance EC2?

https://stackoverflow.com/questions/640838

22-07-2019
|

Question

J'ai une architecture de traitement de travail basée sur AWS qui nécessite la requête d'instances EC2 S3 et SQS. Pour que les instances en cours aient accès à l'API, les informations d'identification sont envoyées sous forme de données utilisateur (-f) sous la forme d'un script shell codé en base64. Par exemple:

$ cat ec2.sh
...
export AWS_ACCOUNT_NUMBER='1111-1111-1111'
export AWS_ACCESS_KEY_ID='0x0x0x0x0x0x0x0x0x0'
...
$ zip -P 'secret-password' ec2.sh
$ openssl enc -base64 -in ec2.zip

De nombreuses instances sont lancées ...

$ ec2run ami-a83fabc0 -n 20 -f ec2.zip

Chaque instance décode et décrypte ec2.zip en utilisant le 'mot de passe secret' qui est codé en dur dans un script init. Bien que cela fonctionne, mon approche pose deux problèmes.

'zip -P' n'est pas très sécurisé
Le mot de passe est codé en dur dans l'instance (c'est toujours 'mot de passe secret')

Cette méthode est très similaire à celle décrite ici

Existe-t-il une approche plus élégante ou acceptée? Utiliser gpg pour chiffrer les informations d'identification et stocker la clé privée sur l'instance pour la déchiffrer est une approche que je considère à présent, mais je ne suis au courant d'aucune mise en garde. Puis-je utiliser les paires de clés AWS directement? Me manque-t-il une partie super évidente de l'API?

La solution

Vous pouvez stocker les informations d'identification sur la machine (ou les transférer, les utiliser, puis les supprimer.)

Vous pouvez transférer les informations d'identification via un canal sécurisé (par exemple, en utilisant scp avec une authentification non interactive, par exemple, une paire de clés), de sorte que vous n'ayez pas à effectuer de chiffrement personnalisé (assurez-vous uniquement définir correctement à 0400 sur le fichier de clé à tout moment, par exemple, définir les autorisations sur les fichiers maîtres et utiliser scp -p )

Si ce qui précède ne répond pas à votre question, veuillez fournir des détails plus spécifiques concernant: quelle est votre configuration et ce que vous essayez d'atteindre. Les actions EC2 doivent-elles être initiées sur plusieurs nœuds à partir d’un emplacement central? SSH est-il disponible entre les multiples nœuds et l'emplacement central? Etc.

MODIFIER

Avez-vous envisagé de paramétrer votre AMI , ce qui oblige ceux qui instancient votre AMI à renseigner d’abord les données utilisateur ( ec2-run-instances -f fichier-données-utilisateur ) avec leurs clés AWS? Votre AMI peut ensuite extraire dynamiquement ces paramètres par instance à partir de http://169.254.169.254/1.0/user-data .





  MISE À JOUR  

 OK, voici une comparaison sécurisée des différentes approches discutées jusqu'à présent: 


 Sécurité des données lorsque  est enregistré dans l'AMI  données utilisateur  non crypté 


  faible  
 les données en texte clair sont accessibles à  tout  utilisateur qui parvient à se connecter à l'AMI et a accès à  telnet ,  curl ,  wget , etc. (peut accéder au texte en clair  http://169.254.169.254/1.0/user-data ) 

 vous êtes vulnérable aux attaques par demandes de proxy (par exemple, l'attaquant demande à Apache qui peut ou non s'exécuter sur l'AMI de récupérer et de transférer le texte en clair  http://169.254.169.254/1.0/user-data ) 
 

 Sécurité des données lorsque  est enregistré dans l'AMI  données utilisateur  et crypté (ou déchiffrable) avec une clé facile à obtenir 


  faible  
 clé facilement accessible (mot de passe) peut inclure:


 clé codée en dur dans un script à l'intérieur d'une ABI (où une ABI peut être obtenue par un attaquant) 
 clé codée en dur dans un script sur l'AMI elle-même, où le script est lisible par  tout utilisateur  qui parvient à se connecter à l'AMI 
 toute autre information facilement accessible, telle que des clés publiques, etc. 
 toute clé privée (sa clé publique peut être facilement obtenue) 
 
 étant donné une clé facile à obtenir (mot de passe), les mêmes problèmes identifiés au point 1 s'appliquent, à savoir:


 les données déchiffrées sont accessibles à  tout  utilisateur qui parvient à se connecter à l'AMI et a accès à  telnet ,  curl ,  wget , etc. (peut accéder au texte en clair  http://169.254.169.254/1.0/user-data ) 

 vous êtes vulnérable aux attaques par demandes de proxy (par exemple, l'attaquant demande à Apache qui peut ou non s'exécuter sur l'AMI de récupérer et de transférer le  http://169.254.169.254/1.0/user-data , décrypté ultérieurement avec la clé facile à obtenir) 
 

 

 Sécurité des données lorsque  est enregistré dans l'AMI  données utilisateur  et crypté avec une clé difficile à obtenir 


  moyenne  
 les données cryptées sont accessibles à  tout  utilisateur qui parvient à se connecter à l'AMI et a accès à  telnet ,  curl ,  wget , etc. (peut accéder au  crypté http://169.254.169.254/1.0/user-data )


 une tentative de déchiffrement des données chiffrées peut ensuite être effectuée à l'aide d'attaques par force brute 
 

 

 Sécurité des données lorsque  est stocké sur l'AMI, dans un emplacement sécurisé  (aucune valeur ajoutée pour qu'elle soit cryptée



	
					
			
			


	
			


	
			
						 Autres conseils
			
			
	
		
	
	
			 J'ai écrit un article sur différentes méthodes permettant de transmettre des secrets à une instance EC2 de manière sécurisée, ainsi qu'aux utilisateurs pros & amp; les inconvénients de chacun. 

  http: // www.shlomoswidler.com/2009/08/how-to-keep-your-aws-credentials-on-ec2.html  
	


	
		
	
	
			 Le meilleur moyen consiste à utiliser les  profils d'instance . L'idée de base est la suivante: 


 Créer un profil d'instance 
 Créer un nouveau rôle IAM 
  Attribuez une stratégie au rôle précédemment créé, par exemple: 

 {
  " Statement " ;: [
    {
      "Sid": "Stmt1369049349504",
      "Action": "sqs: ",
      "Effet": "Autoriser",
      "Ressources": ""
    }
  ]
} 
 
  Associez le profil de rôle et d'instance. 
 
 Lorsque vous démarrez une nouvelle instance EC2, veillez à fournir le nom du profil d'instance. 


 Si tout fonctionne correctement et que la bibliothèque que vous utilisez pour vous connecter aux services AWS à partir de votre instance EC2 prend en charge la récupération des informations d'identification à partir des métadonnées de l'instance, votre code pourra utiliser les services AWS. 

 Un exemple complet tiré de la liste de diffusion de boto-utilisateur: 

 Tout d'abord, vous devez créer un document de stratégie JSON qui représente les services et les ressources auxquels le rôle IAM doit avoir accès. Par exemple, cette stratégie accorde toutes les actions S3 pour le compartiment "my_bucket". Vous pouvez utiliser la stratégie appropriée pour votre application. 

BUCKET_POLICY = """{
  "Statement":[{
    "Effect":"Allow",
    "Action":["s3:*"],
    "Resource":["arn:aws:s3:::my_bucket"]}]}"""


 Ensuite, vous devez créer un profil d'instance dans IAM. 

import boto
c = boto.connect_iam()
instance_profile = c.create_instance_profile('myinstanceprofile')


 Une fois que vous avez le profil d'instance, vous devez créer le rôle, ajouter le rôle au profil d'instance et associer la stratégie au rôle. 

role = c.create_role('myrole')
c.add_role_to_instance_profile('myinstanceprofile', 'myrole')
c.put_role_policy('myrole', 'mypolicy', BUCKET_POLICY)


 Vous pouvez maintenant utiliser ce profil d'instance lorsque vous lancez une instance: 

ec2 = boto.connect_ec2()
ec2.run_instances('ami-xxxxxxx', ..., instance_profile_name='myinstanceprofile')
	


	
		
	
	
			 Je tiens à souligner qu'il n'est plus nécessaire de fournir des informations d'identification à votre instance EC2. À l'aide d'IAM, vous pouvez créer un rôle pour vos instances EC2. Dans ces rôles, vous pouvez définir des stratégies détaillées permettant à votre instance EC2 d'obtenir, par exemple, un objet spécifique à partir d'un compartiment S3 spécifique, sans plus. Vous pouvez en savoir plus sur les rôles IAM dans les documents AWS: 

  http://docs.aws.amazon.com/IAM/ latest / UserGuide / WorkingWithRoles.html  
	


	
		
	
	
			 Comme d'autres l'ont déjà souligné ici, vous n'avez pas vraiment besoin de stocker les informations d'identification AWS pour une instance EC2, à l'aide des rôles IAM -
  https: // aws .amazon.com / blogs / security / une-voie plus sûre pour-distribuer-aws-credentials-to-ec2 / .
J'ajouterai que vous pouvez également utiliser la même méthode pour stocker de manière sécurisée les  informations d'identification NON-AWS  pour votre instance EC2, comme si vous disposiez de certaines informations d'identification de base de données que vous souhaitez protéger. Vous enregistrez les informations d'identification non-aws sur un Bukcet S3 et utilisez le rôle IAM pour accéder à ce compartiment.
vous pouvez trouver des informations plus détaillées à ce sujet ici -  https://aws.amazon.com/blogs/security/using-iam-roles-to-distribute-non-aws-credentials-to -your-ec2-instances/ / a> 
	


			

		

			



	
		
			Licencié sous: CC-BY-SA avec attribution
			Non affilié à StackOverflow