Aws-cdk: (aws-iam): StringParameter.value_from_lookup's dummy value did not suffice

[ThomasSteinbach]

aws_iam.StringParameter.value_from_lookup(...)

returns a dummy-value-for-${parameterName} during synthesis (from #3654). This value did not suffice for use as ARN. The dummy value itself should represent a dummy ARN pattern to avoid errors.

Reproduction Steps

Here is a short (and stripped) example, which currently leads to an error:

aws_kms.Key.from_key_arn(
    self,
    id,
    key_arn=aws_ssm.StringParameter.value_from_lookup(
        self,
        parameter_name="/example/param",
    ),
)

Error Log

During synthesis this leads to an error:

jsii.errors.JSIIError: ARNs must have at least 6 components: dummy-value-for-/example/param

Workaround

_param = aws_ssm.StringParameter.value_from_lookup(self, parameter_name="/example/param")

if "dummy-value" in _param:
    _param = "arn:aws:service:eu-central-1:123456789012:entity/dummy-value"

aws_kms.Key.from_key_arn(
    self,
    id,
    key_arn=_param,
)

Solution Proposal

Instead of dummy-value-for-${parameterName} the method should return something like arn:aws:service:eu-central-1:123456789012:entity/dummy-value

This solution would also address/solve #7051

---

This is :bug: Bug Report

[ThomasSteinbach]

Hi @eladb , is looks like you have created the original implementation of the "dummy-value" for ssm-StringParameters. If so, could you please have a look on my proposed solution code (#8700 ) for this bug report and "do it right", as I am no TypeScript programmer? Thank you :)

[MrArnoldPalmer]

@ThomasSteinbach I'm curious to know about the use case that is breaking with this right now. Can you provide details about what constructs/processes you're using that aren't supported currently?

[github-actions[bot]]

This issue has not received a response in a while. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.

[rix0rrr]

The dummy return value should probably be a Token, this should suppress literal string validation in most of the CDK.

[ThomasSteinbach]

Sorry @MrArnoldPalmer for the late response. (I spent my last 14d in holidays). Regarding your questions:

I'm curious to know about the use case that is breaking with this right now.

The _Reproduction Steps_ in the issues description will give you one use case ( 'aws_kms.Key` can't handle the current dummy values).

Without testing it, in my description I also statet that the solution, provided with this issue ( https://github.com/aws/aws-cdk/pull/8700 ), may resolve https://github.com/aws/aws-cdk/issues/7051 , which then is also a use case, as aws_s3.Bucket.from_bucket_arn will raise the exact same error on the current dummy value.

Can you provide details about what constructs/processes you're using that aren't supported currently?

As shown in the descriptions example, aws_kms.Key.from_key_arn() would not support the dummy-value-for-${parameterName} returned by aws_ssm.StringParameter.value_from_lookup() but would support arn:aws:service:eu-central-1:123456789012:entity/dummy-value as proposed in my solution https://github.com/aws/aws-cdk/pull/8700/files.

The proposed solution should work for all other resource methods requiring an ARN, like aws_s3.Bucket.from_bucket_arn.

We've tested workaround (for python) given in the description, and it worked well for us under every circumstances. The proposed solution would fix the issue natively in TypeScript. However a professional TypeScript programmer should review and "cleanup" the solution.

[MrArnoldPalmer]

@ThomasSteinbach thanks, I didn't derive all those details from the original post.

Since ssm params can obviously contain stuff other than Arns, and validations may be anything really, a more generic solution is required I believe. As @rix0rrr mentioned, we can possibly change the dummy value return type to be a Token, which makes sense since Tokens are stand ins for values that will resolve at some point in the future.

[ThomasSteinbach]

As long as it works, I am totally fine with any solution 😃

As Python-CDK user I feel not able to provide a clean solution for replacing the current dummy values by tokens. Could you please provide one or delegate it to a CDK TypeScript programmer? I am confident, that it should be no extravagant expense but would solve this as well as this https://github.com/aws/aws-cdk/issues/7051 issue.

Thanks in advance

[zxkane]

Another use case,

If putting the json string into SSM parameter store for externalizing the parameters of CDK app, the valueFromLookup always immediately returns the default value that breaks the JSON parsing.

[jishi]

I'm getting this problem when trying to "import" an SNS topic via ARN that I get from parameter store:

const cachePurgeTopicArn = StringParameter.valueFromLookup(
      this, '/infrastructure/topic/cache-purge');
const cachePurgeTopic = Topic.fromTopicArn(this, 'CachePurgeTopic', cachePurgeTopicArn);

Meaning, I can't synthesize this to validate it. This works fine with importing VPCs, ALB listeners, ECS cluster ecs and actually synthesize to the actual parameter store value, so I'm not sure why this becomes a dummy value in this example?

EDIT: OH wait, it only fails on first run? If I run the lookup first, then add the .fromTopicArn, it works? Because of resource caching I guess, that's even weirder...

[jishi]

This actually fails for deploy runs as well, not only synthesizing. Making it somewhat cumbersome to store ARNs on SSM without having to jump through hoops to create the cdk context first without actually using the values.