Commit graph

2 commits

Author SHA1 Message Date
Matt Ellis af2a2d0f42 Correctly flow secretness across structured values
For providers which do not natively support secrets (which is all of
them today), we annotate output values coming back from the provider
if there is a coresponding secret input in the inputs we passed in.

This logic was not tearing into rich objects, so if you passed a
secret as a member of an array or object into a resource provider, we
would lose the secretness on the way back.

Because of the interaction with Check (where we call Check and then
take the values returned by the provider as inputs for all calls to
Diff/Update), this would apply not only to the Output values of a
resource but also the Inputs (because the secret metadata would not
flow from the inputs of check to the outputs).

This change augments our logic which transfers secrets metadata from
one property map to another to handle these additional cases.
2019-05-15 09:32:25 -07:00
Matt Ellis fb1ebd0e06 Add an End to End test of secrets
This test ensures that our secrets support works by deploying
resources with a mix of secret and plantext inputs and then checks the
deployment file to ensure that everything is marked as a secret.
2019-05-10 17:07:52 -07:00