mirror of https://github.com/dapr/docs.git
Re-organizing secret store related articles
This commit is contained in:
Ori Zohar
parent
86888ba875
commit
47f23f2f58
|
|
@ -6,42 +6,23 @@ weight: 2000
|
|||
description: "Use the secret store building block to securely retrieve a secret"
|
||||
---
|
||||
|
||||
It's common for applications to store sensitive information such as connection strings, keys and tokens that are used to authenticate with databases, services and external systems in secrets by using a dedicated secret store.
|
||||
This article provides guidance on using Dapr's secrets API in your code to leverage the [secrets store building block]({{<ref secrets-overview>}}). The secrets API allows you to easily retrieve secrets in your application code from a configured secret store.
|
||||
|
||||
Usually this involves setting up a secret store such as Azure Key Vault, Hashicorp Vault and others and storing the application level secrets there. To access these secret stores, the application needs to import the secret store SDK, and use it to access the secrets.
|
||||
## Prerequisites
|
||||
|
||||
This usually involves writing a fair amount of boilerplate code that is not related to the actual business domain of the app, and this becomes an even greater challenge in multi-cloud scenarios: if an app needs to deploy to two different environments and use two different secret stores, the amount of boilerplate code gets doubled, and the effort increases.
|
||||
|
||||
In addition, not all secret stores have native SDKs for all programming languages.
|
||||
|
||||
To make it easier for developers everywhere to consume application secrets, Dapr has a dedicated secrets building block API that allows developers to get secrets from a secret store.
|
||||
|
||||
## Setting up a secret store component
|
||||
|
||||
The first step involves setting up a secret store, either in the cloud or in the hosting environment such as a cluster. This is done by using the relevant instructions from the cloud provider or secret store implementation.
|
||||
|
||||
The second step is to configure the secret store with Dapr.
|
||||
|
||||
To deploy in Kubernetes, save the file above to `aws_secret_manager.yaml` and then run:
|
||||
|
||||
```bash
|
||||
kubectl apply -f aws_secret_manager.yaml
|
||||
```
|
||||
|
||||
To run locally, create a `components` dir containing the YAML file and provide the path to the `dapr run` command with the flag `--components-path`.
|
||||
|
||||
Watch this [video](https://www.youtube.com/watch?v=OtbYCBt9C34&feature=youtu.be&t=1818) for an example on how to use the secrets API. Or watch this [video](https://www.youtube.com/watch?v=8W-iBDNvCUM&feature=youtu.be&t=1765) for an example on how to component scopes with secret components and the secrets API.
|
||||
Before retrieving secrets in your application's code, you must have a secret store component configured. See guidance on [how to configure a secret store]({{<ref secret-stores-overview>}}) and review [supported secret stores]({{< ref supported-secret-stores >}}) to see specific details required for different secret store solutions.
|
||||
|
||||
## Calling the secrets API
|
||||
|
||||
Now that the secret store is set up, you can call Dapr to get the secrets for a given key for a specific secret store.
|
||||
Once you have a secret store set up, you can call Dapr to get the secrets for a given key for a specific secret store.
|
||||
|
||||
For a full API reference, go [here](https://github.com/dapr/docs/blob/master/reference/api/secrets_api.md).
|
||||
|
||||
Here are a few examples in different programming languages:
|
||||
|
||||
### Go
|
||||
{{< tabs "Go" "Javascript" "Python" "Rust" "C#" >}}
|
||||
|
||||
{{% codetab %}}
|
||||
```Go
|
||||
import (
|
||||
"fmt"
|
||||
|
|
@ -61,7 +42,10 @@ func main() {
|
|||
fmt.Println(string(body))
|
||||
}
|
||||
```
|
||||
### Javascript
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```javascript
|
||||
require('isomorphic-fetch');
|
||||
|
|
@ -78,7 +62,9 @@ fetch(`${secretsUrl}/kubernetes/my-secret`)
|
|||
});
|
||||
```
|
||||
|
||||
### Python
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```python
|
||||
import requests as req
|
||||
|
|
@ -87,7 +73,10 @@ resp = req.get("http://localhost:3500/v1.0/secrets/kubernetes/my-secret")
|
|||
print(resp.text)
|
||||
```
|
||||
|
||||
### Rust
|
||||
{{% /codetab %}}
|
||||
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```rust
|
||||
#![deny(warnings)]
|
||||
|
|
@ -105,7 +94,9 @@ async fn main() -> Result<(), reqwest::Error> {
|
|||
}
|
||||
```
|
||||
|
||||
### C#
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```csharp
|
||||
var client = new HttpClient();
|
||||
|
|
@ -115,3 +106,6 @@ response.EnsureSuccessStatusCode();
|
|||
string secret = await response.Content.ReadAsStringAsync();
|
||||
Console.WriteLine(secret);
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
|
@ -6,25 +6,20 @@ weight: 1000
|
|||
description: "Overview of Dapr secrets management building block"
|
||||
---
|
||||
|
||||
Almost all non-trivial applications need to _securely_ store secret data like API keys, database passwords, and more. By nature, these secrets should not be checked into the version control system, but they also need to be accessible to code running in production. This is generally a hard problem, but it's critical to get it right. Otherwise, critical production systems can be compromised.
|
||||
It's common for applications to store sensitive information such as connection strings, keys and tokens that are used to authenticate with databases, services and external systems in secrets by using a dedicated secret store.
|
||||
|
||||
Dapr's solution to this problem is the secrets API and secrets stores.
|
||||
Usually this involves setting up a secret store such as Azure Key Vault, Hashicorp Vault and others and storing the application level secrets there. To access these secret stores, the application needs to import the secret store SDK, and use it to access the secrets. This may require a fair amount of boilerplate code that is not related to the actual business domain of the app, and so becomes an even greater challenge in multi-cloud scenarios where different vendor specific secret stores may be used.
|
||||
|
||||
Here's how it works:
|
||||
To make it easier for developers everywhere to consume application secrets, Dapr has a dedicated secrets building block API that allows developers to get secrets from a secret store.
|
||||
|
||||
- Dapr is set up to use a **secret store** - a place to securely store secret data
|
||||
- Application code uses the standard Dapr secrets API to retrieve secrets.
|
||||
Using Dapr's secret store building block typically involves the following:
|
||||
1. Setting up a component for a specific secret store solution.
|
||||
1. Retrieving secrets using the Dapr secrets API in the application code.
|
||||
1. Optionally, referencing secrets in Dapr component files.
|
||||
|
||||
Some examples for secret stores include `Kubernetes`, `Hashicorp Vault`, `Azure KeyVault`. See [secret stores]({{< ref supported-secret-stores >}}) for the list of supported stores.
|
||||
|
||||
See [Setup secret stores]({{< ref howto-secrets.md >}}) for a HowTo guide for setting up and using secret stores.
|
||||
|
||||
## Referencing secret stores in Dapr components
|
||||
|
||||
Instead of including credentials directly within a Dapr component file, you can place the credentials within a Dapr supported secret store and reference the secret within the Dapr component. This is preferred approach and is a recommended best practice especially in production environments.
|
||||
|
||||
For more information read [Referencing Secret Stores in Components]({{< ref component-secrets.md >}})
|
||||
## Setting up a secret store
|
||||
|
||||
See [Setup secret stores]({{< ref howto-secrets.md >}}) for guidance on how to setup a secret store with Dapr.
|
||||
|
||||
## Using secrets in your application
|
||||
|
||||
|
|
@ -47,9 +42,16 @@ Notice that in all of the examples above the application code did not have to ch
|
|||
|
||||
See [Access Application Secrets using the Secrets API]({{< ref howto-secrets.md >}}) for a How To guide to use secrets in your application.
|
||||
|
||||
|
||||
For detailed API information read [Secrets API]({{< ref secrets_api.md >}}).
|
||||
|
||||
|
||||
## Referencing secret stores in Dapr components
|
||||
|
||||
When configuring Dapr components such as state stores it is often required to include credentials in components files. Instead of doing that, you can place the credentials within a Dapr supported secret store and reference the secret within the Dapr component. This is preferred approach and is a recommended best practice especially in production environments.
|
||||
|
||||
For more information read [referencing secret stores in components]({{< ref component-secrets.md >}})
|
||||
|
||||
## Limiting access to secrets
|
||||
|
||||
To provide more granular control on access to secrets, Dapr provides the ability to define scopes and restricting access permissions. Learn more about [using secret scoping]({{<ref secrets-scopes>}})
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -7,11 +7,11 @@ weight: 10000
|
|||
type: docs
|
||||
---
|
||||
|
||||
Dapr integrates with secret stores to provide apps and other components with secure store and access to secrets such as access keys and passwords.. Each secret store component has a name and this name is used when accessing a secret.
|
||||
Dapr integrates with secret stores to provide apps and other components with secure store and access to secrets such as access keys and passwords. Each secret store component has a name and this name is used when accessing a secret.
|
||||
|
||||
Secret stores are extensible and can be found in the [components-contrib repo](https://github.com/dapr/components-contrib).
|
||||
As with other building block components, secret store components are extensible and can be found in the [components-contrib repo](https://github.com/dapr/components-contrib).
|
||||
|
||||
A secret store in Dapr is described using a `Component` file:
|
||||
A secret store in Dapr is described using a `Component` file with the following fields:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
|
|
@ -32,7 +32,47 @@ spec:
|
|||
|
||||
The type of secret store is determined by the `type` field, and things like connection strings and other metadata are put in the `.metadata` section.
|
||||
|
||||
Visit [this guide]({{< ref "howto-secrets.md#setting-up-a-secret-store-component" >}}) for instructions on configuring a secret store component.
|
||||
Different [supported secret stores]({{< ref supported-secret-stores >}}) will have different specific fields that would need to be configured. For example, when configuring a secret store which uses AWS Secrets Manager the file would look like this:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: awssecretmanager
|
||||
namespace: default
|
||||
spec:
|
||||
type: secretstores.aws.secretmanager
|
||||
version: v1
|
||||
metadata:
|
||||
- name: region
|
||||
value: "[aws_region]"
|
||||
- name: accessKey
|
||||
value: "[aws_access_key]"
|
||||
- name: secretKey
|
||||
value: "[aws_secret_key]"
|
||||
- name: sessionToken
|
||||
value: "[aws_session_token]"
|
||||
```
|
||||
|
||||
Once you have created the component's YAML file, follow these instructions to apply it based on your hosting environment:
|
||||
|
||||
|
||||
{{< tabs "Self-Hosted" "Kubernetes" >}}
|
||||
|
||||
{{% codetab %}}
|
||||
To run locally, create a `components` dir containing the YAML file and provide the path to the `dapr run` command with the flag `--components-path`.
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
To deploy in Kubernetes, assuming your component file is named `secret-store.yaml`, run:
|
||||
|
||||
```bash
|
||||
kubectl apply -f secret-store.yaml
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
## Related links
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue