No obvious way to flag literal embedded parameter syntax as expected (E1029)

[trav-c]

cfn-lint version: (cfn-lint --version) cfn-lint 0.16.0

Description of issue. Fn::Sub style variables in parameter descriptions trigger E1029, however there is no obvious way to suppress this when the use of the ${Something} is intended to be literal, I suspect this may also be the case in other contexts where ${Something} is intended as a literal rather than missing a !Sub / Fn::Sub

To be clear the intent in the original where I encountered this was that the parameter description contain the literal embedded parameter syntax, eg : '${Test1}' and not be expanded.

The sample template below demonstrates the issue, ie Description properties containing literal embedded parameter syntax.

Sample Template

Description:
    "cfn-lint E1029 false positive"
Parameters:
    Test1:
        Type: String
        Description: "This parameter will replace ${Test1}"
    Test2:
        Type: String
        Description: "This parameter will replace ${!Test2}"

Resources:

    EIP:
        Type: AWS::EC2::EIP
        Properties:
            Domain: vpc

Outputs:
    Test1:
        Value: !Ref Test1
    Test2:
        Value: !Ref Test2

[fatbasstard]

Hi @trav-c,

I'm checking this issue now, and while reading through the documentation I came across something interesting (Source):

To write a dollar sign and curly braces (${}) literally, add an exclamation point (!) after the open curly brace, such as ${!Literal}. AWS CloudFormation resolves this text as ${Literal}.

I'm also wondering if the Usage of !Sub actually works in Parameters 🤔

So in short:

• The linter should take account of the exclamation mark (your Test2)
• Maybe the linter should ignore the Parameter section all together

Good catch!

[fatbasstard]

Ah, the second also answered by the documentation:

You can use intrinsic functions only in specific parts of a template. Currently, you can use intrinsic functions in resource properties, outputs, metadata attributes, and update policy attributes. You can also use intrinsic functions to conditionally create stack resources.

[trav-c]

I can see a few possible considerations here

• Because there is no support for intrinsics in Parameters requiring the use of ${!variable} in that context isn't entirely correct because ${variable} is genuinely a literal already, although would provide a fairly simple and reasonable approach, I certainly agree that it makes sense that the linter should consider ${!variable} in general though
• I can also see some argument for not ignoring parameters in this context, as it could catch cases where people are expecting them to be processed, and have missed the intrinsic.
• Regardless of both those points ideally there would be a way to handle the cases where Fn::Sub is not used, but could be and '${variable}' is intended as a literal.

So overall I'm not sure that it's any easy problem to solve well in general because I believe it is entirely reasonable that a template author could have genuinely intended the non-exclamation mark form as a literal, while it's also likely that the common case is simply that they intended to use !Sub. I could imagine genuine use cases, for example in a Lambda's Code property where !Sub isn't used, but the exclamation mark form is incorrect since there's nothing to remove the exclamation.

[PatMyron]

https://github.com/aws-cloudformation/cfn-lint/pull/2031 should help limit this occurring