Dynamodb Cross-account put_item - amazon-web-services

I have two AWS accounts (account A, and account B). Account A has an EC2 instance, and that instance wants to do a put item to a dynamodb located in account B.
Since it is cross-account access, I created an IAM role on account B to allow account A to do put_item, an IAM role on account A to assume that role and attached the IAM role on the EC2 instance
When I run my program, I get an error message saying that I am trying to use the assume role to put an item to a table that in the same account. (in my code i just sepcified the Account B table name)
It seems that the instance doesn’t realize that the table is on account B even I have the assumerole setup. What am I missing here?
I have also verified that I can put item using AWS CLI (after performing the STS call).
Is there any Java API that I can to specify which dynamodb arn that I want to put the item to?
Error message:
User: arn:aws:sts::ACCOUNT_A:assumed-role/Assume-role/INSTANCE_ID is not authorized to perform: dynamodb:PutItem on resource: arn:aws:dynamodb:us-east-1:ACCOUNT_A:table/TABLE_NAME (Service: AmazonDynamoDBv2; Status Code: 400; Error Code: AccessDeniedException)
Policy on account A:
{
"Version": "2012-10-17",
"Statement": [ {
"Effect": "Allow",
"Action": [ "sts:AssumeRole", "sts:GetFederationToken" ],
"Resource": "arn:aws:iam::AccountA:role/PutItem" },
{ "Effect": "Allow",
"Action": [ "sts:DecodeAuthorizationMessage", "sts:GetAccessKeyInfo", "sts:GetCallerIdentity" ],
"Resource": "*" } ]
}
Policy on Account B:
{
"Version": "2012-10-17",
"Statement": [ {
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [ "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:UpdateTable" ],
"Resource": "arn:aws:dynamodb:region:accB:table/table name" },
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": "dynamodb:*",
"Resource": "*" } ]
}

Related

aws IAM role is not authorized to perform: route53:ListHostedZones

When I try to deploy terraform script using gitlab runner I am getting the following error
Error: Error finding Route 53 Hosted Zone: AccessDenied: User: arn:aws:sts::12345678:assumed-role/dev-runner/i-01b2f123f1e1a127c is not authorized to perform: route53:ListHostedZones because no identity-based policy allows the route53:ListHostedZones action
The IAM role that is attached to the runner has the following policy
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "*",
"Resource": [
"arn:aws:route53:::*",
"arn:aws:acm:us-east-1:12345678:certificate/*",
]
}
]
}
What I am missing here? All the actions are allowed on arn:aws:route53:::* resource.
Try to check role with AWS Policy Simulator
Here is
This action does not support resource-level permissions. Policies granting access must specify "*" in the resource element.
error is raising with your role.
Resource should be "Resource": * to be able run ListHostedZones. However, in this case the permissions will be totally insecure, so I recommend to separate the statements:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"route53:ListHostedZones",
... any other specific permissions for R53 ...
],
"Resource": "*"
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": "*",
"Resource": [
"arn:aws:acm:us-east-1:12345678:certificate/*"
]
}
]
}
And just a personal opinion: using wildcard * actions without specifying at least services (route53:*) is not looking like a good idea

PutObject access denied for a cross account setup

I am setting up a cross-account between two AWS accounts, and I'd like account B to be able to push files/logs to account A. I have an S3 bucket encrypted with KMS encryption sitting in account A.
The bucket in account A has the attached policy in it:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::00000000:role/some-role-in-account-B"
},
"Action": [
"s3:PutObject",
"s3:PutObjectAcl",
"s3:GetObject",
"s3:GetObjectAcl",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3::some-bucket-in-account-A",
"arn:aws:s3:::some-bucket-in-account-A/*"
]
}
]
}
In account B, I have created a role (some-role-in-account-B) with the below policy attached:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:PutObjectAcl",
"s3:GetObject",
"s3:GetObjectAcl",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::some-bucket-in-account-A",
"arn:aws:s3:::some-bucket-in-account-A/*"
]
}
]
}
I have an instance in account B in which I have attached the some-role-in-account-B role.
Running these from the instance: aws s3 ls s3://some-bucket-in-account-A works fine. However, aws s3 cp some-random-file s3://some-bucket-in-account-A fails with the error: An error occurred (AccessDenied) when calling the PutObject operation: Access Denied. Does anyone knows what I might be missing?
You need to grant the role from account B access to the KMS key. See here for more information: https://aws.amazon.com/premiumsupport/knowledge-center/cross-account-access-denied-error-s3/
Mind you, I don't think you need to grant all the permissions referenced in the article to the role, you should only need to grant the following:
kms:Encrypt
kms:GenerateDataKey
kms:ReEncrypt*

Problem with AWS Lambda and cross account roles

I need to assume a cross account role to get access to an ElasticSearch domain for logging on AWS. Here's what I've done:
First, I have created a cross account role in ACCOUNT1. The role name is LoggerAccessToES and the trust relationship is something like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": "sts:AssumeRole"
},
{
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::ACCOUNT1:root",
"arn:aws:iam::ACCOUNT2:root"
]
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}
Then, on ACCOUNT2, I have created a Lambda function to assume the above role with this code:
sts_client = boto3.client('sts', region_name=Config.AWS_ES_REGION)
assumed_role_object=sts_client.assume_role(
RoleArn="arn:aws:iam::ACCOUNT1:role/LoggerAccessToES",
RoleSessionName="AssumeLoggerAccessToESSession1"
)
When I invoke the lambda (basically the lambda is attached to an SNS topic), I get the error:
botocore.exceptions.ClientError: An error occurred (AccessDenied) when calling the AssumeRole operation: Access denied
I've already tried everything was suggested by other guys in other questions and I also googled the problem but I couldn't find the resolution. What am I doing wrong here?
From what i understand, you want to assume a role in Account 1 using the lambda in account 2.
This would require two roles to be created -
The first role needs to be created in the Account 2 which is to be attached to the Lambda. This role needs to have the following permission attached -
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::ACCOUNT1:role/LoggerAccessToES"
}
}
The above policy can be added to your existing lambda execution role.
For the second part, only the trust relationship of the Role LoggerAccesstoEs needs to be addedin Account 1 shown below-
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::ACCOUNT2:root"
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}
The first role policy allows the lambda to use the AssumeRole.
The second policy allows the Account 1 to trust the AssumeRole request from Account 2.

AWS CloudWatch Cross-Account Logging with EC2 Instance Profile

When I originally setup CloudWatch, I created an EC2 Instance Profile to automatically grant access to write to the account's own CloudWatch service. Now, I would like to consolidate the logs from several accounts into a central account.
I'd like to implement a simplified architecture that is based on Centralized Logging on AWS. However, these logs will feed an on-premise ELK stack, so I'm only trying to implement the components outlined in red. I would like to solve this without the use of Kinesis.
Either the CloudWatch Agent (CWAgent) doesn't support assuming a role or I can't wrap my mind around how to craft the EC2 Instance Profile to allow the CWAgent to assume a role in a different account.
Logging Target (AWS Account 111111111111)
IAM LogStreamerRole:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::999999999999:role/EC2CloudWatchLoggerRole"
]
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": [
"arn:aws:logs:*:*:*"
]
}
]
}
Logging Source (AWS Account 999999999999)
IAM Instance Profile Role:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111111111111:role/LogStreamerRole"
}
]
}
The CWAgent is producing the following error:
/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log:
2018-02-12T23:27:43Z E! CreateLogStream / CreateLogGroup with log group name Linux/var/log/messages stream name i-123456789abcdef has errors. Will retry the request: AccessDeniedException: User: arn:aws:sts::999999999999:assumed-role/EC2CloudWatchLoggerRole/i-123456789abcdef is not authorized to perform: logs:CreateLogStream on resource: arn:aws:logs:us-west-2:999999999999:log-group:Linux/var/log/messages:log-stream:i-123456789abcdef
status code: 400, request id: 53271811-1234-11e8-afe1-a3c56071215e
It is still trying to write to its own CloudWatch service, instead of to the central CloudWatch service.
From the logs, I see that the instance profile is used.
arn:aws:sts::999999999999:assumed-role/EC2CloudWatchLoggerRole/i-123456789abcdef
Just add the following to the /etc/awslogs/awscli.conf to assume the LogStreamerRole role.
role_arn = arn:aws:iam::111111111111:role/LogStreamerRole
credential_source=Ec2InstanceMetadata

S3 Policy to Allow Lambda

I have the following policy on an S3 bucket created with the AWS policy generator to allow a lambda, running with a specific role, access to the files in the bucket. However, when I execute the Lambda, I get 403 permission denied:
"errorMessage": "Access Denied (Service: Amazon S3; Status Code: 403; Error Code: AccessDenied; Request ID: <requestId>)",
"errorType": "com.amazonaws.services.s3.model.AmazonS3Exception",
The Policy on the S3 bucket:
{
"Version": "2012-10-17",
"Id": "Policy<number>",
"Statement": [
{
"Sid": "Stmt<number>",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<account>:role/<roleName>"
},
"Action": "s3:*",
"Resource": "arn:aws:s3:::<bucketName>/*"
}
]
}
What is wrong with the policy? The Lamba is running with the role configured in the policy.
A role assigned to an AWS Lambda function should be created with an AWS Lambda role (that is selected when creating a Role in the IAM console).
Roles do not have a Principal since the permissions are assigned to whichever service (in this case, Lambda function) is using the role.
Also, you should assign permissions on the bucket itself (e.g. to list contents) and on the contents of the bucket (e.g. to GetObject).
It would be something like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowS3Access",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123XXX:role/service-role/LAMBDA_ROLE_NAME"
},
"Action": [
"s3:*"
],
"Resource": [
"arn:aws:s3:::my-bucket",
"arn:aws:s3:::my-bucket/*"
]
}
]
}
After looping for I while i could make it work, the process is:
create the s3 bucket.
create the IAM policy (bucket name needed)
Create IAM role (IAM policy needed)
Create lambda Function (IAM Role needed)
Create s3 bucket policy (lambda function name needed)
IAM Policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt*******",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:PutObjectAcl",
"s3:PutObjectTagging",
"s3:PutObjectVersionAcl",
"s3:PutObjectVersionTagging"
],
"Resource": [
"arn:aws:s3:::<bucket-name>"
]
}
]
}
and I use this policy on the s3 Bucket
{
"Id": "Policy************",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt********",
"Action": [
"s3:PutObject",
"s3:PutObjectAcl",
"s3:PutObjectTagging",
"s3:PutObjectVersionAcl",
"s3:PutObjectVersionTagging"
],
"Effect": "Allow",
"Resource": "arn:aws:s3:::<bucket-name>/*",
"Principal": {
"AWS": [
"arn:aws:iam::*********:role/<lambda-function-name>"
]
}
}
]
}