Extend support for handling sensitive/secret property data for DSC Resources

[michaeltlombardi]

As an engineer developing and maintaining DSC Resources, I want to have a standardized/supported model for handling sensitive data types in addition to PSCredentials.

Context

Sometimes, a string, array of bytes, or hash table need to be handled as sensitive data and ideally stay encrypted in memory, only decrypted at the moment they are needed to be passed to something which does not expect the encrypted object.

While DSC already handles passwords (covered by PSCredentials) and tokens (covered by SecureStrings), sometimes the data itself is sensitive but not secret and users want to avoid writing the information to logging accidentally. Having a general model for redacting sensitive data would also make the expected surface of a DSC Resource more explicit to integrating tools and users alike.

Proposal

I propose that, initially, DSC support marking a property as sensitive or secret and automatically redact the value from any logging (while still returning the object for comparison if needed).

This could be implemented on the DSC Resource side by extending the parameters of the DscProperty attribute to include Sensitive or Secret and in the handling for Invoke-DscResource to redact properties with this attribute from being logged to the verbose/error streams.

In the future, it may be even more useful to be able to ensure these values are encrypted and must be explicitly decrypted for direct access (allowing comparison in the course of processing but returning the encrypted object to the pipeline when emitted).