-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SSM Module: String Parameter assumes parameter will have a '/' at the front of the string. #2777
Comments
PR #1726, which introduced this error, modified some code in arn.ts In particular, if you look at the changes the first commit made to lines 29-31 of that file, originally we had
but the change made it so In PR #1726, they say "the SSM parameter name ( |
Looking through the unit tests further in test.parameter.ts, it actually seems like we expect no seperator between For instance, in the linked test they expect the correct ARN to be |
I just made a parameter without "/": I also supposed it was required but actually is not. If it's ok for everyone, maybe I can jump on this - maybe as suggested by @rileylyman |
@made2591 - if you're willing to try to fix this, it sounds like the current understanding of the issue is sane. There is one trick however: if you create a parameter without a leading So I guess the fix probably should be to completely ban leading slashes (beware - there could be unresolved tokens!) and just compose the ARN with the |
Hi @RomainMuller and thank you for the suggestion! I don't know if I got it right: I supposed to just force the parameter name to start without
and then change the value of the Also: is that possible that |
Just a note, the auto generated parameter_name doesn't begin with '/' either.
|
edit: removed unnecessary grumbling :) @RomainMuller should not have modified the general function arnForParameterName(scope: IConstruct, parameterName: string): string {
return Stack.of(scope).formatArn({
service: 'ssm',
resource: 'parameter',
sep: '/',
resourceName: parameterName.replace(/^\//,''),
});
} If the parameter name is supposed to have a slash in front of it, normalise that to have a slash in front of it. And yes @rileylyman is correct there is an incorrectly passing test for this, just to compound the issue: aws-cdk/packages/@aws-cdk/aws-ssm/test/test.parameter.ts Lines 116 to 127 in 6f22446
|
I am happy to contribute the fix to this, if no-one else is doing one right now. First I need to understand, why is the parameter name assumed to (or supposed to) have a leading slash? |
Describe the bug
When creating a string parameter in SSM parameter store, CDK makes the assumption that a '/' will be placed in front of the parameter. This is not a requirement of SSM parameter store; hence, when creating a parameter without a '/' in the front of the string and granting access from another resource to this parameter, cdk will provide an ARN that is invalid. This isn't immediately noticable as the IAM policy will still get created, but one would have to dig to figure out why the requested access is not working as expected.
See here:
https://github.com/awslabs/aws-cdk/blob/master/packages/%40aws-cdk/aws-ssm/lib/parameter.ts#L125
To Reproduce
cdk deploy
app.py:
IAM policy that is created:
Expected behavior
IAM Policy :
Version:
0.33.0 (build 50d71bf)
The text was updated successfully, but these errors were encountered: