| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Signed-off-by: Marc A. Paradise <marc.paradise@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Vault secrets are stored as key-value pairs, so the return value
from a secret lookup is always a Hash.
Example:
```
file "/home/user/test1" do
content secret(name: "secret/example",
service: :hashi_vault,
config: {
vault_addr: "vault.example.com",
role_name: "example-role"
})[:answer]
end
```
As shown above, we are expecting a hash from Vault, and are populating the file
content based on the value of `:answer` in that hash.
Limitations:
* This iteration only supports instance authentication via a Vault
role connected to an IAM profile.
* This iteration does not support versioned secrets
Signed-off-by: Marc A. Paradise <marc.paradise@gmail.com>
|
| |
|
|
|
|
|
| |
This will allow them to use node attributes for configuration, such
as ohai data for determining region.
Signed-off-by: Marc A. Paradise <marc.paradise@gmail.com>
|
| |
|
|
|
|
|
|
|
|
| |
Usage in a recipe looks like this:
value = secret(name: "test1", version: "v1",
service: :azure_key_vault,
config: { vault: "myvault" } )
Signed-off-by: Marc A. Paradise <marc.paradise@gmail.com>
|
| |
|
|
| |
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In a recipe, usage will look like the following:
value = secret(name: "test1", service: :aws_secrets_manager, config: { region: "us-west-1" })
log "My secret is #{value.secret_string}"
Note the use of `secret_string` to determine the secret value. The
returned object here is Aws::Types::GetSecretValueResponse from the AWS SDK.
This beta implementation supports ec2/imds instance profile
authentication but also checks standard locations for credentials
configuration -- see documentation [1] for a description of default credentials search behavior.
[1] https://docs.aws.amazon.com/sdk-for-ruby/v3/api/Aws/SecretsManager/Client.html#initialize-instance_method
Signed-off-by: Marc A. Paradise <marc.paradise@gmail.com>
|
|
|
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>
|
