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

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 Report

[sdhuang32]

I ran into this too, and found a bit more elegant solution recently, which was to use Lazy values. To be specific, the following example I use the Lazy.string() of the CDK core module, which encodes your variable as a token and defer the calculation of the string value to synthesis time.

import * as cdk from '@aws-cdk/core';
import * as ssm from '@aws-cdk/aws-ssm';
import * as iam from '@aws-cdk/aws-iam';

const roleArn = ssm.StringParameter.valueFromLookup(this, "/param/testRoleArn");
const role = iam.Role.fromRoleArn(this, "role", cdk.Lazy.string({ produce: () => roleArn }));

It’s more general because it can apply to many other use cases besides fromXXXArn() methods, and is in fact used in many places of internal CDK source to get values rendered at synthesis time, as long as the method you throw a lazy value to can handle tokens.

The following is an example that shows why I don’t think making ssm.StringParameter.valueFromLookup() return a token is a good idea.

When importing a VPC using ec2.Vpc.fromLookup(), just give the return value of the ssm.StringParameter.valueFromLookup() and it works.

import * as cdk from '@aws-cdk/core';
import * as ssm from '@aws-cdk/aws-ssm';
import * as ec2 from '@aws-cdk/aws-ec2';

const vpcId = ssm.StringParameter.valueFromLookup(this, "/param/vpcId");
const vpc = ec2.Vpc.fromLookup(this, "vpc", {
  vpcId: vpcId
});

This is because ec2.Vpc.fromLookup() does not check the format of vpcId input parameter, so it won’t cause the construction phase to fail.

However, this method demands your input vpcId to be a concrete string and not a token, so the statement vpcId: cdk.Lazy.string({produce: () => vpcId }) will result in the error All arguments to Vpc.fromLookup() must be concrete (no Tokens). You never know how the callee will deal with the input parameter.

You can store any kind of strings, for different purposes in a SSM parameter, so it’s hard to demand a universal fix for every use cases from inside the valueFromLookup() method, unless (the ideal fix in my mind) the CDK team does a big re-design and make it fetch the parameters at construction time.

Seems to me at the moment the best way is to understand your use case and have a look at the source code of the method you’re gonna pass your parameter to, and decide what approach you need to pre-process your parameter.

Anyone interested can have a look at my complete analysis.

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