Support encrypted secrets

[SteveL-MSFT]

Summary of the new feature / enhancement

There are scenarios where a resource might export secrets. Using SecureString and SecureObject currently is insufficient as the contents are in clear text and the only contract is that the contents are redacted when traced.

Proposed technical implementation details (optional)

We can adopt CMS (Cryptographic Message Syntax) using public key encryption. This requires the user to provide a public key used for encryption. In this scenario, a resource that exports secrets would export it as a SecureString or SecureObject and when DSC receives it, would encrypt it using the given public key. When this config is applied, the user needs to provide the private key to decrypt the secrets which DSC would then pass to the appropriate resources. In this case, resources don't handle encryption/decryption directly and only DSC itself handles it.

[michaeltlombardi]

I think we should also document/encourage resource authors not to return secrets from resources - I've been documenting this as a primary reason to define the writeOnly keyword for secret properties as true from a resource API perspective.

I can't think of a good reason to return the actual value for a secret passed to the resource except maybe for resources that focus on managing secrets themselves.

Definitely agree that encrypting any values marked as secret is the correct way forward, regardless of guidance on resource authoring.

[SteveL-MSFT]

@michaeltlombardi we might only say we support this for export