Tag: iam

Posted on

serverless framework remove error: “An error occurred: xyzRole – Cannot delete entity, must detach all policies first.”

Attempting a ‘serverless remove’ on a deployed error, I got this unexpected error I haven’t seen before:

An error occurred: xyzRole - Cannot delete entity, must detach all policies first.

A quick Google found an issue with the same error and an explanation. There is another policy attached to this Lambda that was not added via the serverless.yml for this stack, so CloudFormation is refusing to delete it. This answer describes exactly what I had done to add the new policy:

I also had added XRay to this Lambda via the Console, and this added an additional managed policy to enable Xray. Checking the IAM Role, here’s the XRay related policy that was added:

I deleted the XRay policy, but at this point serverless has already removed most of the stack but left the IAM role in place, but won’t delete the stack itself, so a manual delete from the Console completed the cleanup.

Posted on

Enabling AWS API Gateway CloudWatch logging

I deployed a new Lamdba with API Gateway, and when I tried turning on the CloudWatch logging for this API Gateway from the console:

… I got this error that I haven’t seen before:

Turns out per the steps on this page, you need to create an IAM role with API Gateway as the Trusted Entity, and attach the managed policy ‘AmazonAPIGatewayPushToCloudWatchLogs’ :

Add the ARN for the role you created to the Settings for the API you are working with here:

Done!

Posted on

Using Serverless framework and AWS sts:assume-role to cross deploy to different AWS accounts

In order to assume a role in another account, the owning account needs to grant a ‘trust relationship’ to those allowed to assume the role. This can be done by referencing an IAM username or role for those in the other account that are allowed to assume this role.

You can do this in the Console using the Trust Relationship tab:

A Policy to grant access to to a specific IAM user looks like:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::ACCOUNT-ID:user/USER-ID"
      },
    "Action": "sts:AssumeRole"
    }
  ]
}

To assume this role, use the ‘aws sts assume-role’ cli command:

aws sts assume-role --role-arn arn:aws:iam::ACCOUNT-ID:role/ROLE-NAME --role-session-name SESSION-NAME

If this is successful, you’ll see a response that grants temporary values for the following AWS credentials that can be used after this point:

  • AccessKeyId
  • SecretAccessKey
  • SessionToken

The returned values can be used to set env vars to use with the CLI and other AWS SDK apps:

  • export AWS_ACCESS_KEY_ID=
  • export AWS_SECRET_ACCESS_KEY=
  • export AWS_SESSION_TOKEN=
  • export AWS_DEFAULT_REGION=

For Servlerless to deploy into another account, if you attempt a Serverless deploy at this point, you’ll see errors like:

User: arn:aws:sts::ACCOUNT-ID:assumed-role/ServerlessLambdaDeployRole/lambdadeploy is not authorized to perform: cloudformation:CreateStack on resource: arn:aws:cloudformation:us-east-1:TARGET-ACCOUNT-ID:stack/deploy-demo/*

In this case cloudformation:CreateStack is missing from the assumed role. If you incrementally attempt to find what additional permissions you’ll need to deploy, you’ll also need to add:

  • cloudformation:DescribeStackEvents
  • cloudformation:DescribeStackResource
  • cloudformation:ValidateTemplate
  • cloudformation:UpdateStack
  • cloudformation:DeleteStack
  • apigateway:POST
  • iam:CreateRole
  • iam:PutRolePolicy

ValidateTemplate appears to throw an error unless the Resource is for a wildcard of ‘*’ and not anything more specific, otherwise you’ll see this error:

Error: The CloudFormation template is invalid: User: arn:aws:sts::ACOUNT-ID:assumed-role/ServerlessLambdaDeployRole/lambdadeploy is not authorized to perform: cloudformation:ValidateTemplate

To grant permissions for ValidateTemplate specify a Resource of “*”

{
"Sid": "CreateCloudFormationStackValidate",
"Effect": "Allow",
"Action": [
"cloudformation:ValidateTemplate"
],
"Resource": "*"
}

The STS temporary credentials will expire after 1 hour, so if you see this error:

An error occurred (ExpiredToken) when calling the AssumeRole operation: The security token included in the request is expired

then you’ll need to rerun the ‘aws sts assume-role’ command again. If you previously set the session token in AWS_SESSION_TOKEN, you’ll need to set it back to blank (along with AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY) before you run the command again. When you get the refreshed values, remember to set the env vars with the updated values.

At this point, if you’ve run ‘aws sts assume-role’ and you’ve set the env vars for the returned temp credentials, you’ll be able to run a ‘serverless deploy’ and deploy into the other account where you’ve assumed this new role with the permissions to deploy. This should include permissions for creating a new Lambda and API Gateway, if you’re deploying anything else from your serverless config, you’ll need to add those permissions to the role you’re assuming.

Proudly powered by WordPress