Feature request: Setting Parameters and Secrets

[stephenbawks]

Use case

The parameters module currently only allows users to read secrets and parameters from the Secret and Parameter Store. I would like to extend the parameters module to allow users to write secrets and parameters back to the stores. This would make it easier for users to update values that are stored in the Secret Store, without having to create their own boto3 client.

Solution/User Experience

The parameters module provides a convenient and easy-to-use way to read values from the Secret and Parameter Store. It eliminates the need to set up your own session, making it a more streamlined and efficient process. I would like to replicate these features by adding the ability to write values back to the stores.

Alternative solutions

No response

Acknowledgment

• This feature request meets Powertools for AWS Lambda (Python) Tenets
• Should this be considered in other Powertools for AWS Lambda languages? i.e. Java, TypeScript, and .NET

[heitorlessa]

hey @stephenbawks thanks for another nice idea! Got any ideas on what the experience could look like?

Like this?

provider = SSMProvider()
provider.set(param_or_secret_name, value, **sdk_options)

SSM has quite a few options so I'd start by defining what are the most common options so we can have defaults or infer to keep it simple: https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/ssm/client/put_parameter.html

[stephenbawks]

Yah I started on this actually this morning. Might commit some early stuff and get some initial feedback since the parameter code is quite complex like you are saying with so many options.
@heitorlessa

[leandrodamascena]

Hei @heitorlessa and @stephenbawks! Is this issue related to the PR #2858?

I really like this idea because we can make it easy to set and update secrets and parameters. Should we include AppConfig also?

Heitor's suggestion:

hey @stephenbawks thanks for another nice idea! Got any ideas on what the experience could look like?

Like this?

provider = SSMProvider()
provider.set(param_or_secret_name, value, **sdk_options)

I like this experience, but we need to add high-level functions also, right?

So, lets see if we can work to get it merged soon.

Thanks

[thiagoamaciel]

I'd love this feature also. I have a use case that I need to update a token every hour. Had to do this using boto3, but the user exp should improve a lot calling a function like Heitor mentioned.

Willing to help in case you guys need it.

[leandrodamascena]

Hey everyone! I'm writing an RFC to define how we implement this. At first glance, it looks like we only need one method to define a new parameter/secret, but there are things to discuss before implementing this.

• What is the best developer experience in this case? Create a single set() method for create and update or create() and update() methods?
• If an parameter/secret already exists, we replace the value? We will add a new Optinal parameter to force overwrite?
• Do we need to add support to create profiles/config in AppConfig?
• If a customer creates/updates a new parameter/secret, we cache that value the same way it does when using get()?

Once I have the RFC created I will update this issue with the link.

Thank you.

[stephenbawks]

@leandrodamascena
Yeah, I think the one thing worth calling out on this is that when using put_secret_value [link] we probably would want an optional value to specify the version. It defaults to moving it to AWSCURRENT in boto3. Probably worth having the ability to create a new version and set it to AWSPENDING or some other tag.

I think create() makes sense for creating a new one.

set() or update() maybe close to the same thing with an optional flag I think for versions.

update(secret_name="mySuperSecret", secret_value="toomanysecrets")

update(secret_name="mySuperSecret", secret_value="toomanysecrets", stage="development")

get() would be nice to have with the optional way to get different versions of a secret.

I think being able to cache that value would be great but may have to think through if they are updating a secret with a different version.

I have been thinking about how this might eventually be used for versioning around being able to do "canary" or even cutovers to new passwords/secrets. But that is probably future work....

[stephenbawks]

Adding an RFC
#3040

[rubenfonseca]

@stephenbawks thank you so much for your patience. Now that we are back from re:invent, one of us will look and review the RFC you've opened.

[heitorlessa]

Updated to reflect we're working on release or get as close to prod ready in the next two weeks.

[heitorlessa]

Last update before release... all updates will be done in the PR from here on: #2858 (comment)

It's doable to get this ready for release in the next two weeks. We'll share otherwise. I'm gonna close this feature request and keep the RFC open only, as nearly all context is there.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

This issue is now closed. Please be mindful that future comments are hard for our team to see.

If you need more assistance, please either tag a team member or open a new issue that references this one.

If you wish to keep having a conversation with other community members under this issue feel free to do so.