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

score 93 · Answer 1 · edited Aug 29 '23 at 13:52

93

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.

edited Aug 29 '23 at 13:52

jarmod

71,565
16
115
122

answered Aug 07 '18 at 14:11

rubyisbeautiful

1,840
1
16
15

18

Unbelievable that cloudformation error reporting is so bad that you have to paper parse and debug. – Adrian Baker Jan 08 '19 at 04:29
I got it because I had written {AWS::Region} instead of ${AWS::Region} in a resource reference – Daniel Persson Feb 12 '21 at 12:37

score 24 · Answer 2 · edited Feb 24 '21 at 02:54

24

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

edited Feb 24 '21 at 02:54

John Mee

50,179
34
152
186

answered May 27 '19 at 12:36

aspdeepak

2,640
2
32
37

2

wow....and I thought a missing semicolon was hard to spot....thank you! – jones-chris Feb 06 '20 at 21:52
I was coding this in CDK and had the same problem. Strings will get you every time. – Helgi Aug 30 '21 at 18:43

score 16 · Answer 3 · answered Feb 24 '21 at 03:47

16

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

answered Feb 24 '21 at 03:47

John Mee

50,179
34
152
186

2

this is the best approach; the `serverless-pseudo-parameters` plugin has even been deprecated since this came out – Ulad Kasach Jun 11 '21 at 20:02

score 5 · Answer 4 · answered Jun 06 '19 at 07:53

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.

or maybe use `${AWS::AccountId}` instead – Putnik Nov 10 '21 at 11:18 — Putnik, Nov 10 '21 at 11:18

score 3 · Answer 5 · answered Apr 08 '21 at 21:21

3

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.

answered Apr 08 '21 at 21:21

BrianV

961
8
9

1

cfn-lint failed to catch my error - it's a great tool but it's not perfect! – shearn89 Apr 13 '22 at 11:33

score 1 · Answer 6 · answered Jun 14 '21 at 13:28

1

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

answered Jun 14 '21 at 13:28

Zachary Ryan Smith

2,688
1
20
30

Only the `prefix` and `action` values are case-insensitive. For example, `iam:ListAccessKeys` and `IAM:listaccesskeys` are equivalent. – jarmod Aug 29 '23 at 13:57

score 0 · Answer 7 · answered Mar 27 '17 at 12:22

0

I don't think you can wildcard the region on the arn, so you may need something like this instead:

arn:aws:logs:us-east-1:*:*

, where you specify the region you are using in place of us-east-1.

More information here:

http://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html#arn-syntax-cloudwatch-logs

answered Mar 27 '17 at 12:22

E.J. Brennan

45,870
7
88
116

Thanks for responding, though I specify the region I am getting same errors. – Mani Teja Mar 27 '17 at 13:01

score 0 · Answer 8 · answered Aug 15 '17 at 00:53

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

score 0 · Answer 9 · answered Oct 11 '17 at 20:08

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

score 0 · Answer 10 · answered Apr 13 '22 at 11:32

0

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 $!

answered Apr 13 '22 at 11:32

shearn89

798
1
9
24

score 0 · Answer 11 · answered Jun 30 '22 at 00:30

0

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

answered Jun 30 '22 at 00:30

Cesar Murphy

3
1
3

Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Jul 05 '22 at 10:59

score 0 · Answer 12 · answered Dec 17 '22 at 19:23

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)

The policy failed legacy parsing

12 Answers12

debugging tools

also good to know

Linked