Add 'secret' to the Chef DSL

This is a proposed addition of a 'secret' helper to the Chef DSL, where
a 'secret' is private data stored within a secrets management service.

Usage would look like the following working example:

```
  # The included ':example' secrets provider
  # requires that it be configured with a hash of secrets
  my_config = { "secret1" => "a hidden door" }

  file "/tmp/the-secret" do
    content secret(name: "secret1", service: :example, config: my_config)
  end

```
Initial constraints:

* minimal-to-no abstraction over how services handle inputs, outputs,
and errors. Each of these services has well-defined interfaces already,
and there is much more different than the same across services.  We may
revisit this as we begin implementing a range of specific secrets
fetchers.
* no caching of results.
* avoid 'provider' nomenclature. That's already well-used within Chef Infra.
  That's why a secrets 'service' has a SecretFetcher implementation and not a SecretProvider.

Security Concerns:

Because we don't provide an abstraction around the returned secret
(there is not a specific single type of returned data we can rely on),
if a secrets fetcher does not take steps to hide its own data from
incidental output (logs, debug output, exceptions) then there is a risk
of exposing this data to people and systems that have the ability to
view the output.

Signed-off-by: Marc A. Paradise <marc.paradise@gmail.com>

1 files changed, 1 insertions, 0 deletions

diff --git a/cspell.json b/cspell.json
index 614bb8f06d..751a40e597 100644
--- a/cspell.json
+++ b/cspell.json
@@ -1434,6 +1434,7 @@
     "secoption",
     "secopts",
     "secp",
+    "secretkey",
     "securerandom",
     "SECURITYPOLICY",
     "secvalue",