Here is a role I already declared with a policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sqs:ReceiveMessage",
"sqs:DeleteMessage",
"sqs:GetQueueAttributes",
"sqs:ChangeMessageVisibility",
"sqs:GetQueueUrl"
],
"Resource": "arn:aws:sqs:*:<my-account>:my-prefix-*"
}
]
}
When I deploy manually my queue and Lambda (with Trigger) everything is OK (and it is working as expected). However when I deploy with CDK it tries to add a new inline policy which looks exactly the same (without wildcards):
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sqs:ReceiveMessage",
"sqs:DeleteMessage",
"sqs:GetQueueAttributes",
"sqs:ChangeMessageVisibility",
"sqs:GetQueueUrl"
],
"Resource": "arn:aws:sqs:eu-west-3:<my-account>:my-prefix-MYRESOURCE-CREATED"
}
]
}
My questions:
Why CDK do not detect that policy is the same ?
If it is working as design, is there a way to not include IAM changes ?
I am not referencing to How to skip IAM change confirmation during a cdk deploy? where user wants an auto approval.
Thanks and regards
I assume you are passing a role parameter into your Lambda Function.
If you don't want CDK to automatically add inline policies to this role, you may want to use .without_policy_updates():
Use the object returned by this method if you want this Role to be used by a construct without it automatically updating the Role’s Policies.
If you do, you are responsible for adding the correct statements to the Role’s policies yourself.
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 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 created a custom managed AWS IAM policy as follows:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1567509959500",
"Action": [
"codecommit:DeleteBranch",
"codecommit:GitPush",
"codecommit:MergeBranchesByFastForward",
"codecommit:MergeBranchesBySquash",
"codecommit:MergeBranchesByThreeWay",
"codecommit:MergePullRequestByFastForward",
"codecommit:MergePullRequestBySquash",
"codecommit:MergePullRequestByThreeWay",
"codecommit:PutFile"
],
"Effect": "Deny",
"Resource": [
"arn:aws:codecommit:us-east-1:420843264582:ui-repos",
"arn:aws:codecommit:us-east-1:420843264582:API-repos"
],
"Condition": {
"StringEquals": {
"codecommit:References": "refs/heads/master"
}
}
}
]
}
But any user on which this policy is applied is getting 403 when Git pushes to any branch.
I want users to create branches, allow all operations on other branches except the master branch.
Thanks!
If this is the whole thing (you put the json inside the question really - why external link?), then you only have a deny statement and nothing to grant your users any rights to codecommit.
I'm relatively new to AWS and am trying to figure out how the role policies work. I've read the AWS documentation, which is very comprehensive, but the policy I'm applying still isn't doing what I expect... let me explain
I'm trying to grant access to a role so that, when it is assumed, it can do stuff with lambda
I've create a role called "deployer".
I've then attached the below policy to that role:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "1",
"Effect": "Allow",
"Action": "lambda:*"
"Resource": "arn:aws:iam::<account_id>:role/deployer"
}
]
}
My expectation here is that the Policy says... The specified resource (the deployer role) is "Allowed" to do any action with the Lambda service
However, when I switch to that role in the front end, I get the following error in the Lambda dashboard:
You are not authorized to perform: lambda:GetAccountSettings.
The only solution I've found is to wildcard the Resource attribute in the Policy... however that sort of negates the purpose of trying to restrict access to only that role
Example of the Policy that does what I want
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "1",
"Effect": "Allow",
"Action": "lambda:*"
"Resource": "*"
}
]
}
Could someone explain to me what is actually happening here? I've clearly not understood what the Resource attribute is used for... To me that second Policy says any resource can do anything with Lambda...
Thanks
You're attempting to define the role to apply the policy to in the resource attribute - that's not what the resource attribute is for. The resource attribute relates to the Lambda functions you want the user to be able to call.
To assign this policy to a role, simply create the policy as above (defining your Lambda resources appropriately, which could be a wildcard if you really want to apply this to all your Lambda functions) then assign the policy to a role in the IAM console.
See here for more information on defining resources.
Change
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "1",
"Effect": "Allow",
"Action": "lambda:*"
"Resource": "arn:aws:iam::<account_id>:role/deployer"
}
]
}
to
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "1",
"Effect": "Allow",
"Action": "lambda:*"
"Resource": "arn:aws:lambda:<region>:<account_number>:function:my-awesome-lambda-function"
}
]
}
I'm trying to allow all EC2 instances in our AWS account to stop themselves (using an automated script that uses the aws cli). I try to do so by creating an AWS IAM role with the propper policy. However, I can't find how to define the policy to only Allow instances to stop itself (and not other instances).
I tried with the following policy
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:StopInstances"
],
"Resource": [
"${ec2:SourceInstanceARN}"
]
}
]
}
But on validation, this gives me the error This policy contains the following error: The following resources are invalid : ${ec2:SourceInstanceARN}
Is there a way to allow an instance to stop itself (and only itself)? If so, how should I do it?
Shutdown behavior solves the problem with termination but there might be other scenarios that require limited access to API requests (i.e. self tagging). So here's a solution with IAM policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"ec2:DeleteTags",
"ec2:DescribeTags",
"ec2:CreateTags",
"ec2:TerminateInstances",
"ec2:StopInstances"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ARN": "${ec2:SourceInstanceARN}"
}
}
}
]
}
As Mark B suggested in the comments, I solved my problem by changing my script to use shutdown rather than aws ec2 stop-instances. This makes the use of any policy needless, as any system can execute shutdown on itself (and only itself).