mirror of https://github.com/dapr/docs.git
Weekly merge from default docs v0.11
This commit is contained in:
Ori Zohar
commit
0ca958144b
|
|
@ -50,7 +50,7 @@ The Dapr runtime SDKs have language specific actor frameworks. The .NET SDK for
|
|||
|
||||
### Does Dapr have any SDKs if I want to work with a particular programming language or framework?
|
||||
|
||||
To make using Dapr more natural for different languages, it includes language specific SDKs for Go, Java, JavaScript, .NET, Python, RUST and C++.
|
||||
To make using Dapr more natural for different languages, it includes language specific SDKs for Go, Java, JavaScript, .NET, Python, Rust and C++.
|
||||
|
||||
These SDKs expose the functionality in the Dapr building blocks, such as saving state, publishing an event or creating an actor, through a typed, language API rather than calling the http/gRPC API. This enables you to write a combination of stateless and stateful functions and actors all in the language of their choice. And because these SDKs share the Dapr runtime, you get cross-language actor and functions support.
|
||||
|
||||
|
|
|
|||
|
|
@ -49,9 +49,9 @@ Your handler implementation can include any inbound logic, outbound logic, or bo
|
|||
func GetHandler(metadata Metadata) fasthttp.RequestHandler {
|
||||
return func(h fasthttp.RequestHandler) fasthttp.RequestHandler {
|
||||
return func(ctx *fasthttp.RequestCtx) {
|
||||
//inboud logic
|
||||
h(ctx) //call the downstream handler
|
||||
//outbound logic
|
||||
// inboud logic
|
||||
h(ctx) // call the downstream handler
|
||||
// outbound logic
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ As seen above, you invoked the `/binding` endpoint with the name of the binding
|
|||
The payload goes inside the mandatory `data` field, and can be any JSON serializable value.
|
||||
|
||||
You'll also notice that there's an `operation` field that tells the binding what you need it to do.
|
||||
You can check [here]({{< ref bindings >}}) which operations are supported for every output binding.
|
||||
You can check [here]({{< ref supported-bindings >}}) which operations are supported for every output binding.
|
||||
|
||||
|
||||
## References
|
||||
|
|
|
|||
|
|
@ -6,42 +6,66 @@ 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.
|
||||
## Set up a secret store
|
||||
|
||||
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.
|
||||
Before retrieving secrets in your application's code, you must have a secret store component configured. For the purposes of this guide, as an example you will configure a local secret store which uses a local JSON file to store secrets.
|
||||
|
||||
In addition, not all secret stores have native SDKs for all programming languages.
|
||||
>Note: The component used in this example is not secured and is not recommended for production deployments. You can find other alternatives [here]({{<ref supported-secret-stores >}}).
|
||||
|
||||
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.
|
||||
Create a file named `secrets.json` with the following contents:
|
||||
|
||||
## 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
|
||||
```json
|
||||
{
|
||||
"my-secret" : "I'm Batman"
|
||||
}
|
||||
```
|
||||
|
||||
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`.
|
||||
Create a directory for your components file named `components` and inside it create a file named `localSecretStore.yaml` with the following contents:
|
||||
|
||||
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.
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: my-secrets-store
|
||||
namespace: default
|
||||
spec:
|
||||
type: secretstores.local.file
|
||||
version: v1
|
||||
metadata:
|
||||
- name: secretsFile
|
||||
value: <PATH TO SECRETS FILE>/secrets.json
|
||||
- name: nestedSeparator
|
||||
value: ":"
|
||||
```
|
||||
|
||||
## Calling the secrets API
|
||||
Make sure to replace `<PATH TO SECRETS FILE>` with the path to the JSON file you just created.
|
||||
|
||||
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.
|
||||
To configure a different kind of secret store see the 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.
|
||||
## Get a secret
|
||||
|
||||
Now run the Dapr sidecar (with no application)
|
||||
|
||||
```bash
|
||||
dapr run --app-id my-app --port 3500 --components-path ./components
|
||||
```
|
||||
|
||||
And now you can get the secret by calling the Dapr sidecar using the secrets API:
|
||||
|
||||
```bash
|
||||
curl http://localhost:3500/v1.0/secrets/my-secrets-store/my-secret
|
||||
```
|
||||
|
||||
For a full API reference, go [here]({{< ref secrets_api.md >}}).
|
||||
|
||||
Here are a few examples in different programming languages:
|
||||
## Calling the secrets API from your code
|
||||
|
||||
### Go
|
||||
Once you have a secret store set up, you can call Dapr to get the secrets from your application code. Here are a few examples in different programming languages:
|
||||
|
||||
{{< tabs "Go" "Javascript" "Python" "Rust" "C#" >}}
|
||||
|
||||
{{% codetab %}}
|
||||
```Go
|
||||
import (
|
||||
"fmt"
|
||||
|
|
@ -49,7 +73,7 @@ import (
|
|||
)
|
||||
|
||||
func main() {
|
||||
url := "http://localhost:3500/v1.0/secrets/kubernetes/my-secret"
|
||||
url := "http://localhost:3500/v1.0/secrets/my-secrets-store/my-secret"
|
||||
|
||||
res, err := http.Get(url)
|
||||
if err != nil {
|
||||
|
|
@ -61,13 +85,16 @@ func main() {
|
|||
fmt.Println(string(body))
|
||||
}
|
||||
```
|
||||
### Javascript
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```javascript
|
||||
require('isomorphic-fetch');
|
||||
const secretsUrl = `http://localhost:3500/v1.0/secrets`;
|
||||
|
||||
fetch(`${secretsUrl}/kubernetes/my-secret`)
|
||||
fetch(`${secretsUrl}/my-secrets-store/my-secret`)
|
||||
.then((response) => {
|
||||
if (!response.ok) {
|
||||
throw "Could not get secret";
|
||||
|
|
@ -78,16 +105,21 @@ fetch(`${secretsUrl}/kubernetes/my-secret`)
|
|||
});
|
||||
```
|
||||
|
||||
### Python
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```python
|
||||
import requests as req
|
||||
|
||||
resp = req.get("http://localhost:3500/v1.0/secrets/kubernetes/my-secret")
|
||||
resp = req.get("http://localhost:3500/v1.0/secrets/my-secrets-store/my-secret")
|
||||
print(resp.text)
|
||||
```
|
||||
|
||||
### Rust
|
||||
{{% /codetab %}}
|
||||
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```rust
|
||||
#![deny(warnings)]
|
||||
|
|
@ -95,7 +127,7 @@ use std::{thread};
|
|||
|
||||
#[tokio::main]
|
||||
async fn main() -> Result<(), reqwest::Error> {
|
||||
let res = reqwest::get("http://localhost:3500/v1.0/secrets/kubernetes/my-secret").await?;
|
||||
let res = reqwest::get("http://localhost:3500/v1.0/secrets/my-secrets-store/my-secret").await?;
|
||||
let body = res.text().await?;
|
||||
println!("Secret:{}", body);
|
||||
|
||||
|
|
@ -105,13 +137,27 @@ async fn main() -> Result<(), reqwest::Error> {
|
|||
}
|
||||
```
|
||||
|
||||
### C#
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```csharp
|
||||
var client = new HttpClient();
|
||||
var response = await client.GetAsync("http://localhost:3500/v1.0/secrets/kubernetes/my-secret");
|
||||
var response = await client.GetAsync("http://localhost:3500/v1.0/secrets/my-secrets-store/my-secret");
|
||||
response.EnsureSuccessStatusCode();
|
||||
|
||||
string secret = await response.Content.ReadAsStringAsync();
|
||||
Console.WriteLine(secret);
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
## Related links
|
||||
|
||||
- [Dapr secrets overview]({{<ref secrets-overview>}})
|
||||
- [Secrets API reference]({{<ref secrets_api>}})
|
||||
- [Configure a secret store]({{<ref secret-stores-overview>}})
|
||||
- [Supported secrets]({{<ref secret-stores-overview>}})
|
||||
- [Using secrets in components]({{<ref component-secrets>}})
|
||||
- [Secret stores quickstart](https://github.com/dapr/quickstarts/tree/master/secretstore)
|
||||
|
|
@ -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>}})
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -49,9 +49,9 @@ Every binding has its own unique set of properties. Click the name link to see t
|
|||
| Name | Input<br>Binding | Output<br>Binding | Status |
|
||||
|------|:----------------:|:-----------------:|--------|
|
||||
| [Azure Blob Storage]({{< ref blobstorage.md >}}) | | ✅ | Experimental |
|
||||
| [Azure EventHubs]({{< ref eventhubs.md >}}) | ✅ | ✅ | Experimental |
|
||||
| [Azure CosmosDB]({{< ref cosmosdb.md >}}) | | ✅ | Experimental |
|
||||
| [Azure Event Grid]({{< ref eventgrid.md >}}) | ✅ | ✅ | Experimental |
|
||||
| [Azure Event Hubs]({{< ref eventhubs.md >}}) | ✅ | ✅ | Experimental |
|
||||
| [Azure Service Bus Queues]({{< ref servicebusqueues.md >}}) | ✅ | ✅ | Experimental |
|
||||
| [Azure SignalR]({{< ref signalr.md >}}) | | ✅ | Experimental |
|
||||
| [Azure Storage Queues]({{< ref storagequeues.md >}}) | ✅ | ✅ | Experimental |
|
||||
| [Azure Event Grid]({{< ref eventgrid.md >}}) | ✅ | ✅ | Experimental |
|
||||
|
|
|
|||
|
|
@ -1,4 +1,3 @@
|
|||
|
||||
---
|
||||
type: docs
|
||||
title: "Apple Push Notification Service binding spec"
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ Three different event types are available:
|
|||
- Delete : Only the `oldVal` field is populated, `newVal` field is an empty `v1.Event`, `event` is `delete`
|
||||
- Update : Both the `oldVal` and `newVal` fields are populated, `event` is `update`
|
||||
|
||||
## Required permisiions
|
||||
## Required permissions
|
||||
|
||||
For consuming `events` from Kubernetes, permissions need to be assigned to a User/Group/ServiceAccount using [RBAC Auth] mechanism of Kubernetes.
|
||||
|
||||
|
|
@ -105,4 +105,4 @@ roleRef:
|
|||
- [Bindings building block]({{< ref bindings >}})
|
||||
- [How-To: Trigger application with input binding]({{< ref howto-triggers.md >}})
|
||||
- [How-To: Use bindings to interface with external resources]({{< ref howto-bindings.md >}})
|
||||
- [Bindings API reference]({{< ref bindings_api.md >}})
|
||||
- [Bindings API reference]({{< ref bindings_api.md >}})
|
||||
|
|
|
|||
|
|
@ -63,6 +63,8 @@ spec:
|
|||
# blow are subscription configuration.
|
||||
- name: subscriptionType
|
||||
value: <REPLACE-WITH-SUBSCRIPTION-TYPE> # Required. Allowed values: topic, queue.
|
||||
- name: deliverNew
|
||||
value: true
|
||||
# - name: ackWaitTime
|
||||
# value: "" # Optional. See: https://docs.nats.io/developing-with-nats-streaming/acks#acknowledgements
|
||||
# - name: maxInFlight
|
||||
|
|
@ -74,9 +76,7 @@ spec:
|
|||
# value: 1
|
||||
# - name: startWithLastReceived
|
||||
# value: false
|
||||
- name: deliverAll
|
||||
value: true
|
||||
# - name: deliverNew
|
||||
# - name: deliverAll
|
||||
# value: false
|
||||
# - name: startAtTimeDelta
|
||||
# value: ""
|
||||
|
|
|
|||
|
|
@ -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