I am using Terraform to deploy a service role for CodeBuild using a trust policy from this guide.
The service role mentioned in the guide set conditions on the trust policy to avoid the confused deputy problem, but with those conditions CodeBuild is not able to assume the role with this error:
CodeBuild is not authorized to perform: sts:AssumeRole on arn:aws:iam::<account-ID>:role/<my-role>
Without the conditions everything works fine.
Any suggestions?
Trust policy from the guide:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "codebuild.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "<account-ID>"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:codebuild:<region-ID>:<account-ID>:project/<project-name>"
}
}
}
]
}
Generated trust policy in my role:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "codebuild.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "<account-ID>"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:codebuild:us-west-2:<account-ID>:project/<my-project>"
}
}
}
]
}
Related
I want to restrict my sqs to accept only from event-bridge rule, below IAM rule looks correct with deny in place, but sqs not receiving message with this, any input appreciated.
{ "Id": "Policy", "Version": "2012-10-17", "Statement": [
{
"Sid": "sid",
"Action": [
"sqs:SendMessage"
],
"Effect": "Deny",
"Resource": "arn:aws:sqs:us-east-1:***:sri-test-queue-3",
"Condition": {
"ArnNotEquals": {
"aws:SourceArn": "arn:aws:events:us-east-1:***:rule/sri-test-bus/sri-test-sqs-rule"
}
},
"Principal": "*"
} ] }
The one generated by Event-bridge to allow sqs access looks like this
{
"Version": "2008-10-17",
"Id": "__default_policy_ID",
"Statement": [
{
"Sid": "AWSEvents_sri-test-sqs-rule_Id12",
"Effect": "Allow",
"Principal": {
"Service": "events.amazonaws.com"
},
"Action": "sqs:SendMessage",
"Resource": "arn:aws:sqs:us-east-1:***:sri-test-queue-3",
"Condition": {
"ArnEquals": {
"aws:SourceArn": "arn:aws:events:us-east-1:***:rule/sri-test-bus/sri-test-sqs-rule"
}
}
}
]
}
Use the bottom policy. SQS policy denies by default, so you do not need to worry about other resources posting messages to SQS. The policy would allow only arn:aws:events:us-east-1:***:rule/sri-test-bus/sri-test-sqs-rule to send the messages.
The problem with the policy statement you wrote was that you did not have an "Allow" statement, so SQS is denying SendMessage actions from every source.
We just had to put some combination of principalTypes to achieve this, below one worked finally
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ownerstatement",
"Effect": "Allow",
"Principal": {
"Service": "events.amazonaws.com"
},
"Action": "sqs:SendMessage",
"Resource": "arn:aws:sqs:us-east-1:xxxx:sri-test-queue-3"
},
{
"Sid": "DenyAllExceptBus",
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Action": "sqs:SendMessage",
"Resource": "arn:aws:sqs:us-east-1:xxxx:sri-test-queue-3",
"Condition": {
"ArnNotEquals": {
"aws:SourceArn": [
"arn:aws:events:us-east-1:xxxx:rule/sri-test-bus/sri-test-sqs-rule"
]
}
}
}
]
}
I am trying to assume a role (in Account B) from inside of an EKS Pod (in Account A). When running aws sts get-caller-identity from inside of the pod, I get:
/app # aws sts get-caller-identity
{
"UserId": "AROAXXXXXXXXXXXCQLF:botocore-session-1659114796",
"Account": "00ACCOUNTA00",
"Arn": "arn:aws:sts::00ACCOUNTA00:assumed-role/my-pod-role/botocore-session-1659114796"
}
The Trust Relationship configs I have tried in arn:aws:iam::00ACCOUNTB00:role/yolo-test-role (In Account B) which are not working:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::00ACCOUNTA00:role/my-pod-role"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
and
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::00ACCOUNTA00:root"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
],
"Condition": {
"StringLike": {
"aws:userId": "AROAXXXXXXXXXXXCQLF:*"
}
}
}
]
}
and
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "00ACCOUNTA00"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
],
"Condition": {
"StringLike": {
"aws:userId": "AROAXXXXXXXXXXXCQLF:*"
}
}
}
]
}
When I try to run a aws sts assume-role --role-arn 'arn:aws:iam::00ACCOUNTB00:role/yolo-test-role' --role-session-name metesting from the pod, I get:
An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:sts::00ACCOUNTA00:assumed-role/my-pod-role/botocore-session-1659114796 is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::00ACCOUNTB00:role/yolo-test-role
I am creating and running a task on my ECS fargate cluster.
Task definition (with role) and fargate cluster is already created.
When I use run task step in step function, I am getting following error,
{
"Error": "ECS.AccessDeniedException",
"Cause": "User: arn:aws:sts::xxxxxxxxxx:assumed-role/StepFunctions-my-state-machine-role-xxxxxxxxxx/xxxxxxxxxx is not authorized to perform: iam:PassRole on resource: arn:aws:iam::xxxxxxxxxx:role/my-app-dev-exec because no identity-based policy allows the iam:PassRole action (Service: AmazonECS; Status Code: 400; Error Code: AccessDeniedException; Request ID: xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx; Proxy: null)"
}
The role attached to the step function has the following policies (as per the documentation provided by AWS https://docs.aws.amazon.com/step-functions/latest/dg/ecs-iam.html)
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecs:RunTask"
],
"Resource": [
"arn:aws:ecs:eu-west-1:xxxxxxxxxx:task-definition/*:*"
]
},
{
"Effect": "Allow",
"Action": [
"ecs:StopTask",
"ecs:DescribeTasks"
],
"Resource": [
"arn:aws:ecs:eu-west-1:xxxxxxxxxx:task/*"
]
},
{
"Effect": "Allow",
"Action": [
"events:PutTargets",
"events:PutRule",
"events:DescribeRule"
],
"Resource": [
"arn:aws:events:eu-west-1:xxxxxxxxxx:rule/StepFunctionsGetEventsForECSTaskRule"
]
},
{
"Effect": "Allow",
"Action": [
"states:DescribeStateMachine",
"states:StartExecution",
"states:ListExecutions",
"states:UpdateStateMachine"
],
"Resource": [
"arn:aws:states:eu-west-1:xxxxxxxxxx:stateMachine:my-state-machine"
]
}
]
}
with following trusted entities
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "states.amazonaws.com"
},
"Action": "sts:AssumeRole"
},
{
"Effect": "Allow",
"Principal": {
"Service": "events.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
Can someone help with what additional permission I need to give to resolve the above permission issue? From the error, I am not able to figure out what additional permission is required.
If I attach AmazonECS_FullAccess (aws managed) policy to the role, job works perfectly.
Because your task will use an IAM Role, you need to specify the additional permission 'PassRole'.
The best practice is to restrict which roles can be passed. So is recommended to add a condition limiting to only allow to pass roles to ECS tasks.
Try adding this statement to your policy:
{
"Action": "iam:PassRole",
"Effect": "Allow",
"Resource": [
"*"
],
"Condition": {
"StringLike": {
"iam:PassedToService": "ecs-tasks.amazonaws.com"
}
}
}
I’ve created a set of AWS Lambdas using the Serverless framework, and a React app which calls these. A user pool and an identity pool have been setup in AWS Cognito, and a table in DynamoDB. (I've followed the tutorial on serverless-stack.com). It's a simple notes app.
The client app is deployed to: https://dev.cakebook.co
The API is deployed: https://api.cakebook.co/dev/orders
However, after I log in using this Cognito user:
admin#example.com
Passw0rd!
I get a 403 response for the GET of the orders:
message: “User: arn:aws:sts::********8766:assumed-role/cakebook-api-dev-CognitoAuthRole-1DTRT5XGEGRXW/CognitoIdentityCredentials is not authorized to perform: execute-api:Invoke on resource: arn:aws:execute-api:us-east-2:********8766:sss6l7svxc/dev/GET/orders”
I'm new to all this, but it looks like my Cognito user does not have permission to call the Lambda (or API gateway?). Is that the issue? If so, how do I give the users permission to call the Lambdas?
UPDATE, requested JSON
Execution Role:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"logs:CreateLogStream"
],
"Resource": [
"arn:aws:logs:us-east-2:********8766:log-group:/aws/lambda/cakebook-api-dev-create:*",
"arn:aws:logs:us-east-2:********8766:log-group:/aws/lambda/cakebook-api-dev-get:*",
"arn:aws:logs:us-east-2:********8766:log-group:/aws/lambda/cakebook-api-dev-list:*",
"arn:aws:logs:us-east-2:********8766:log-group:/aws/lambda/cakebook-api-dev-update:*",
"arn:aws:logs:us-east-2:********8766:log-group:/aws/lambda/cakebook-api-dev-delete:*"
],
"Effect": "Allow"
},
{
"Action": [
"logs:PutLogEvents"
],
"Resource": [
"arn:aws:logs:us-east-2:********8766:log-group:/aws/lambda/cakebook-api-dev-create:*:*",
"arn:aws:logs:us-east-2:********8766:log-group:/aws/lambda/cakebook-api-dev-get:*:*",
"arn:aws:logs:us-east-2:********8766:log-group:/aws/lambda/cakebook-api-dev-list:*:*",
"arn:aws:logs:us-east-2:********8766:log-group:/aws/lambda/cakebook-api-dev-update:*:*",
"arn:aws:logs:us-east-2:********8766:log-group:/aws/lambda/cakebook-api-dev-delete:*:*"
],
"Effect": "Allow"
},
{
"Action": [
"dynamodb:DescribeTable",
"dynamodb:Query",
"dynamodb:Scan",
"dynamodb:GetItem",
"dynamodb:PutItem",
"dynamodb:UpdateItem",
"dynamodb:DeleteItem"
],
"Resource": [
"arn:aws:dynamodb:us-east-2:********8766:table/orders"
],
"Effect": "Allow"
},
{
"Sid": "1",
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-east-2:********8766:function:cakebook-api-dev-list",
"Condition": {
"ArnLike": {
"AWS:SourceArn": "arn:aws:cognito-identity:us-east-2:********8766:identitypool/us-east-2:d9e4e505-c64a-4836-8e56-3af843dbe453"
}
}
}
]
}
Function Policy:
{
"Version": "2012-10-17",
"Id": "default",
"Statement": [
{
"Sid": "cakebook-api-dev-ListLambdaPermissionApiGateway-U7OCBI3JM44G",
"Effect": "Allow",
"Principal": {
"Service": "apigateway.amazonaws.com"
},
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-east-2:********8766:function:cakebook-api-dev-list",
"Condition": {
"ArnLike": {
"AWS:SourceArn": "arn:aws:execute-api:us-east-2:********8766:w5o4vxx4f0/*/*"
}
}
},
{
"Sid": "lambda-da48f6d0-6d3c-4bbf-a761-ca3510f79624",
"Effect": "Allow",
"Principal": {
"Service": "cognito-sync.amazonaws.com"
},
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-east-2:********8766:function:cakebook-api-dev-list",
"Condition": {
"ArnLike": {
"AWS:SourceArn": "arn:aws:cognito-identity:us-east-2:********8766:identitypool/us-east-2:d9e4e505-c64a-4836-8e56-3af843dbe453"
}
}
}
]
}
You need to update Lambda permission to allow invoking by Cognito user pool.
Option A - update permission in JSON format
{
"Version": "2012-10-17",
"Id": "default",
"Statement": [
{
"Sid": "lambda-something",
"Effect": "Allow",
"Principal": {
"Service": "cognito-sync.amazonaws.com"
},
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:eu-west-1:__accountId__:__function_name__",
"Condition": {
"ArnLike": {
"AWS:SourceArn": "arn:aws:cognito-identity:eu-west-1:__accountId__:identitypool/eu-west-1:....."
}
}
}
]
}
Option B - in console
Go to Lambda Configuration page
Add trigger Cognito Sync Trigger
During saving it will offer to configure Lambda permission automatically - agree
I am trying to connect boxfuse to my aws account
i am getting the below. Any help is highly appreciated
`Role with ARN arn:aws:iam::535880694150:role/Boxfuse-access has not been properly configured. Please check your configuration and try again. (AWSSecurityTokenService: AccessDenied -> User: arn:aws:iam::762186188748:user/boxfuse-console is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::535880694150:role/Boxfuse-access)`
I followed the instructions as provided by Boxfuse, Am i missing something, Do i need to do anything special.I used the policy provide by boxfuse
{"Version": "2012-10-17","Statement":[
{"Sid":"allow","Effect":"Allow","Resource":["*"],
"Action":["ec2:*","elasticloadbalancing:*","autoscaling:*","rds:*","cloudwatch:*","iam:ListInstanceProfiles","iam:PassRole"]},
{"Sid":"ec2Deny","Effect":"Deny",
"Action":["ec2:*"],"Resource":["*"],"Condition":{"StringEquals":{"ec2:ResourceTag/boxfuse:ignore":"true"}}},
{"Sid":"rdsDeny","Effect":"Deny",
"Action":["rds:*"],"Resource":["*"],"Condition":{"StringEquals":{"rds:db-tag/boxfuse:ignore":"true"}}}]}
This is how my trust relationship in Iam role policy looks like
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::762186188748:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "uxvmGXwfII4944dh"
},
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
}
]
}
As stated in the instructions, multi-factor access should be turned off. In your case this can be fixed by updating the policy document to:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::762186188748:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "uxvmGXwfII4944dh"
}
}
}
]
}