AWS ElasticSearch write to account "A" from lambda in account "B" - amazon-web-services

I have an AWS ElasticSearch Cluster in account "A".
I'm trying to create a lambda (triggered from a DynamoDB Stream) in account "B" that will write to ES in account "A".
I'm getting the following error:
{
"Message":"User: arn:aws:sts::AccountB:assumed-role/lambdaRole1/sourceTableToES is not authorized to perform: es:ESHttpPost on resource: beta-na-lifeguard"
}
I have tried putting the STS as well as the ROLE into the ES access policy (within account "A") with no luck. Here is my policy:
{
"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": "*"
}
]
}

In my code above I was adding arn:aws:sts::AccountB:assumed-role/lambdaRole1/sourceTableToSNS into the AccountA ES access list, that is wrong. Instead do the following:
I already had arn:aws:iam::AccountA:role/beta-na-DynamoDBStreamLambdaElasticSearch in the ES access list, I needed to add a trust relationship (from the IAM role screen) for that role to be assumable by AccountB. I added this into the trust relationship:
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::AccountB:root"
},
"Action": "sts:AssumeRole"
}
Then, in my accountB lambda code, I needed to assume that role. Here is the relevent code from the 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);
});

When you create a "role" for another account you also need to setup the "Trust relationships". This is done in the AWS IAM console under "Roles". Second tab for your role is "Trust relationships". You will need to specify the account details for the other account as trusted.
The "Trust relationships" is a policy document itself. Here is an example that will allow you to call AssumeRole from another account to my AWS account.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::2812XXXXYYYY:root"
},
"Action": "sts:AssumeRole"
}
]
}
In your role, just specify permissions as normal just like you were granting permissions for another IAM user / service (e.g. remove all those account type entries). The Trust relationships policy document defines who can call AssumeRole to be granted those permissions.
Creating a Role to Delegate Permissions to an IAM User
Modifying a Role

Related

How can I put assume role on itself in CDK

I have a role created by aws cdk like below code.
const role = new iam.Role(scope, name, {
assumedBy: new iam.CompositePrincipal(
new iam.ServicePrincipal('codebuild.amazonaws.com'),
new iam.ServicePrincipal('codepipeline.amazonaws.com'),
),
});
role.grantAssumeRole(new iam.ArnPrincipal(role.roleArn));
I'd like it to be able to assume by itself. The use case is that the role will used by codebuild and inside the codebuild it needs to assume the role in order to pass credential to a docker container.
but after deploy, the principal of this role is:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "codebuild.amazonaws.com"
},
"Action": "sts:AssumeRole"
},
{
"Effect": "Allow",
"Principal": {
"Service": "codepipeline.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
It doesn't include the roleArn in the principle. How can I make the arn appear in the principal policy?
I don't pass the role name into this code since I'd like to use auto generated role name. That's why I can't assemble the role arn.

Allow user to assume an IAM role with SSO login

I am trying to allow a user to assume a role on AWS. I attached an assume role policy to a group where the IAM user belongs so that they can assume a particular role. The problem is that the user now uses SSO to login and and is no longer allowed to login into through console with the IAM user credentials, therefore the user is unable to assume the role. How can I configure a user with SSO login to assume an existing IAM role? When i created the Assume role policy I chose both AssumeRole and AssumeRoleWithSaml. But it's still not working.
This is what the AssumeRole policy looks like
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"sts:AssumeRole",
"sts:AssumeRoleWithSAML"
],
"Resource": "arn:aws:iam::xxxxxxxxxxxx:role/service-role/KinesisFirehoseServiceRole--us-east-1-xxxxxxxxxxxxx"
}
]
The Trust relationship for the role looks like this
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "firehose.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
You need to specifically allow that user / role to be able to assume that role. Right now, the Principal is set to only allow the "firehose service" to assume that role.
The 2nd problem is that you need to specifically allow a SSO account to be able to access it. You'll need to get the ARN of your current SSO user session. To get this you should run aws sts get-caller-identity
You should get something like this
{
"UserId": "BROA5DAM2TACHAA38V9J1:daryl.teo#appetiser.com.au",
"Account": "1234567890",
"Arn": "arn:aws:sts::1234567890:assumed-role/AWSReservedSSO_AWSAdministratorAccess_abe68abec87ew/something.username"
}
Or a 1 liner aws sts get-caller-identity --output text --query Arn
Then take that value and add it to your policy as an additional policy statement.
{
"Version": "2012-10-17",
"Statement":
[
{
"Effect": "Allow",
"Principal":
{
"Service": "firehose.amazonaws.com"
},
"Action": "sts:AssumeRole"
},
{
"Effect": "Allow",
"Principal":
{
"AWS": "arn:aws:sts::1234567890:assumed-role/AWSReservedSSO_AWSAdministratorAccess_abe68abec87ew/something.username"
},
"Action": "sts:AssumeRole"
},
]
}
And now you can use:
aws sts assume-role --role-arn=arn:aws:iam::123456823432:role/NameOfYourRole --role-session-name=role-session-name
I managed to enable SSO users to assume a role in the account they were authenticated to by using the following. Note that you'll need to replace ${ACCOUNT_ID}, ${SSO_ROLE_NAME}, and ${ASSUMABLE_ROLE_NAME}. You may, of course, need to repackage the bits.
aws iam create-role --role-name ${ASSUMABLE_ROLE_NAME} --assume-role-policy-document file://policy.json --profile $PROFILE
policy.json:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::${ACCOUNT_ID}:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnLike": {
"aws:PrincipalArn": [
"arn:aws:iam::${ACCOUNT_ID}:role/aws-reserved/sso.amazonaws.com/*/AWSReservedSSO_${SSO_ROLE_NAME}_*",
"arn:aws:iam::${ACCOUNT_ID}:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_${SSO_ROLE_NAME}_*"
]
}
}
}
]
}
Thanks to everyone that responded. I was able to complete the task using this instructions. google saml sso with AWS

Identity Pool Role Can't Access S3 Bucket Access Point

Summary: I am using AWS Amplify Auth class with a pre-configured Cognito User Pool for authentication. After authentication, I am using the Cognito ID token to fetch identity pool credentials (using AWS CredentialProviders SDK) whose assumed role is given access to an S3 access point. I then attempt to fetch a known object from the bucket's access point using the AWS S3 SDK. The problem is that the request returns a response of 403 Forbidden instead of successfully getting the object, despite my role policy and bucket (access point) policy allowing the s3:GetObject action on the resource.
I am assuming something is wrong with the way my policies are set up. Code snippets below.
I am also concerned I'm not getting the right role back from the credentials provider, but I don't allow unauthenticated roles on the identity pool so I am not sure, and I don't know how to verify the role being sent back in the credentials' session token to check.
I also may not be configuring the sdk client objects properly, but I followed the documentation provided to the best of my understanding from the documentation (I am using AWS SDK v3, not v2, so slightly different syntax and uses modular imports)
Backend Configurations - IAM
Identity Pool: Authenticated Role Trust Policy
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "cognito-identity.amazonaws.com"
},
"Action": [
"sts:AssumeRoleWithWebIdentity",
"sts:TagSession"
],
"Condition": {
"StringEquals": {
"cognito-identity.amazonaws.com:aud": "<MY_IDENTITY_POOL_ID>"
},
"ForAnyValue:StringLike": {
"cognito-identity.amazonaws.com:amr": "authenticated"
}
}
}
]
}
Identity Pool: Authenticated Role S3 Access Policy
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:GetObjectVersion"
],
"Resource": "arn:aws:s3:::<MY_ACCESS_POINT_NAME>/object/*"
}
]
}
Backend Configurations - S3
S3 Bucket and Access Points: Block All Public Access
S3 Bucket CORS Policy:
[
{
"AllowedHeaders": [
"*"
],
"AllowedMethods": [
"GET",
"PUT",
"HEAD"
],
"AllowedOrigins": [
"*"
],
"ExposeHeaders": [],
"MaxAgeSeconds": 300
}
]
S3 Bucket Policy (Delegates Access Control to Access Points):
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DelegateAccessControlToAccessPoints",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "*",
"Resource": [
"arn:aws:s3:::<MY_BUCKET_NAME>",
"arn:aws:s3:::<MY_BUCKET_NAME>/*"
],
"Condition": {
"StringEquals": {
"s3:DataAccessPointAccount": "<MY_ACCT_ID>"
}
}
}
]
}
Access Point Policy
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAccessPointToGetObjects",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<ACCT_ID>:role/<MY_IDENTITY_POOL_AUTH_ROLE_NAME>"
},
"Action": [
"s3:GetObject",
"s3:GetObjectVersion"
],
"Resource": "arn:aws:s3:<REGION>:<ACCT_ID>:accesspoint/<MY_ACCESS_POINT_NAME>/object/*"
}
]
}
Front End AuthN & AuthZ
Amplify Configuration of User Pool Auth
Amplify.configure({
Auth: {
region: '<REGION>',
userPoolId: '<MY_USER_POOL_ID>',
userPoolWebClientId: '<MY_USER_POOL_APP_CLIENT_ID>'
}
})
User AuthZ process:
On user login event, call Amplify's Auth.signIn() which returns type CognitoUser:
// Log in user (error checking ommitted here for post)
const CognitoUser = await Auth.signIn(email, secret);
// Get ID Token JWT
const CognitoIdToken = CognitoUser.signInUserSession.getIdToken().getJwtToken();
// Use #aws-sdk/credentials-provider to get Identity Pool Credentials
const credentials = fromCognitoIdentityPool({
clientConfig: { region: '<REGION>' },
identityPoolId: '<MY_IDENTITY_POOL_ID>',
logins: {
'cognito-idp.<REGION>.amazonaws.com/<MY_USER_POOL_ID>': CognitoIdToken
}
})
// Create S3 SDK Client
client = new S3Client({
region: '<REGION>',
credentials
})
// Format S3 GetObjectCommand parameters for object to get from access point
const s3params = {
Bucket: '<MY_ACCESS_POINT_ARN>',
Key: '<MY_OBJECT_KEY>'
}
// Create S3 client command object
const getObjectCommand = new GetObjectCommand(s3params);
// Get object from access point (execute command)
const response = await client.send(getObjectCommand); // -> 403 FORBIDDEN

AWS cli: not authorized to perform: sts:AssumeRole on resource

I have an AWS account in which I am assuming a role named A(role-A), from that role I have created another role named B(role-B) through the web console and attached the administrator policy to that role
Here is cli configuration
[default]
aws_access_key_id = <>
aws_secret_access_key = <>
region = eu-central-1
[role-B]
role_arn = arn:aws:iam::<id>:role/ics-role
mfa_serial = arn:aws:iam::<id>:mfa/<name>
external_id = <name>
source_profile = default
role-B which I have created from role-A
When i try to get the role details
aws --profile role-B sts get-caller-identity
I am getting the following error
An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::<>:user/<> is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::<>:role/ics-role
You'll need to check the trust relationship policy document of the iam role to confirm that your user is in it.
Additionally make sure that the iam user has explicit permissions allowing them to assume that role.
The trust relationship should look something like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::1234567890:user/person"
]
},
"Action": "sts:AssumeRole"
}
]
}
My issue was I had a condition set in the policy json.
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::000000000:dave"
},
"Action": "sts:AssumeRole",
"Condition": {
// Condition set here
}
}]
}
I removed the condition and it works now no issues.
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::000000000:dave"
},
"Action": "sts:AssumeRole"
}]
}

update Route53 record set - cross account

Am facing an access issue when trying to update record set using lambda function.
Lambda - Account A
Route53 - Account B
I have an IAM role attached to lambda in Account A with an assume role permission to an IAM role in Account B. The IAM role in account B has access to update the record set in Account B.
When am triggering lambda, am receiving user is not authorized to access this resource.
Can someone help me, if i'm missing anything here or do I need any additional setup.
You are using a Lambda function in Account-A to call Route 53 in Account-B.
This will require:
An IAM Role (Role-A) in Account-A that is assigned to the Lambda function. It should grant permission to call AssumeRole(), with the Resource set to the ARN of Role-B in Account-B:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::<Account-B>:role/role-b"
}
]
}
And with this Trust Relationship:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
An IAM Role (Role-B) in Account-B that has permission to call Route 53. It should also have a trust policy allowing it to be assumed by Role-A in Account-A:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "route53:*",
"Resource": "*"
}
]
}
(This is an overly powerful policy. It would be better to limit it to the specific Route 53 actions that are required.)
And this Trust Relationship (pointing to the Role created in the previous step):
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<Account-A>:role/role-a"
},
"Action": "sts:AssumeRole"
}
]
}
You need to use STS to get a token to call Route53 on Account B. Here are the docs on STS in boto3: https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/sts.html#STS.Client.assume_role
You'll get back a credential that you will use to make the call to Route53.