utilizando el perfil que asume un rol en aws-sdk (AWS JavaScript SDK)

Si encuentras alguna incompatibilidad con tu código o proyecto, recuerda probar siempre en un ambiente de testing antes aplicar el código al proyecto final.

Solución:

La forma correcta de usar múltiples roles de cuentas cruzadas en el código:

Obtenga las credenciales para el rol de cuentas cruzadas con sts y use esas credenciales cada vez que necesite autenticar un servicio con ese rol de cuentas cruzadas específico.

Ejemplo:

Cree una función para obtener las credenciales de cuentas cruzadas como:

const AWS = require('aws-sdk');
const sts = new AWS.STS();

const getCrossAccountCredentials = async () => 
  return new Promise((resolve, reject) => 
    const timestamp = (new Date()).getTime();
    const params = 
      RoleArn: 'arn:aws:iam::123456789:role/Developer',
      RoleSessionName: `be-descriptibe-here-$timestamp`
    ;
    sts.assumeRole(params, (err, data) => 
      if (err) reject(err);
      else 
        resolve(
          accessKeyId: data.Credentials.AccessKeyId,
          secretAccessKey: data.Credentials.SecretAccessKey,
          sessionToken: data.Credentials.SessionToken,
        );
      
    );
  );

Y luego puedes usarlo sin problemas como:

const main = async () => 
  // Get the Cross account credentials
  const accessparams = await getCrossAccountCredentials();
  // Get the ec2 service for current account
  const ec2 = new AWS.EC2();
  // Get the ec2 service for cross account role
  const ca_ec2 = new AWS.EC2(accessparams);
  // Get the autoscaling service for current account
  const autoscaling = new AWS.AutoScaling();
  // Get the autoscaling service for cross account role
  const ca_autoscaling = new AWS.AutoScaling(accessparams);

  // This will describe instances within the cross account role
  ca_ec2.describeInstances(...) 

  // This will describe instances within the original account
  ec2.describeInstances(...)

  // Here you can access both accounts without issues.

Beneficios:

• No cambia las credenciales a nivel mundial, por lo que aún puede apuntar a su propia cuenta de AWS sin tener que hacer una copia de seguridad de las credenciales con anticipación para restaurarla.
• Permite controlar exactamente a qué cuenta se dirige en cada momento.
• Permite manejar múltiples roles y servicios de cuentas cruzadas.

La forma incorrecta:

NO UTILICE AWS.config.update para anular las credenciales globales AWS.config.credentials!!!

¡Anular las credenciales globales es una mala práctica! Esta es la misma situación que la solución aprobada por @ Brant aquí, ¡pero no es una buena solución! He aquí por qué:

const main = async () => 
  // Get the Cross account credentials
  const accessparams = await getCrossAccountCredentials();

  // Get the ec2 service for current account
  const ec2 = new AWS.EC2();

  // Overwrite the AWS credentials with cross account credentilas
  AWS.config.update(accessparams);

  // Get the ec2 service for cross account role
  const ca_ec2 = new AWS.EC2();

  // This will describe instances within the cross account role
  ca_ec2.describeInstances(...) 

  // This will ALSO describe instances within the cross account role
  ec2.describeInstances(...)

  // WARNING: Here you only will access the cross account role. You may get
  // confused on what you're accessing!!!

Cuestiones:

• Actualizando global AWS.config.credentials directamente o por AWS.config.update, anulará las credenciales actuales.
• Todo apuntará a ese rol de cuentas cruzadas, incluso futuras llamadas de servicio que quizás no espere.
• Para volver a la primera cuenta, es posible que necesite una copia de seguridad temporal AWS.config.credentials y actualícelo nuevamente para restaurarlo. Es difícil controlar cuándo usa cada cuenta, es difícil rastrear el contexto de ejecución y es fácil equivocarse al apuntar a la cuenta incorrecta.

Nuevamente, NO UTILICE AWS.config.update para anular las credenciales globales AWS.config.credentials!!!

Si necesita ejecutar el código por completo en otra cuenta:

Si necesita ejecutar su código por completo para otra cuenta sin cambiar entre credenciales. Puede seguir los consejos de @Kanak Singhal y almacenar el role_arn en el archivo de configuración y agregar AWS_SDK_LOAD_CONFIG="true" a la variable de entorno junto con AWS_PROFILE="assume-role-profile".

¡Encontré la forma correcta de hacerlo! Consulte este PR: https://github.com/aws/aws-sdk-js/pull/1391

Solo tuve que agregar AWS_SDK_LOAD_CONFIG="true" a la variable de entorno junto con AWS_PROFILE="assume-role-profile"

Por lo que no requiere ninguna actualización de código.

Esto se debe a que el SDK solo carga credentials archivo por defecto, no el config archivo, pero dado que AWS role_arn se almacena en el config archivo, debemos habilitar la carga del config archivo también.

La CLI y el SDK funcionan de manera diferente, ya que debe asumir explícitamente el rol al usar el SDK. El SDK no asume automáticamente el rol de la configuración como lo hace la CLI.

Una vez asumido el rol, AWS.config debe actualizarse con las nuevas credenciales.

Esto funciona para mi:

var AWS = require('aws-sdk');
AWS.config.region = 'us-east-1';

var sts = new AWS.STS();
sts.assumeRole(
  RoleArn: 'arn:aws:iam::123456789:role/Developer',
  RoleSessionName: 'awssdk'
, function(err, data) 
  if (err)  // an error occurred
    console.log('Cannot assume role');
    console.log(err, err.stack);
   else  // successful response
    AWS.config.update(
      accessKeyId: data.Credentials.AccessKeyId,
      secretAccessKey: data.Credentials.SecretAccessKey,
      sessionToken: data.Credentials.SessionToken
    );
  
);

Aquí puedes ver las reseñas y valoraciones de los lectores

Si te ha resultado provechoso nuestro post, nos gustaría que lo compartas con el resto seniors así nos ayudas a difundir este contenido.

---

---

Utiliza Nuestro Buscador