AWS ElasticSearch écrit sur le compte "A" de lambda dans le compte "B"

Question

J'ai un cluster AWS ElasticSearch dans le compte "A".

J'essaie de créer un lambda (déclenché à partir d'un flux DynamoDB) sur le compte "B" qui écrira à ES sur le compte "A".

Je reçois l'erreur suivante:

{ 
"Message":"User: arn:aws:sts::AccountB:assumed-role/lambdaRole1/sourceTableToES is not authorized to perform: es:ESHttpPost on resource: beta-na-lifeguard" 
} 

J'ai essayé de mettre les STS, ainsi que le rôle dans la politique d'accès ES (au compte « A ») sans chance. Voici ma politique:

{ 
    "Version": "2012-10-17", 
    "Statement": [ 
    { 
     "Effect": "Allow", 
     "Principal": { 
     "AWS": "arn:aws:iam::AccountA:user/beta-elasticsearch-admin" 
     }, 
     "Action": "es:*", 
     "Resource": "*" 
    }, 
    { 
     "Effect": "Allow", 
     "Principal": { 
     "AWS": [ 
      "arn:aws:iam::AccountA:user/beta-elasticsearch-readwrite", 
      "arn:aws:iam::AccountA:role/beta-na-DynamoDBStreamLambdaElasticSearch", 
      "arn:aws:sts::AccountB:assumed-role/lambdaRole1/sourceTableToES", 
      "arn:aws:iam::AccountB:role/service-role/lambdaRole1" 
     ] 
     }, 
     "Action": [ 
     "es:ESHttpGet", 
     "es:ESHttpPost", 
     "es:ESHttpPut" 
     ], 
     "Resource": "*" 
    } 
    ] 
} 

Answer 1

Lorsque vous créez un «rôle» pour un autre compte, vous devez également configurer les «relations de confiance». Cela est effectué dans la console AWS IAM sous "Rôles". Le deuxième onglet pour votre rôle est "Relations de confiance". Vous devrez indiquer les détails du compte pour l'autre compte comme étant de confiance. Les relations de confiance sont un document de politique lui-même.

Voici un exemple qui vous permettra d'appeler AssumeRole d'un autre compte à mon compte AWS.

{ 
    "Version": "2012-10-17", 
    "Statement": [ 
    { 
     "Effect": "Allow", 
     "Principal": { 
     "AWS": "arn:aws:iam::2812XXXXYYYY:root" 
     }, 
     "Action": "sts:AssumeRole" 
    } 
    ] 
} 

Dans votre rôle, il suffit de spécifier des autorisations que la normale tout comme vous accordez des autorisations pour un autre utilisateur IAM/service (par exemple supprimer toutes les entrées de type de compte). Le document de stratégie Relations de confiance définit qui peut appeler AssumeRole pour obtenir ces autorisations.

Creating a Role to Delegate Permissions to an IAM User

Modifying a Role

Answer 2

Dans mon code ci-dessus, j'ajoutais arn:aws:sts::AccountB:assumed-role/lambdaRole1/sourceTableToSNS dans la liste d'accès ES compte Pour, cela est faux. Au lieu de faire ce qui suit:

J'avais déjà arn:aws:iam::AccountA:role/beta-na-DynamoDBStreamLambdaElasticSearch dans la liste d'accès ES, j'avais besoin d'ajouter une relation d'approbation (à partir de l'écran de rôle IAM) pour que ce rôle soit assumable par AccountB. J'ai ajouté ceci dans la relation d'approbation:

{ 
    "Effect": "Allow", 
    "Principal": { 
    "AWS": "arn:aws:iam::AccountB:root" 
    }, 
    "Action": "sts:AssumeRole" 
} 

Ensuite, dans mon code lambda de compteB, j'ai dû assumer ce rôle. Voici le code correspondant du lambda.

var AWS = require('aws-sdk'); 
var sts = new AWS.STS({ region: process.env.REGION }); 
var params = { 
    RoleSessionName: "hello-cross-account-session", 
    RoleArn: "arn:aws:iam::accountA:role/beta-na-DynamoDBStreamLambdaElasticSearch", 
    DurationSeconds: 900 
}; 
sts.assumeRole(params, function (err, data) { 
    if (err) { 
     console.log(err, err.stack); // an error occurred 
     context.fail('failed to assume role ' + err); 
     return; 
    } 
    log("assumed role successfully! %j", data) 
    postToES(bulkUpdateCommand, context); 
});