¿Cuál es el mejor método para pasar las credenciales de AWS como datos de usuario a una instancia EC2?

Question

Tengo una arquitectura de procesamiento de trabajos basada en AWS que requiere consultas de instancias EC2 S3 y SQS. Para que las instancias en ejecución tengan acceso a la API, las credenciales se envían como datos de usuario (-f) en forma de un script de shell codificado en base64. Por ejemplo:

$ 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

Se lanzan muchas instancias ...

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

Cada instancia decodifica y descifra ec2.zip usando la 'contraseña secreta' que está codificada en un script de inicio. Aunque funciona, tengo dos problemas con mi enfoque.

1. 'zip -P' no es muy seguro
2. La contraseña está codificada en la instancia (siempre es 'contraseña secreta')

El método es muy similar al descrito aquí

¿Hay un enfoque más elegante o aceptado? Usar gpg para cifrar las credenciales y almacenar la clave privada en la instancia para descifrarlo es un enfoque que estoy considerando ahora, pero no estoy al tanto de ninguna advertencia. ¿Puedo usar los pares de claves de AWS directamente? ¿Me estoy perdiendo alguna parte súper obvia de la API?

Answer 1

Puede almacenar las credenciales en la máquina (o transferirlas, usarlas y luego eliminarlas)

Puede transferir las credenciales a través de un canal seguro (por ejemplo, usando scp con autenticación no interactiva, por ejemplo, par de claves) para que no necesite realizar ningún cifrado personalizado (solo asegúrese de que los permisos sean configurado correctamente en 0400 en el archivo de clave en todo momento, por ejemplo, configure los permisos en los archivos maestros y use scp -p )

Si lo anterior no responde a su pregunta, proporcione detalles más específicos re. cuál es su configuración y qué está tratando de lograr. ¿Se deben iniciar acciones EC2 en múltiples nodos desde una ubicación central? ¿SSH está disponible entre los múltiples nodos y la ubicación central? Etc.

---

EDIT

¿Ha considerado parametrizando su AMI , requiriendo aquellos que instancian su ¿Primero AMI para completar los datos del usuario ( ec2-run-instancia -f user-data-file ) con sus claves AWS? Su AMI puede recuperar dinámicamente estos parámetros por instancia de http://169.254.169.254/1.0/user-data .

---

UPDATE

Bien, aquí va una comparación con mentalidad de seguridad de los diversos enfoques discutidos hasta ahora:

1. Seguridad de datos cuando se almacenan en los datos de usuario de AMI sin cifrar
   • low
   • los datos de texto claro son accesibles para cualquier usuario que logre iniciar sesión en el AMI y tenga acceso a telnet , curl , wget , etc. (puede acceder a texto claro http://169.254.169.254/1.0/user-data )
   • usted es vulnerable a los ataques de solicitud de proxy (por ejemplo, el atacante le pide al Apache que puede o no estar ejecutándose en la AMI que obtenga y reenvíe el texto claro http://169.254.169.254/1.0/user-data )
2. Seguridad de los datos cuando se almacenan en los datos de usuario de AMI y se cifran (o descifran) con una clave fácilmente obtenible
   • low
   • la clave (contraseña) fácilmente obtenible puede incluir:
     • clave codificada en un script dentro de un ABI (donde el atacante puede obtener el ABI)
     • clave codificada en un script en el AMI en sí, donde el script puede ser leído por cualquier usuario que logre iniciar sesión en el AMI
     • cualquier otra información fácilmente obtenible, como claves públicas, etc.
     • cualquier clave privada (su clave pública puede obtenerse fácilmente)
   • dada una clave (contraseña) fácil de obtener, se aplican los mismos problemas identificados en el punto 1, a saber:
     • los datos descifrados son accesibles para cualquier usuario que logre iniciar sesión en el AMI y tenga acceso a telnet , curl , wget , etc. (puede acceder a texto claro http://169.254.169.254/1.0/user-data )
     • usted es vulnerable a los ataques de solicitud de proxy (por ejemplo, el atacante le pide al Apache que puede o no ejecutarse en el AMI que obtenga y reenvíe el cifrado http://169.254.169.254/1.0/user-data, descifrado posteriormente con la clave fácil de obtener)
3. Seguridad de los datos cuando se almacenan en los datos de usuario de AMI y se cifran con una clave que no se puede obtener fácilmente
   • aproceso
   • los datos encriptados son accesibles para cualquier usuario que logre iniciar sesión en el AMI y tenga acceso a telnet , curl , wget , etc. (puede acceder a encriptado http://169.254.169.254/1.0/user-data )
     • se puede intentar descifrar los datos cifrados utilizando ataques de fuerza bruta
4. Seguridad de los datos cuando se almacenan en el AMI, en una ubicación segura (sin valor agregado para que se cifre

Answer 2

Escribí un artículo que examina varios métodos para pasar secretos a una instancia de EC2 de forma segura y los pros & amp; contras de cada uno.

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

Answer 3

La mejor manera es usar perfiles de instancia . La idea básica es:

• Crear un perfil de instancia
• Crear un nuevo rol de IAM

• Asigne una política a la función creada anteriormente, por ejemplo:

  {   " Declaración " ;: [     {       " Sid " ;: " Stmt1369049349504 " ;,       " Acción " ;: " sqs: " ;,       " Efecto " ;: " Permitir " ;,       " Recurso " ;: " "     }   ] }

• Asociar el rol y el perfil de instancia juntos.

• Cuando inicie una nueva instancia EC2, asegúrese de proporcionar el nombre del perfil de la instancia.

Si todo funciona bien y la biblioteca que usa para conectarse a los servicios de AWS desde su instancia EC2 admite la recuperación de las credenciales de los metadatos de la instancia, su código podrá usar los servicios de AWS.

Un ejemplo completo tomado de la lista de correo del usuario botánico:

Primero, debe crear un documento de política JSON que represente a qué servicios y recursos debe tener acceso el rol de IAM. por ejemplo, esta política otorga todas las acciones de S3 para el depósito "my_bucket". Puede usar cualquier política que sea apropiada para su aplicación.

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

A continuación, debe crear un perfil de instancia en IAM.

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

Una vez que tenga el perfil de instancia, debe crear el rol, agregar el rol al perfil de instancia y asociar la política con el rol.

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

Ahora, puede usar ese perfil de instancia cuando inicie una instancia:

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

Answer 4

Me gustaría señalar que ya no es necesario proporcionar ninguna credencial a su instancia EC2. Con IAM, puede crear un rol para sus instancias EC2. En estos roles, puede establecer políticas específicas que permitan que su instancia EC2 obtenga, por ejemplo, un objeto específico de un bucket S3 específico y no más. Puede leer más sobre los roles de IAM en los documentos de AWS:

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

Answer 5

Como otros ya han señalado aquí, realmente no necesita almacenar las credenciales de AWS para una instancia de EC2, mediante el uso de roles de IAM:   https: // aws .amazon.com / blogs / security / a-safer-way-to-distribution-aws-credentials-to-ec2 / . Agregaré que puede emplear el mismo método también para almacenar de forma segura credenciales NO-AWS para su instancia EC2, por ejemplo, si tiene algunas credenciales db que desea mantener seguras. Guarda las credenciales que no son AWS en un Bukcet S3 y utiliza la función IAM para acceder a ese depósito. puede encontrar información más detallada sobre eso aquí - https://aws.amazon.com/blogs/security/using-iam-roles-to-distribute-non-aws-credentials-to-your-ec2-instances/