SSM: resolve full parameter ARNs in get_parameters (#9396) - #10120
Open
balramthewarrior wants to merge 2 commits into
Open
SSM: resolve full parameter ARNs in get_parameters (#9396)#10120balramthewarrior wants to merge 2 commits into
balramthewarrior wants to merge 2 commits into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Partially addresses #9396.
Problem
get_parameteraccepts a full parameter ARN — that was fixed in #7748.get_parameterswas not updated to match, so reading parameters by ARN (as you do for a parameter shared from another account via RAM) silently returns nothing:The cause is the guard in
get_parameters:For an ARN,
name.split(":")[0]is"arn", which is never a stored parameter name, so the entry is skipped beforeget_parameter(which would have handled the ARN) is ever called.Change
Extract the prefix-stripping already present in
get_parameterinto_strip_parameter_arn, and use it in theget_parametersguard as well.The caller's original string stays the dict key, so the response layer still reports
InvalidParametersusing exactly what was requested rather than a stripped name — there's a test for that.Namein the returned parameter is the bare name, matching the existingget_parameter-by-ARN behaviour.Tests
test_get_parameters_by_arn, parametrizedby-name/by-arn, mirroring the existing parametrizedtest_get_parameterfrom SSM.Client.get_parameter() by ARN instead of Name fails with ParameterNotFound #7748.test_get_parameters_by_arn_reports_unknown_arn_as_invalid— an unresolvable ARN comes back inInvalidParametersverbatim.Against unpatched master these give 2 failed / 1 passed; the
by-namecase passes either way. Fulltests/test_ssm/suite: 181 passed.mypyandruff checkclean.Not covered by this PR
Two other things reported in #9396:
create_resource_sharestill rejects SSM parameters —SHAREABLE_RESOURCESinmoto/ram/models.pyhas no"parameter"entry. Adding the string is trivial, but AWS only permits sharing Advanced-tier parameters, and RAM has no visibility into SSM state to enforce that. Happy to do it if you have a preference on how strict it should be.Tieronput_parameterappears to be a non-issue —Tieris stored and returned inresponse_objecton current master.