I am trying to create assume role policy for an IAM role which will be assumed by ECS TASK. I want to put a condition that only ECS Container with specific Arn should be able to assume role.
Here is my policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ecs-tasks.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringLike": {
"ecs:cluster": "ECS cluster Arn"
}
}
}
]
}
The above policy is not working and even not letting the ECS Cluster mentioned above to assume the role. So, is there any other way we can do this? Any help would be appreciated.
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": "*"
}
]
}
I have 3 different EKS cluster for each stage (dev, staging, prd)
and I need to have multiple IAM Role for each application deployed in our clusters.
The idea is to be able to reference multiple EKS OIDC in the trust relationship of that IAM Role so I would end up with 1 IAM Role per application across clusters instead of 3x.
Configuring one IAM Role + trust relationship is easy like below:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::xxxxx:oidc-provider/oidc.eks.eu-west-1.amazonaws.com/id/xxxx-oidc-cluster-1"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringLike": {
"oidc.eks.eu-west-1.amazonaws.com/id/xxxx-oidc-cluster-1:sub": "system:serviceaccount:*:*"
}
}
}
]
}
What I'm trying to do is reference my other clusters (xxxx-oidc-cluster-2 and xxxx-oidc-cluster-3) in that same trust relationship. I dug into the official doc to how to construct such IAM JSON Policy, but couldn't find anything that could help. I thought maybe I was missing something.
It's probably best practice to scope your IAM Roles to one per application per cluster, but if you really want to do this, you'll need to use multiple separate statements in your Assume Role Policy (Trust Relationship).
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::xxxxx:oidc-provider/oidc.eks.eu-west-1.amazonaws.com/id/xxxx-oidc-cluster-1"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks.eu-west-1.amazonaws.com/id/xxxx-oidc-cluster-1:sub": "system:serviceaccount:*:*"
}
}
},
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::xxxxx:oidc-provider/oidc.eks.eu-west-1.amazonaws.com/id/xxxx-oidc-cluster-2"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks.eu-west-1.amazonaws.com/id/xxxx-oidc-cluster-2:sub": "system:serviceaccount:*:*""
}
}
}
]
}
I want to upload to S3 from a Fargate task. Can this be achieved by only specifying a ExecutionRoleArn as opposed to specifying a both a ExecutionRoleArn and a TaskRoleArn?
If I specify a ExecutionRoleArn that has the following Permission Policies attached:
Custom policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject"
],
"Resource": "arn:aws:s3:::example_bucket/*"
}
]
}
AmazonECSTaskExecutionRolePolicy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecr:GetAuthorizationToken",
"ecr:BatchCheckLayerAvailability",
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "*"
}
]
}
With the following trust relationship:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": [
"events.amazonaws.com",
"lambda.amazonaws.com",
"ecs-tasks.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
Would this be sufficient to allow the task to upload to S3? Or do I need to define a TaskRoleArn?
The ExecutionRoleArn is used by the service to setup the task correctly, this includes pulling any images down from ECR.
The TaskRoleArn is used by the task to give it the permissions it needs to interact with other AWS Services (such as S3).
Technically both Arns could be the same, however I would suggest separating them to be different roles to avoid confusion over the permissions required for both of the scenarios the role is used for.
Additionally you should have the endpoint for ecs.amazonaws.com. In fact the full list of services depending on how you're using ECS are below (although most could be removed such as spot if you're not using spot, or autoscaling if you're not using autoscaling).
"ecs.amazonaws.com",
"ecs-tasks.amazonaws.com",
"spot.amazonaws.com",
"spotfleet.amazonaws.com",
"ecs.application-autoscaling.amazonaws.com",
"autoscaling.amazonaws.com"
In the case of Fargate, both IAM role pay different role
Execution Role
This is role is mandatory and you can not run the task without this role even if you add ExecuationRole policy in Task Role
To produce this error just set Execution role =None, you will not able to launch the task.
AWS Forums (Unable to create a new revision of Task Definition)
Task Role
This role is optional and you can add s3 related permission in this role,
Optional IAM role that tasks can use to make API requests to authorized AWS services.
Your police seems okay,
Create ecs_s3_upload_role
Add below policy
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject"
],
"Resource": "arn:aws:s3:::example_bucket/*"
}
]
}
Now Fargate Task will able to upload to S3 bucket.
Your policies don't include any s3 related permissions. Thus you should define your s3 permissions in a task role:
With IAM roles for Amazon ECS tasks, you can specify an IAM role that can be used by the containers in a task.
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"
}
]
}
I'm trying to create an IAM role and assign it to an EC2 instance according to Attach an AWS IAM Role to an Existing Amazon EC2 Instance by Using the AWS CLI.
The policy looks like below:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
But it gives this error:
This policy contains the following error: Has prohibited field Principal
There is a similar question here but it couldn't fix this issue.
Any help would be appreciated.
Faced the same issue when trying to update the "Trust Relationship" Or same known as "Trust Policy".
"Principal" comes to play only in "Trust Policy". May be by mistake you are updating normal policy falling under the permissions tab. Try updating the policy under "Trust Relationships" tab as below:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"ec2.amazonaws.com",
"lambda.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
The easiest way to create a Service Role is:
Go to the IAM Console
Click Roles
Create new Role
Select an Amazon EC2 service role
Then attach your policies
It will create the trust policy for you.
Please note that the Trust Policy is stored in a separate location to the actual Policy (the bit that assigns permissions). Based upon the error message, it seems like you're putting the trust policy in the normal spot, because Roles don't need a principle (but trust policies do).
write a policy inside bucket --> permissions --> bucket policy --> save
Note: don't write policy in iam console and bucket and cloud-watch regions must be same. other region wont work.
use below policy
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "logs.YOUR-CLOUD-WATCH-REGION.amazonaws.com"
},
"Action": "s3:GetBucketAcl",
"Resource": "arn:aws:s3:::YOUR-BUCKET-NAME"
},
{
"Effect": "Allow",
"Principal": {
"Service": "logs.YOUR-CLOUD-WATCH-REGION.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::YOUR-BUCKET-NAME/*",
"Condition": {
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control"
}
}
}
]
}