I have two AWS accounts:
DEV: 111111111111
PROD: 999999999999
I created an a code commit repo in the prod account called prodRepo.
What I want to do is allow an ec2 instance on the DEV and PROD account to have read-only access to this repo. So git clone, git pull, etc...
I can do this easily on my PROD account using the following IAM instance profile called codecommit-tester
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"codecommit:BatchGetRepositories",
"codecommit:Get*",
"codecommit:GitPull",
"codecommit:List*"
],
"Resource": "arn:aws:codecommit:us-east-1:999999999999:prodRepo"
}
]
}
The Trust Relationship policy is:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
}
Then I use the aws credentials helpers in the git config to perform read-only git operations without having to store credentials on my machine (it gets the credentials for code commit from the instance metadata).
$ cat ~/.gitconfig
[credential]
helper = !aws codecommit credential-helper $#
UseHttpPath = true
The problem I am having is creating an the IAM policy/role on the DEV account to do the same thing as the PROD account. Here is what I tried.
I edited the Trust Relationship on the PROD account to trust the DEV account:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
},
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111111111111:root"
},
"Action": "sts:AssumeRole"
}
}
Now I think this means the DEV account can assume this role. On the DEV account I created these IAM policies attached to a role:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"codecommit:BatchGetRepositories",
"codecommit:Get*",
"codecommit:GitPull",
"codecommit:List*"
],
"Resource": "arn:aws:codecommit:us-east-1:999999999999:prodRepo"
}
]
}
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::999999999999:role/codecommit-tester"
}
}
I use the credentials helper on the DEV account after launching an ec2 instance using this IAM instance profile and I get this error when performing a git clone:
$ git clone https://git-codecommit.us-east-1.amazonaws.com/v1/repos/prodRepo
Cloning into 'prodRepo'...
fatal: unable to access 'https://git-codecommit.us-east-1.amazonaws.com/v1/repos/prodRepo/': The requested URL returned error: 403
So what did I miss in the IAM roles/policies on the DEV to make this work?
I think you don't need iam role in dev which you mention (On the DEV account I created these IAM policies attached to a role) .... have not tried with instance cross account assume role..
but if you can create new IAM role in prod account with
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::999999999999:role/codecommit-tester"
}
]
}
and trust relation would be something like
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111111111111:root"
},
"Action": "sts:AssumeRole"
}
and just assume new IAM ARN in dev ec2 role.
Related
In the CI/CD section of the AWS SAM tutorial workshop, when I ran
sam pipeline init --bootstrap and went through the configurations, a role was created with this policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": "*",
"Resource": "*",
"Effect": "Allow"
}
]
}
Doesn't this grant the role complete permission over my AWS account which is a big no no? Or is it fine because the permission is granted to an AWS service, and not a user?
This is the trust relationship:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "cloudformation.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
Having a role that exists with those permissionsis fine.
When you create a vanilla AWS Account (in other words I am not including those created by enterprise landing zones like Control Tower) it comes with a policy called AdministratorAccess and a role called Administrator.
The best practice is in who or what you allow to use that policy and when.
Roles are preferred over users, since roles provide security credentials. With a user you have durable credentials you need to secure.
In this case you are allowing CloudFormation to assume this role. This makes sense since CloudFormation often needs to be able to create and modify any resources including IAM roles. If you know you will not be creating or modifying IAM resources you can user a more restrictive role (least privilege), for example using the PowerUserAccess policy which looks like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"NotAction": [
"iam:*",
"organizations:*",
"account:*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole",
"iam:DeleteServiceLinkedRole",
"iam:ListRoles",
"organizations:DescribeOrganization",
"account:ListRegions"
],
"Resource": "*"
}
]
}
My AWS has 2 different Users: admin, s3_readonly
I am the main admin and have 1 cluster in Redshift(cluster1).
Now I am trying to schedule a query that just calls those procedures every hour (CALL <procedure_name>)
For this task, I have followed the official documentation from AWS (Scheduling a query on the Amazon Redshift console - Amazon Redshift) and to be exact this document steps (Scheduling SQL queries on your Amazon Redshift data warehouse | AWS Big Data Blog).
So I created new IAM role RedshiftScheduler, which has Redshift Customizable option and have attached AmazonRedshiftDataFullAccess to it. Then I edited the Trust relationship and added:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "redshift.amazonaws.com"
},
"Action": "sts:AssumeRole"
},
{
"Sid": "S2",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<ACCOUNT_ID>:user/admin"
},
"Action": "sts:AssumeRole"
},
{
"Sid": "S1",
"Effect": "Allow",
"Principal": {
"Service": "events.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
I then went back to my AWS user (admin) and attached a new policy granted with Assume Role permissions:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "S3",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::<ACCOUNT_ID>:role/RedshiftScheduler"
}
]
}
Now, I logged in to the Redshift cluster via AWS service. Used Temporary credentials to connect to cluster1 and user as dbuser. However, when I try to schedule the query it throws an error
To view the schedule history of this schedule, add sts:AssumeRole for IAM role arn:aws:iam::<ACCOUNT_ID>:role/RedshiftScheduler to your IAM role. You also need to add your IAM user ARN to the role’s trust policy.
You need to add your IAM user ARN to the role’s trust policy like this
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<account #>:user/<admin username"
},
"Action": "sts:AssumeRole",
"Condition": {}
}
after
{
"Sid": "S1",
"Effect": "Allow",
"Principal": {
"Service": "events.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
Getting this Elastic Beanstalk permission error when trying to do:
eb ssh --setup
2020-07-06 07:36:50 INFO Environment update is starting.
2020-07-06 07:36:53 ERROR Service:Amazon S3, Message:You don't have permission to copy an Amazon S3 object to another S3 location. Source: bucket = 'tempsource', key = 'xxx'. Destination: bucket = 'tempdest', key = 'yyy'.
2020-07-06 07:36:53 ERROR Failed to deploy configuration.
Is there a specific policy that I should be adding to my IAM permissions? I've tried adding full S3 access to my IAM User, but the error remains. Or is a permissions error associated with the source bucket?
Some more details:
Both buckets are in the same AWS account. The copying operation doesn't work for AWS CLI copy commands.
Bucket Profiles
Source Bucket
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::XXXXXXXXXXXX:role/aws-elasticbeanstalk-ec2-role"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::SOURCE_BUCKET/*"
},
{
"Sid": "Stmt2",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::XXXXXXXXXXXX:role/aws-elasticbeanstalk-ec2-role"
},
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::SOURCE_BUCKET"
}
]
}
Destination Bucket (elasticbeanstalk-us-west-2-XXXXXXXXXXXX)
{
"Version": "2008-10-17",
"Statement": [
{
"Sid": "eb-ad78f54a-f239-4c90-adda-49e5f56cb51e",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::XXXXXXXXXXXX:role/aws-elasticbeanstalk-ec2-role"
},
"Action": "s3:PutObject",
"Resource": [
"arn:aws:s3:::elasticbeanstalk-us-west-2-XXXXXXXXXXXX/*",
"arn:aws:s3:::elasticbeanstalk-us-west-2-XXXXXXXXXXXX/resources/environments/logs/*"
]
},
{
"Sid": "eb-af163bf3-d27b-4712-b795-d1e33e331ca4",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::XXXXXXXXXXXX:role/aws-elasticbeanstalk-ec2-role"
},
"Action": [
"s3:ListBucket",
"s3:ListBucketVersions",
"s3:GetObject",
"s3:GetObjectVersion"
],
"Resource": [
"arn:aws:s3:::elasticbeanstalk-us-west-2-XXXXXXXXXXXX",
"arn:aws:s3:::elasticbeanstalk-us-west-2-XXXXXXXXXXXX/resources/environments/*"
]
},
{
"Sid": "eb-58950a8c-feb6-11e2-89e0-0800277d041b",
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Action": "s3:DeleteBucket",
"Resource": "arn:aws:s3:::elasticbeanstalk-us-west-2-XXXXXXXXXXXX"
}
]
}
I've tried adding full S3 access to my IAM User, but the error remains.
The error is not about about your IAM permissions (i.e. your IAM user). But its about a role that EB is using your the instance (i.e. instance role/profile):
Managing Elastic Beanstalk instance profiles
The defualt role used on the instances in aws-elasticbeanstalk-ec2-role. Thus you can locate it in IAM console, and add required S3 permissions. Depending on your setup, you may be using different role.
Or is a permissions error associated with the source bucket?
If you have bucket policies that deny the access, it could also be the reason.
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
I have two AWS account , I was able to set AWS integration for the first account using Terraform, but when I try to create AWS integration for my second account I am having an error.
I have created a role with in-line policy and we do not have a cross account set up.
! Datadog is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::xxxxxxxxxx:role/DatadogAWSIntegrationRole. See http://docs.datadoghq.com/integrations/aws/
Trust Relationship:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::xxxxxxxxxxxx:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "xxxxxxxxxxxxxxxxxxxxxxxxxx"
}
}
}
]
}
Can anyone please guide me how to solve this error?
The role arn:aws:iam::xxxxxxxxxx:role/DatadogAWSIntegrationRole also has to have permission to assume the role on the other account.
You'll have to update the DatadogAWSIntegrationRole on the primary account to include:
{
"Version": "2012-10-17",
"Statement": [
...
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::xxxxxxxxxxxx:role/AssumedRoleForDataDogInOtherAccount"
}
]
}