dapr
/
docs
mirror of https://github.com/dapr/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'v0.11' into docsday-956

This commit is contained in:
Ori Zohar 2020-12-17 14:33:53 -08:00 committed by GitHub
parent 47f23f2f58 44ae1a134b
commit 5b57ba4809
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 96 additions and 86 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

172
daprdocs/content/en/operations/components/component-secrets.md
View File

@ -1,6 +1,6 @@
---
type: docs
title: "How-To: Reference secret stores in components"
title: "How-To: Reference secrets in components"
linkTitle: "How-To: Reference secrets"
weight: 200
description: "How to securly reference secrets from a component definition"
@ -18,9 +18,93 @@ When running in Kubernetes, if the `auth.secretStore` is empty, the Kubernetes s
Go to [this]({{< ref "howto-secrets.md" >}}) link to see all the secret stores supported by Dapr, along with information on how to configure and use them.
## Non default namespaces
## Referencing secrets
If your Dapr enabled apps are using components that fetch secrets from non-default namespaces, apply the following resources to the namespace:
While you have the option to use plain text secrets, this is not recommended for production:
```yml
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
name: statestore
namespace: default
spec:
type: state.redis
version: v1
metadata:
- name: redisHost
value: localhost:6379
- name: redisPassword
value: MyPassword
```
Instead create the secret in your secret store and reference it in the component definition:
```yml
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
name: statestore
namespace: default
spec:
type: state.redis
version: v1
metadata:
- name: redisHost
value: localhost:6379
- name: redisPassword
secretKeyRef:
name: redis-secret
key: redis-password
auth:
secretStore: <SECRET_STORE_NAME>
```
`SECRET_STORE_NAME` is the name of the configured [secret store component]({{< ref supported-secret-stores >}}). When running in Kubernetes and using a Kubernetes secret store, the field `auth.SecretStore` defaults to `kubernetes` and can be left empty.
The above component definition tells Dapr to extract a secret named `redis-secret` from the defined secret store and assign the value of the `redis-password` key in the secret to the `redisPassword` field in the Component.
## Example
### Referencing a Kubernetes secret
The following example shows you how to create a Kubernetes secret to hold the connection string for an Event Hubs binding.
1. First, create the Kubernetes secret:
```bash
kubectl create secret generic eventhubs-secret --from-literal=connectionString=*********
```
2. Next, reference the secret in your binding:
```yaml
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
name: eventhubs
namespace: default
spec:
type: bindings.azure.eventhubs
version: v1
metadata:
- name: connectionString
secretKeyRef:
name: eventhubs-secret
key: connectionString
```
3. Finally, apply the component to the Kubernetes cluster:
```bash
kubectl apply -f ./eventhubs.yaml
```
## Kubernetes permissions
### Default namespace
When running in Kubernetes, Dapr, during installtion, defines default Role and RoleBinding for secrets access from Kubernetes secret store in the `default` namespace. For Dapr enabled apps that fetch secrets from `default` namespace, a secret can be defined and referenced in components as shown in the example above.
### Non-default namespaces
If your Dapr enabled apps are using components that fetch secrets from non-default namespaces, apply the following resources to that namespace:
```yaml
---
@ -49,82 +133,8 @@ roleRef:
apiGroup: rbac.authorization.k8s.io
```
## Examples
These resources grant Dapr permissions to get secrets from the Kubernetes secret store for the namespace defined in the Role and RoleBinding.
Using plain text:
```yml
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
name: statestore
namespace: default
spec:
type: state.redis
version: v1
metadata:
- name: redisHost
value: localhost:6379
- name: redisPassword
value: MyPassword
```
Using a Kubernetes secret:
```yml
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
name: statestore
namespace: default
spec:
type: state.redis
version: v1
metadata:
- name: redisHost
value: localhost:6379
- name: redisPassword
secretKeyRef:
name: redis-secret
key: redis-password
auth:
secretStore: kubernetes
```
The above example tells Dapr to use the `kubernetes` secret store, extract a secret named `redis-secret` and assign the value of the `redis-password` key in the secret to the `redisPassword` field in the Component.
### Creating a secret and referencing it in a Component
The following example shows you how to create a Kubernetes secret to hold the connection string for an Event Hubs binding.
First, create the Kubernetes secret:
```bash
kubectl create secret generic eventhubs-secret --from-literal=connectionString=*********
```
Next, reference the secret in your binding:
```yaml
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
name: eventhubs
namespace: default
spec:
type: bindings.azure.eventhubs
version: v1
metadata:
- name: connectionString
secretKeyRef:
name: eventhubs-secret
key: connectionString
```
Finally, apply the component to the Kubernetes cluster:
```bash
kubectl apply -f ./eventhubs.yaml
```
All done!
{{% alert title="Note" color="warning" %}}
In production scenario to limit Dapr's access to certain secret resources alone, you can use the `resourceNames` field. See this [link](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#referring-to-resources) for further explanation.
{{% /alert %}}

2
daprdocs/content/en/operations/components/setup-bindings/supported-bindings/blobstorage.md
View File

@ -38,7 +38,7 @@ The above example uses secrets as plain strings. It is recommended to use a secr
### Create Blob
To perform a get blob operation, invoke the Azure Blob Storage binding with a `POST` method and the following JSON body:
To perform a create blob operation, invoke the Azure Blob Storage binding with a `POST` method and the following JSON body:
```json
{

8
daprdocs/content/en/operations/monitoring/zipkin.md
View File

@ -11,7 +11,7 @@ type: docs
For self hosted mode, on running `dapr init`:
1. The following YAML file is created by default in `$HOME/dapr/config.yaml` (on Linux/Mac) or `%USERPROFILE%\dapr\config.yaml` (on Windows) and it is referenced by default on `dapr run` calls unless otherwise overridden `:
1. The following YAML file is created by default in `$HOME/.dapr/config.yaml` (on Linux/Mac) or `%USERPROFILE%\.dapr\config.yaml` (on Windows) and it is referenced by default on `dapr run` calls unless otherwise overridden `:
* config.yaml
@ -24,8 +24,8 @@ metadata:
spec:
tracing:
samplingRate: "1"
zipkin:
endpointAddress: "http://localhost:9411/api/v2/spans"
zipkin:
endpointAddress: "http://localhost:9411/api/v2/spans"
```
2. The [openzipkin/zipkin](https://hub.docker.com/r/openzipkin/zipkin/) docker container is launched on running `dapr init` or it can be launched with the following code.
@ -36,7 +36,7 @@ Launch Zipkin using Docker:
docker run -d -p 9411:9411 openzipkin/zipkin
```
3. The applications launched with `dapr run` will by default reference the config file in `$HOME/dapr/config.yaml` or `%USERPROFILE%\dapr\config.yaml` and can be overridden with the Dapr CLI using the `--config` param:
3. The applications launched with `dapr run` will by default reference the config file in `$HOME/.dapr/config.yaml` or `%USERPROFILE%\.dapr\config.yaml` and can be overridden with the Dapr CLI using the `--config` param:
```bash
dapr run --app-id mynode --app-port 3000 node app.js