Closed scott-phillips-ah closed 3 years ago
Hi @scott-phillips-ah
Thank you for your pull request.
I have two observations:
Thanks.
Addressed all feedback, thanks for the quick review!
Hi @scott-phillips-ah, sorry I disappeared.
I'm not totally happy with the name of DefinedSecretArns
. Can you suggest something else? I was more inclined towards AcceptedSecretArns
but I welcome any other idea.
Also, would you be so kind to update the README
file with this addition?
Hey, no worries. Good call on that. I changed it to what you specified, the alternative I'd use is RequiredSecretArns
(which would indicate that the following secrets are required for the application to operate).
Would the application fail to start if a secret with one of the specified Arns were to be missing? If not, i don't think Required
describes the behavior we are introducing.
In our case, it would. But I wouldn't say that is true in every case. We can leave it as it is.
Feel free to merge whenever.
Any updates on this? I'd be happy to test or do whatever is needed to get this merged. I'm very excited for the feature ^_^
Hi @killianhale-earnin, could you take care of updating the readme? Also if you could try the feature in the wild, using one of the nightly builds, it would be great.
@killianhale-earnin @Kralizek the README has been updated per your request.
@scott-phillips-ah @killianhale-earnin
I'll release a new version once #47 is merged in :)
Searching for keys makes the secrets manager configuration require the ListSecrets permission, which some organizations don't like to grant to services. This PR allows users to define a list of secret ARNs to load, and it only loads those. Filtering still works, but I don't see a good reason to use a filter with a defined secrets list.
Test created and passed. Not sure the best way to develop an example