diff --git a/daprdocs/content/en/operations/components/component-secrets.md b/daprdocs/content/en/operations/components/component-secrets.md index 074b691b0..bd4c4f20f 100644 --- a/daprdocs/content/en/operations/components/component-secrets.md +++ b/daprdocs/content/en/operations/components/component-secrets.md @@ -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` 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 %}} diff --git a/daprdocs/content/en/operations/components/setup-bindings/supported-bindings/blobstorage.md b/daprdocs/content/en/operations/components/setup-bindings/supported-bindings/blobstorage.md index 49af5d23a..02a38eac2 100644 --- a/daprdocs/content/en/operations/components/setup-bindings/supported-bindings/blobstorage.md +++ b/daprdocs/content/en/operations/components/setup-bindings/supported-bindings/blobstorage.md @@ -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 { diff --git a/daprdocs/content/en/operations/monitoring/zipkin.md b/daprdocs/content/en/operations/monitoring/zipkin.md index 5939661e5..cd92af512 100644 --- a/daprdocs/content/en/operations/monitoring/zipkin.md +++ b/daprdocs/content/en/operations/monitoring/zipkin.md @@ -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