binxio/cfn-secret-provider

Changing the parameter path of the Custom::AccessKey recreates the access key

Closed this issue · 9 comments

We have a cloudformation template that creates a very large number of users with access and secret keys that are stored in SSM parameter store using this custom resource.

I need to change the path where the items are stored.

Looking at the code it seems changing the path will cause a new key to be created, will this remove the old keys? We cannot afford for the existing keys to be invalidated.

Additionally, during testing after modifying the key path I received this error in the logs:

An error occurred (ParameterNotFound) when calling the GetParameter operation:

So my question is, how can I modify the Parameter Path within the existing cloudformation stack without removing the existing access or secret keys?

Hi @reidca, when you change the parameter name and you have specified (RefreshOnUpdate == false), the value will be copied to the parameter name. CloudFormation will Delete the old parameter because the physical resource id will have changed.

If the secrets are really sensitive, I would recommend copying your secrets to another AWS account, before the rename. You could use the aws-ssm-copy utility for this purpose.. -> https://pypi.org/project/aws-ssm-copy/

Please open an issue with a reproduction of the ParameterNotFound error, if it is reproducible.

I have had a look but cannot see the RefreshOnUpdate property in the Custom:AccessKey resource.

To be clear, we are creating a number of AWS::IAM::User resources with corresponding Custom:AccessKey resources that save the AccessKey and SecretKey to the parameter store.

The parameter path that was used when the stack was first launched was incorrect and therefore I want to change it but I do not want the existing IAM users access key or secret key to be replaced, rather I want the existing values to be copied into a new SSM parameter with the correct path.

Is this possible to do?

Thanks

Ah I see now. I was looking at the secret, you are talking about the AccessKey.

Yes you are right. The AccessKey does re-create and does not have a RefreshOnUpdate property. I would need to spent some time on fixing this.

Thank you for replying. I am in a quandy with this as I have made changes to the parameter name and the CloudFormation stack has now got itself into a mess due to this.

I did try to make changes to the code myself to resolve the issue however it appears you cannot update the service token on a customer resource so I need you to make the changes otherwise I am stuck!

@reidca,

I have upgraded the cfn-secret-provider to version 1.0.1 which fully supports the parameter path rename without changing the access key. In the update process, the key is copied to the new parameter path and the old parameters are deleted from the store.

This problem is caused by the fact that in my design I return the access key as physical resource id, instead of the Arn of the parameter in which the access key is stored. If I would have done that, this problem would not have occurred. Changing that now, will break compatibility and would not solve your immediate issue.

I have added an integration test to the source code to validate that it now has the desired behaviour. I trust you have made a copy of the relevant keys to a safe spot using the
https://pypi.org/project/aws-ssm-copy/ utility. My apologies for any inconvenience caused.

Cheers,

Mark

Many thanks! Much appreciate you doing this so quickly. Has it been deployed to your S3 bucket now?

I have upgraded the cfn-secret-provider to version 1.0.1 which fully supports the parameter path rename with changing the access key

Just to confirm, you mean WITHOUT changing the access key?

I need the keys to remain as they are, just the location to change.

Is it just a case of modifying the Parameter path or do I need to add the RefreshOnUpdate parameter to the AccessKey resource as well?

Confirm: Change the ParameterPath only to move the access key to another path. The RefreshOnUpdate is not support nor involved.

If you change Version or User it will create a new key.

BTW you may also want to address the requirement that the key is not allowed to change. It is best practice to recycle access keys frequently, so your system should be able to deal with a modified access key and secret. Given the fact that the keys are obtainable from the parameter store, it should not be a big issue.