The policy failed legacy parsing

Question

I am trying to create IAM Role in AWS, but while I am creating I am facing error

"We encountered the following errors while processing your request: Problem in attaching permission to role. Role will be created without permission. The policy failed legacy parsing "

{"Version": "2012-10-17",  "Statement": [
{
  "Effect": "Allow",
  "Action": [
    "logs:CreateLogGroup",
    "logs:CreateLogStream",
    "logs:PutLogEvents"
  ],
  "Resource": "arn:aws:logs:*:*:*"
},
{
  "Action": [
    "sqs:SendMessage",
    "sqs:GetQueueUrl"
  ],
  "Effect": "Allow",
  "Resource": "arn:aws:sqs:ap-northeast-1:SOME_ID_HERE:test-messages"
}]}

Solution 1

I got this error, and couldn't figure it out. A colleague and I poured over it, and then we spotted that I had left a substitution variable without the Fn::Sub, e.g.

"Resource": "arn:aws:logs::${AWS::AccountId}:*

will cause this error, and of course should be

"Resource": { "Fn::Sub": "arn:aws:logs::${AWS::AccountId}:*" }

BTW, in my experience, I agree with E.J. Brennan above, you cannot use a wildcard for region, instead leave it blank as I did there.

Solution 2

If it fails for s3, ensure that you are using the correct arn format:

• Correct one is 3 ::: arn:aws:s3:::AccountABucketName

  "Resource": "arn:aws:s3:::AccountABucketName"

• Wrong one 2 :: arn:aws:s3::AccountABucketName

  "Resource": "arn:aws:s3::AccountABucketName"

Count the number of colons between s3 and AccountABucketName

Solution 3

If you are using serverless you can indicate that you want variables substitution by prefixing the resource with !Sub:

  Resource:
    - !Sub arn:aws:dynamodb:*:${AWS::AccountId}:table/${self:provider.environment.DYNAMODB_TABLE}

No plugin required (if serverless version is recent).

Solution 4

A fun new error state I found today:

If:

• you have a CFN template where you provide an Account ID via a parameter
• AND you use the Default prop of the parameter to provide the Account ID
• AND the Account ID starts with a 0

CFN will actually read the parameter as an integer (and cast it to like 9.3476294382E10) - regardless of whether you have Type: String on the parameter, or use !!str to explicitly cast it.

So the solution is to manually provide the parameter to the deployment instead of using the Default: "093476294382".

Hope I can save someone else some time.

Solution 5

For debugging CloudFormation syntax errors (many of which have unhelpful error messages like the one above), I suggest validating with cfn-lint prior to deployment. You'll thank me later.

View more solutions

Comments

[Mani Teja]

Thanks for responding, though I specify the region I am getting same errors.

[Adrian Baker]

Unbelievable that cloudformation error reporting is so bad that you have to paper parse and debug.

[jones-chris]

wow....and I thought a missing semicolon was hard to spot....thank you!

[Daniel Persson]

I got it because I had written {AWS::Region} instead of ${AWS::Region} in a resource reference

[Ulad Kasach]

this is the best approach; the serverless-pseudo-parameters plugin has even been deprecated since this came out

[Helgi]

I was coding this in CDK and had the same problem. Strings will get you every time.

[Putnik]

or maybe use ${AWS::AccountId} instead

[shearn89]

cfn-lint failed to catch my error - it's a great tool but it's not perfect!