Skip to content
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

Set NoEcho on response to keep return Secret hidden #6

Closed
spockNinja opened this issue Feb 20, 2018 · 9 comments
Closed

Set NoEcho on response to keep return Secret hidden #6

spockNinja opened this issue Feb 20, 2018 · 9 comments

Comments

@spockNinja
Copy link

Thanks for this and the cfn-resource-provider. It goes a long way to make my job easier!

If the ReturnSecret option is used, it appears that the value will still show up in CloudFormation.

According to these AWS Docs, we should be able to set the NoEcho parameter to keep the secret a secret.

This will be important for me, as the only interface my service engineers have with AWS is CloudFormation. So they will be using the CloudFormation console and seeing templates.

I may have missed something, but I couldn't find a reference to "NoEcho" anywhere in this repo.

I would be happy to open up a PR if it would be welcome.

@spockNinja
Copy link
Author

For now, I have a copy of your SecretProvider, and have added the following:


    def set_request(self, *args, **kwargs):
        super().set_request(*args, **kwargs)

        # Don't ever show secrets in the CloudFormation console or CLI
        self.response['NoEcho'] = True

@mvanholsteijn
Copy link
Member

Ooh nice!

I will add the option 'NoEcho' as a request parameter to the secret providers. A pull request is welcomed..

Cheers,

Mark

@mvanholsteijn
Copy link
Member

@spockNinja Would it be sufficient to make NoEcho an option that you can set on the resource?

@spockNinja
Copy link
Author

Yeah, I think it could behave like the PhysicalResourceId, where if it is set, it gets added to the request. I suppose that would be a change in cfn-resource-provider instead.

Basically, the same thing as https://github.com/binxio/cfn-resource-provider/blob/master/cfn_resource_provider/resource_provider.py#L126 -- if you set self.no_echo = True, it'll set NoEcho in the response.

How does that sound?

@mvanholsteijn
Copy link
Member

mvanholsteijn commented Feb 23, 2018

@spockNinja, I implemented the NoEcho but unfortunately AWS CloudFormation does nothing with the NoEcho field in the response.

Did you have a working version? If it does not do anything I will revert back the changes.

ReturnSecret == False actually does have the desired effect of not exposing the secrets..

See https://github.com/binxio/cfn-secret-provider/tree/no-echo

@spockNinja
Copy link
Author

I believe it is only used in a few places, so it might be hard to find where it's working.

From the AWS Docs:

If the name-value pairs contain sensitive information, you should use the NoEcho field to mask the output of the custom resource. Otherwise, the values are visible through APIs that surface property values (such as DescribeStackEvents).

The "ReturnSecret" keeps the secret from coming back to the template at all, which won't work for me since I need to pass the secret to other templates' NoEcho parameters.

@spockNinja
Copy link
Author

I took a look at that branch, and I couldn't find where the self.no_echo property was actually passing on to self.response['NoEcho']. Do you also have a branch in the resource-provider that's handling that?

@mvanholsteijn
Copy link
Member

Hi, it is in de code. I added the no_echo as a property to the cfn_resource_provider. For instance -> https://github.com/binxio/cfn-secret-provider/blob/no-echo/src/cfn_secret_provider.py#L109

I can see the NoEcho actually working in the describe-stack-events. I thought it would also disable the ability the put the secret values in an Output parameter, but that is not the case.

@mvanholsteijn
Copy link
Member

NoEcho is set by default on Custom::Secret and Custom::AccessKey. available in release v0.10.1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants