Reputation: 769

The policy failed legacy parsing

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"
}]}

Upvotes: 76

Answers (12)

rubyisbeautiful

Reputation: 2120

I got this error, and couldn't figure it out. A colleague and I pored 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.

Upvotes: 118

mksm

Reputation: 4553

These tools could be useful:

debugging tools

UI in AWS web-console policysim (though, you will need permissions to use it)
CLI tool accessanalyzer (it is not very clear how to run it without these examples in GH repo)
CloudTrail with this guide can help you find recent issues

also good to know

serverless variables (if you use sls), be careful with ${AWS::AccountId} - i had #{....} in my config and I end up writing this
AWS advice on validate policies

Have no idea why AWS CloudFormation didn't become more helpful over this time. Still any $ or ${ will be a great source of fun, especially when the deployed stack is not basic (for example, you have a serverless, and every attempt takes >5 min)

Upvotes: 1

Cesar Murphy

Reputation: 3

I also got this error, mine was related to a missing $ when using !Sub to substitute a variable.

I.e.:

"Resource": { "Fn::Sub": "arn:aws:sqs:ap-northeast-1:{SOME_ID_HERE}:test-messages" }

When the correct expression should be:

"Resource": { "Fn::Sub": "arn:aws:sqs:ap-northeast-1:${SOME_ID_HERE}:test-messages" }

Upvotes: 0

shearn89

Reputation: 897

Had this today - cfn-lint was happy but I'd got:

- !Sub "arn:aws:ec2:${AWS::Region}:{AWS::AccountId}:network-interface/*"

instead of:

- !Sub "arn:aws:ec2:${AWS::Region}:${AWS::AccountId}:network-interface/*"

A missing $!

Upvotes: 0

Zachary Ryan Smith

Reputation: 2768

my issue was that i tried "Effect": "ALLOW" instead of "Effect": "Allow". Smh...

Upvotes: 2

BrianV

Reputation: 1476

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.

Upvotes: 3

John Mee

Reputation: 52323

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).

Upvotes: 21

aspdeepak

Reputation: 2781

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

Upvotes: 27

Max Kaye

Reputation: 51

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.

Upvotes: 5

BlackJeep

Reputation: 33

I would think you could do

    "Resource": "arn:aws:logs:us-west-2:123456789012:*"

but if not, you can map your accounts to the region with a mapping:

    "mAWSRegionToAccountsMap": {
        "us-west-2": {
            "prod": "444444444673",
            "dev": "678333333333"

        },
        "us-gov-west-1": {
            "dev": "12345678903",
            "prod": "234345345345"
        }
    }

Then integrate the mapping into a join using a ":" for the delimiter

    "Resource": {
        "Fn::Join": [
            ":",
            [
                "arn:aws:logs",
                { 
                    "Ref": "AWS::Region" 
                },
                {
                    "Fn::FindInMap": [
                        "mAWSRegionToAccountsMap",  {
                            "Ref": "AWS::Region"
                        },
                        "prod"
                    ]
                },
                "/*"
            ]
        ]
    }

May need to tweak the ending

Upvotes: 0

hayduke

Reputation: 121

One issue you may have is cloudwatch Logs ARNS can have 6 : symbols because there is an extra between log group and log stream. For example:

"Resource": "arn:aws:logs:us-west-2:123456789012:/my/log/group:log-stream"

or for your case:

"Resource": "arn:aws:logs:*:*:*:*

I have found that some ARNS such as the more specific example above give this error if a 6th : is not added. I realize this does contradict the docs (including doc provided by E.J) so perhaps it's a bug within AWS somewhere

http://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/iam-identity-based-access-control-cwl.html

Upvotes: 0