taking latest from hugo-docs branch

This commit is contained in:
Ori Zohar 2020-10-09 16:04:19 -07:00
commit 515d26d35a
47 changed files with 445 additions and 400 deletions

View File

@ -1 +0,0 @@

View File

@ -0,0 +1,11 @@
---
title: "Configuration"
linkTitle: "Configuration"
weight: 400
description: "Change the behavior of Dapr sidecars or globally on Dapr system services"
---
Dapr configurations are settings that enable you to change the behavior of individual Dapr application sidecars or globally on the system services in the Dapr control plane.
An example of a per Dapr application sidecar setting is configuring trace settings. An example of a Dapr control plane setting is mutual TLS which is a global setting on the Sentry system service.
Read [this page]({{< ref "configuration-overview.md" >}}) for a list of all configuration options.

View File

@ -1,263 +0,0 @@
---
title: "Configuration"
linkTitle: "Configuration"
weight: 400
description: "Change the behavior of Dapr sidecars or globally on Dapr system services"
---
Dapr configurations are settings that enable you to change the behavior of individual Dapr application sidecars or globally on the system services in the Dapr control plane.
An example of a per Dapr application sidecar setting is configuring trace settings. An example of a Dapr control plane setting is mutual TLS which is a global setting on the Sentry system service.
## Setting self hosted sidecar configuration
In self hosted mode the Dapr configuration is a configuration file, for example `config.yaml`. By default the Dapr sidecar looks in the default Dapr folder for the runtime configuration eg: `$HOME/.dapr/config.yaml` in Linux/MacOS and `%USERPROFILE%\.dapr\config.yaml` in Windows.
A Dapr sidecar can also apply a configuration by using a ```--config``` flag to the file path with ```dapr run``` CLI command.
## Setting Kubernetes sidecar configuration
In Kubernetes mode the Dapr configuration is a Configuration CRD, that is applied to the cluster. For example;
```cli
kubectl apply -f myappconfig.yaml
```
You can use the Dapr CLI to list the Configuration CRDs
```cli
dapr configurations -k
```
A Dapr sidecar can apply a specific configuration by using a ```dapr.io/config``` annotation. For example:
```yml
annotations:
dapr.io/enabled: "true"
dapr.io/app-id: "nodeapp"
dapr.io/app-port: "3000"
dapr.io/config: "myappconfig"
```
Note: There are more [Kubernetes annotations](../../howto/configure-k8s/README.md) available to configure the Dapr sidecar on activation by sidecar Injector system service.
## Sidecar configuration settings
The following configuration settings can be applied to Dapr application sidecars;
- [Tracing](#tracing)
- [Middleware](#middleware)
- [Scoping secrets for secret stores](#scoping-secrets-for-secret-stores)
- [Access control allow lists for service invocation](#access-control-allow-lists-for-service-invocation)
- [Example application sidecar configuration](#example-application-sidecar-configuration)
### Tracing
Tracing configuration turns on tracing for an application.
The `tracing` section under the `Configuration` spec contains the following properties:
```yml
tracing:
samplingRate: "1"
```
The following table lists the properties for tracing:
Property | Type | Description
---- | ------- | -----------
samplingRate | string | Set sampling rate for tracing to be enabled or disabled.
`samplingRate` is used to enable or disable the tracing. To disable the sampling rate ,
set `samplingRate : "0"` in the configuration. The valid range of samplingRate is between 0 and 1 inclusive. The sampling rate determines whether a trace span should be sampled or not based on value. `samplingRate : "1"` samples all traces. By default, the sampling rate is (0.0001) or 1 in 10,000 traces.
See [Observability distributed tracing](../observability/traces.md) for more information
### Middleware
Middleware configuration set named Http pipeline middleware handlers
The `httpPipeline` section under the `Configuration` spec contains the following properties:
```yml
httpPipeline:
handlers:
- name: oauth2
type: middleware.http.oauth2
- name: uppercase
type: middleware.http.uppercase
```
The following table lists the properties for HTTP handlers:
Property | Type | Description
---- | ------- | -----------
name | string | name of the middleware component
type | string | type of middleware component
See [Middleware pipelines](../middleware/README.md) for more information
### Scoping secrets for secret stores
In addition to scoping which applications can access a given component, for example a secret store component (see [Scoping components](../../howto/components-scopes)), a named secret store component itself can be scoped to one or more secrets for an application. By defining `allowedSecrets` and/or `deniedSecrets` list, applications can be restricted to access only specific secrets.
The `secrets` section under the `Configuration` spec contains the following properties:
```yml
secrets:
scopes:
- storeName: kubernetes
defaultAccess: allow
allowedSecrets: ["redis-password"]
- storeName: localstore
defaultAccess: allow
deniedSecrets: ["redis-password"]
```
The following table lists the properties for secret scopes:
Property | Type | Description
---- | ------- | -----------
storeName | string | name of the secret store component. storeName must be unique within the list
defaultAccess | string | access modifier. Accepted values "allow" (default) or "deny"
allowedSecrets | list | list of secret keys that can be accessed
deniedSecrets | list | list of secret keys that cannot be accessed
When an `allowedSecrets` list is present with at least one element, only those secrets defined in the list can be accessed by the application.
See the [Scoping secrets](../../howto/secrets-scopes/README.md) HowTo for examples on how to scope secrets to an application.
### Access Control allow lists for service invocation
Access control enables the configuration of policies that restrict what operations *calling* applications can perform, via service invocation, on the *called* application.
An access control policy is specified in configuration and be applied to Dapr sidecar for the *called* application. Example access policies are shown below and access to the called app is based on the matched policy action. You can provide a default global action for all calling applications and if no access control policy is specified, the default behavior is to allow all calling applicatons to access to the called app.
## Concepts
**TrustDomain** - A "trust domain" is a logical group to manage trust relationships. Every application is assigned a trust domain which can be specified in the access control list policy spec. If no policy spec is defined or an empty trust domain is specified, then a default value "public" is used. This trust domain is used to generate the identity of the application in the TLS cert.
**App Identity** - Dapr generates a [SPIFFE](https://spiffe.io/) id for all applications which is attached in the TLS cert. The SPIFFE id is of the format: **spiffe://\<trustdomain>/ns/\<namespace\>/\<appid\>**. For matching policies, the trust domain, namespace and app ID values of the calling app are extracted from the SPIFFE id in the TLS cert of the calling app. These values are matched against the trust domain, namespace and app ID values specified in the policy spec. If all three of these match, then more specific policies are further matched.
```
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
name: appconfig
spec:
accessControl:
defaultAction: deny --> Global default action in case no other policy is matched
trustDomain: "public" --> The called application is assigned a trust domain and is used to generate the identity of this app in the TLS certificate.
policies:
- appId: app1 --> AppId of the calling app to allow/deny service invocation from
defaultAction: deny --> App level default action in case the app is found but no specific operation is matched
trustDomain: 'public' --> Trust domain of the calling app is matched against the specified value here.
namespace: "default" --> Namespace of the calling app is matched against the specified value here.
operations:
- name: /op1 --> operation name on the called app
httpVerb: ['POST', 'GET'] --> specific http verbs, unused for grpc invocation
action: deny --> allow/deny access
- name: /op2/* --> operation name with a postfix
httpVerb: ["*"] --> wildcards can be used to match any http verb
action: allow
- appId: app2
defaultAction: allow
trustDomain: "public"
namespace: "default"
operations:
- name: /op3
httpVerb: ['POST', 'PUT']
action: deny
```
The following tables lists the different properties for access control, policies and operations:
Access Control
Property | Type | Description
---- | ------- | -----------
defaultAction | string | Global default action when no other policy is matched
trustDomain | string | Trust domain assigned to the application. Default is "public".
policies | string | Policies to determine what operations the calling app can do on the called app
Policies
Property | Type | Description
---- | ------- | -----------
app | string | AppId of the calling app to allow/deny service invocation from
namespace | string | Namespace value that needs to be matched with the namespace of the calling app
trustDomain | string | Trust domain that needs to be matched with the trust domain of the calling app. Default is "public"
defaultAction | string | App level default action in case the app is found but no specific operation is matched
operations | string | operations that are allowed from the calling app
Operations
Property | Type | Description
---- | ------- | -----------
name | string | Path name of the operations allowed on the called app. Wildcard "\*" can be used to under a path to match
httpVerb | list | list specific http verbs that can be used by the calling app. Wildcard "\*" can be used to match any http verb. Unused for grpc invocation
action | string | Access modifier. Accepted values "allow" (default) or "deny"
See the [Allow lists for service invocation](../../howto/allowlists-serviceinvocation/README.md) HowTo for examples on how to set allow lists.
### Example application sidecar configuration
The following yaml shows an example configuration file that can be applied to an applications' Dapr sidecar.
```yml
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
name: myappconfig
namespace: default
spec:
tracing:
samplingRate: "1"
httpPipeline:
handlers:
- name: oauth2
type: middleware.http.oauth2
secrets:
scopes:
- storeName: localstore
defaultAccess: allow
deniedSecrets: ["redis-password"]
accessControl:
defaultAction: deny
trustDomain: "public"
policies:
- appId: app1
defaultAction: deny
trustDomain: 'public'
namespace: "default"
operations:
- name: /op1
httpVerb: ['POST', 'GET']
action: deny
- name: /op2/*
httpVerb: ["*"]
action: allow
```
## Setting Kubernetes control plane configuration
There is a single configuration file called `default` installed with the Dapr control plane system services that applies global settings. This is set up when Dapr is deployed to Kubernetes
## Control plane configuration settings
A Dapr control plane configuration can configure the following settings:
Property | Type | Description
---- | ------- | -----------
enabled | bool | Set mtls to be enabled or disabled
allowedClockSkew | string | The extra time to give for certificate expiry based on possible clock skew on a machine. Default is 15 minutes.
workloadCertTTL | string | Time a certificate is valid for. Default is 24 hours
See the [Mutual TLS](../../howto/configure-mtls/README.md) HowTo and [security concepts](../security/README.md) for more information.
### Example control plane configuration
```yaml
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
name: default
namespace: default
spec:
mtls:
enabled: true
allowedClockSkew: 15m
workloadCertTTL: 24h
```
## References
* [Distributed tracing](../observability/traces.md)
* [Middleware pipelines](../middleware/README.md)
* [Security](../security/README.md)
* [How-To: Configuring the Dapr sidecar on Kubernetes](../../howto/configure-k8s/README.md)

View File

@ -77,4 +77,7 @@ scopes:
- app1
- app2
```
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.
## Example
<iframe width="560" height="315" src="https://www.youtube.com/embed/8W-iBDNvCUM?start=1763" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

View File

@ -5,6 +5,8 @@ weight: 7000
description: "How to securly reference secrets from a component definition"
---
## Overview
Components can reference secrets for the `spec.metadata` section within the components definition.
In order to reference a secret, you need to set the `auth.secretStore` field to specify the name of the secret store that holds the secrets.
@ -13,7 +15,7 @@ When running in Kubernetes, if the `auth.secretStore` is empty, the Kubernetes s
### Supported secret stores
Go to [this](../../howto/setup-secret-store/README.md) link to see all the secret stores supported by Dapr, along with information on how to configure and use them.
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

View File

@ -0,0 +1,169 @@
---
title: "Overview of Dapr configuration options"
linkTitle: "Overview"
weight: 100
description: "Information on Dapr configuration and how to set options for your application"
---
## Sidecar configuration
### Setup sidecar configuration
#### Self-hosted sidecar
In self hosted mode the Dapr configuration is a configuration file, for example `config.yaml`. By default the Dapr sidecar looks in the default Dapr folder for the runtime configuration eg: `$HOME/.dapr/config.yaml` in Linux/MacOS and `%USERPROFILE%\.dapr\config.yaml` in Windows.
A Dapr sidecar can also apply a configuration by using a ```--config``` flag to the file path with ```dapr run``` CLI command.
#### Kubernetes sidecar
In Kubernetes mode the Dapr configuration is a Configuration CRD, that is applied to the cluster. For example;
```bash
kubectl apply -f myappconfig.yaml
```
You can use the Dapr CLI to list the Configuration CRDs
```bash
dapr configurations -k
```
A Dapr sidecar can apply a specific configuration by using a ```dapr.io/config``` annotation. For example:
```yml
annotations:
dapr.io/enabled: "true"
dapr.io/app-id: "nodeapp"
dapr.io/app-port: "3000"
dapr.io/config: "myappconfig"
```
Note: There are more [Kubernetes annotations]({{< ref "kubernetes-annotations.md" >}}) available to configure the Dapr sidecar on activation by sidecar Injector system service.
### Sidecar configuration settings
The following configuration settings can be applied to Dapr application sidecars;
- [Tracing](#tracing)
- [Middleware](#middleware)
- [Scoping secrets for secret stores](#scoping-secrets-for-secret-stores)
- [Access control allow lists for service invocation](#access-control-allow-lists-for-service-invocation)
- [Example application sidecar configuration](#example-application-sidecar-configuration)
#### Tracing
Tracing configuration turns on tracing for an application.
The `tracing` section under the `Configuration` spec contains the following properties:
```yml
tracing:
samplingRate: "1"
```
The following table lists the properties for tracing:
| Property | Type | Description |
|--------------|--------|-------------|
| samplingRate | string | Set sampling rate for tracing to be enabled or disabled.
`samplingRate` is used to enable or disable the tracing. To disable the sampling rate ,
set `samplingRate : "0"` in the configuration. The valid range of samplingRate is between 0 and 1 inclusive. The sampling rate determines whether a trace span should be sampled or not based on value. `samplingRate : "1"` samples all traces. By default, the sampling rate is (0.0001) or 1 in 10,000 traces.
See [Observability distributed tracing]({{< ref "tracing.md" >}}) for more information
#### Middleware
Middleware configuration set named Http pipeline middleware handlers
The `httpPipeline` section under the `Configuration` spec contains the following properties:
```yml
httpPipeline:
handlers:
- name: oauth2
type: middleware.http.oauth2
- name: uppercase
type: middleware.http.uppercase
```
The following table lists the properties for HTTP handlers:
| Property | Type | Description |
|----------|--------|-------------|
| name | string | Name of the middleware component
| type | string | Type of middleware component
See [Middleware pipelines]({{< ref "middleware-concept.md" >}}) for more information
#### Scope secret store access
See the [Scoping secrets]({{< ref "secret-scope.md" >}}) guide for information and examples on how to scope secrets to an application.
#### Access Control allow lists for service invocation
See the [Allow lists for service invocation]({{< ref "invoke-allowlist.md" >}}) guide for information and examples on how to set allow lists.
### Example sidecar configuration
The following yaml shows an example configuration file that can be applied to an applications' Dapr sidecar.
```yml
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
name: myappconfig
namespace: default
spec:
tracing:
samplingRate: "1"
httpPipeline:
handlers:
- name: oauth2
type: middleware.http.oauth2
secrets:
scopes:
- storeName: localstore
defaultAccess: allow
deniedSecrets: ["redis-password"]
accessControl:
defaultAction: deny
trustDomain: "public"
policies:
- appId: app1
defaultAction: deny
trustDomain: 'public'
namespace: "default"
operations:
- name: /op1
httpVerb: ['POST', 'GET']
action: deny
- name: /op2/*
httpVerb: ["*"]
action: allow
```
## Control-plane configuration
There is a single configuration file called `default` installed with the Dapr control plane system services that applies global settings. This is only set up when Dapr is deployed to Kubernetes.
### Control-plane configuration settings
A Dapr control plane configuration can configure the following settings:
| Property | Type | Description |
|------------------|--------|-------------|
| enabled | bool | Set mtls to be enabled or disabled
| allowedClockSkew | string | The extra time to give for certificate expiry based on possible clock skew on a machine. Default is 15 minutes.
| workloadCertTTL | string | Time a certificate is valid for. Default is 24 hours
See the [Mutual TLS]({{< ref "mtls.md" >}}) HowTo and [security concepts]({{< ref "security-concept.md" >}}) for more information.
### Example control plane configuration
```yaml
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
name: default
namespace: default
spec:
mtls:
enabled: true
allowedClockSkew: 15m
workloadCertTTL: 24h
```

View File

@ -1,7 +1,7 @@
---
title: "Control concurrency and rate limit applications"
linkTitle: "Concurrency & rate limits"
weight: 1000
weight: 2000
description: "Control how many requests and events will invoke your application simultaneously"
---

View File

@ -1,7 +1,7 @@
---
title: "Configure Dapr to use gRPC"
linkTitle: "Use gRPC interface"
weight: 3000
weight: 5000
description: "How to configure Dapr to use gRPC for low-latency, high performance scenarios"
---

View File

@ -1,23 +1,49 @@
---
title: "Apply access control list configuration for service invocation"
linkTitle: "Service Invocation access control"
weight: 2000
weight: 4000
description: "Restrict what operations *calling* applications can perform, via service invocation, on the *called* application"
---
Access control enables the configuration of policies that restrict what operations *calling* applications can perform, via service invocation, on the *called* application. To limit access to a called applications from specific operations and HTTP verbs from the calling applications, you can define an access control policy specification in configuration.
- [Concepts](#concepts)
- [Policy rules](#policy-rules)
- [Policy priority](#policy-priority)
- [Example scenarios](#example-scenarios)
- [Hello world example](#hello-world-example)
An access control policy is specified in configuration and be applied to Dapr sidecar for the *called* application. Example access policies are shown below and access to the called app is based on the matched policy action. You can provide a default global action for all calling applications and if no access control policy is specified, the default behavior is to allow all calling applicatons to access to the called app.
## Concepts
**TrustDomain** - A "trust domain" is a logical group to manage trust relationships. Every application is assigned a trust domain which can be specified in the access control list policy spec. If no policy spec is defined or an empty trust domain is specified, then a default value "public" is used. This trust domain is used to generate the identity of the application in the TLS cert.
**App Identity** - Dapr generates a [SPIFFE](https://spiffe.io/) id for all applications which is attached in the TLS cert. The SPIFFE id is of the format: **spiffe://\<trustdomain>/ns/\<namespace\>/\<appid\>**. For matching policies, the trust domain, namespace and app ID values of the calling app are extracted from the SPIFFE id in the TLS cert of the calling app. These values are matched against the trust domain, namespace and app ID values specified in the policy spec. If all three of these match, then more specific policies are further matched.
**App Identity** - Dapr generates a [SPIFFE](https://spiffe.io/) id for all applications which is attached in the TLS cert. The SPIFFE id is of the format: `**spiffe://\<trustdomain>/ns/\<namespace\>/\<appid\>**`. For matching policies, the trust domain, namespace and app ID values of the calling app are extracted from the SPIFFE id in the TLS cert of the calling app. These values are matched against the trust domain, namespace and app ID values specified in the policy spec. If all three of these match, then more specific policies are further matched.
## Configuration properties
The following tables lists the different properties for access control, policies and operations:
### Access Control
| Property | Type | Description |
|---------------|--------|-------------|
| defaultAction | string | Global default action when no other policy is matched
| trustDomain | string | Trust domain assigned to the application. Default is "public".
| policies | string | Policies to determine what operations the calling app can do on the called app
### Policies
| Property | Type | Description |
|---------------|--------|-------------|
| app | string | AppId of the calling app to allow/deny service invocation from
| namespace | string | Namespace value that needs to be matched with the namespace of the calling app
| trustDomain | string | Trust domain that needs to be matched with the trust domain of the calling app. Default is "public"
| defaultAction | string | App level default action in case the app is found but no specific operation is matched
| operations | string | operations that are allowed from the calling app
### Operations
| Property | Type | Description |
|----------|--------|-------------|
| name | string | Path name of the operations allowed on the called app. Wildcard "\*" can be used to under a path to match
| httpVerb | list | List specific http verbs that can be used by the calling app. Wildcard "\*" can be used to match any http verb. Unused for grpc invocation
| action | string | Access modifier. Accepted values "allow" (default) or "deny"
## Policy rules
@ -36,9 +62,10 @@ The action corresponding to the most specific policy matched takes effect as ord
## Example scenarios
Below are some example scenarios for using access control list for service invocation. See [configuration guidance](../../concepts/configuration/README.md) to understand the available configuration settings for an application sidecar.
Below are some example scenarios for using access control list for service invocation. See [configuration guidance]({{< ref "configuration-concept.md" >}}) to understand the available configuration settings for an application sidecar.
<font size=5>Scenario 1: Deny access to all apps except where trustDomain = public, namespace = default, appId = app1</font>
### Scenario 1 : Deny access to all apps except where trustDomain = public, namespace = default, appId = app1
With this configuration, all calling methods with appId = app1 are allowed and all other invocation requests from other applications are denied
```yaml
@ -57,7 +84,8 @@ spec:
namespace: "default"
```
### Scenario 2 : Deny access to all apps except trustDomain = public, namespace = default, appId = app1, operation = op1
<font size=5>Scenario 2: Deny access to all apps except trustDomain = public, namespace = default, appId = app1, operation = op1</font>
With this configuration, only method op1 from appId = app1 is allowed and all other method requests from all other apps, including other methods on app1, are denied
```yaml
@ -80,7 +108,7 @@ spec:
action: allow
```
### Scenario 3 : Deny access to all apps except when a specific verb for HTTP and operation for GRPC is matched
<font size=5>Scenario 3: Deny access to all apps except when a specific verb for HTTP and operation for GRPC is matched</font>
With this configuration, the only scenarios below are allowed access and and all other method requests from all other apps, including other methods on app1 or app2, are denied
* trustDomain = public, namespace = default, appID = app1, operation = op1, http verb = POST/PUT
@ -114,7 +142,7 @@ spec:
action: allow
```
### Scenario 4 : Allow access to all methods except trustDomain = public, namespace = default, appId = app1, operation = /op1/*, all http verbs
<font size=5>Scenario 4: Allow access to all methods except trustDomain = public, namespace = default, appId = app1, operation = /op1/*, all http verbs</font>
```yaml
apiVersion: dapr.io/v1alpha1
@ -136,7 +164,7 @@ spec:
action: deny
```
### Scenario 5 : Allow access to all methods for trustDomain = public, namespace = ns1, appId = app1 and deny access to all methods for trustDomain = public, namespace = ns2, appId = app1
<font size=5>Scenario 5: Allow access to all methods for trustDomain = public, namespace = ns1, appId = app1 and deny access to all methods for trustDomain = public, namespace = ns2, appId = app1</font>
This scenario shows how applications with the same app ID but belonging to different namespaces can be specified
@ -161,7 +189,7 @@ spec:
```
## Hello world example
This scenario shows how to apply access control to the [hello world](https://github.com/dapr/quickstarts/blob/master/hello-world/README.md) or [hello kubernetes](https://github.com/dapr/quickstarts/blob/master/hello-world/README.md) samples where a python app invokes a node.js app. You can create and apply these configuration files `nodeappconfig.yaml` and `pythonappconfig.yaml` as described in the [configuration](../../concepts/configuration/README.md) article.
This scenario shows how to apply access control to the [hello world](https://github.com/dapr/quickstarts/blob/master/hello-world/README.md) or [hello kubernetes](https://github.com/dapr/quickstarts/blob/master/hello-world/README.md) samples where a python app invokes a node.js app. You can create and apply these configuration files `nodeappconfig.yaml` and `pythonappconfig.yaml` as described in the [configuration]({{< ref "configuration-concept.md" >}}) article.
The nodeappconfig example below shows how to deny access to the `neworder` method from the `pythonapp`, where the python app is in the `myDomain` trust domain and `default` namespace. The nodeapp is in the `public` trust domain.
@ -232,7 +260,3 @@ spec:
- name: python
image: dapriosamples/hello-k8s-python:edge
```
## Related Links
* [Configuration concepts](../../concepts/configuration/README.md)

View File

@ -0,0 +1,115 @@
---
title: "Limit the secrets that can be read from secret stores"
linkTitle: "Limit secret store access"
weight: 3000
description: "To limit the secrets to which the Dapr application has access, users can define secret scopes by augmenting existing configuration CRD with restrictive permissions."
---
In addition to scoping which applications can access a given component, for example a secret store component (see [Scoping components]({{< ref "component-scopes.md">}})), a named secret store component itself can be scoped to one or more secrets for an application. By defining `allowedSecrets` and/or `deniedSecrets` list, applications can be restricted to access only specific secrets.
Follow [these instructions]({{< ref "configuration-overview.md" >}}) to define a configuration CRD.
## Configure secrets access
The `secrets` section under the `Configuration` spec contains the following properties:
```yml
secrets:
scopes:
- storeName: kubernetes
defaultAccess: allow
allowedSecrets: ["redis-password"]
- storeName: localstore
defaultAccess: allow
deniedSecrets: ["redis-password"]
```
The following table lists the properties for secret scopes:
| Property | Type | Description |
|----------------|--------|-------------|
| storeName | string | Name of the secret store component. storeName must be unique within the list
| defaultAccess | string | Access modifier. Accepted values "allow" (default) or "deny"
| allowedSecrets | list | List of secret keys that can be accessed
| deniedSecrets | list | List of secret keys that cannot be accessed
When an `allowedSecrets` list is present with at least one element, only those secrets defined in the list can be accessed by the application.
## Permission priority
The `allowedSecrets` and `deniedSecrets` list values take priorty over the `defaultAccess`.
| Scenarios | defaultAccess | allowedSecrets | deniedSecrets | permission
|----- | ------- | -----------| ----------| ------------
| 1 - Only default access | deny/allow | empty | empty | deny/allow
| 2 - Default deny with allowed list | deny | ["s1"] | empty | only "s1" can be accessed
| 3 - Default allow with deneied list | allow | empty | ["s1"] | only "s1" cannot be accessed
| 4 - Default allow with allowed list | allow | ["s1"] | empty | only "s1" can be accessed
| 5 - Default deny with denied list | deny | empty | ["s1"] | deny
| 6 - Default deny/allow with both lists | deny/allow | ["s1"] | ["s2"] | only "s1" can be accessed
## Examples
### Scenario 1 : Deny access to all secrets for a secret store
In Kubernetes cluster, the native Kubernetes secret store is added to Dapr application by default. In some scenarios it may be necessary to deny access to Dapr secrets for a given application. To add this configuration follow the steps below:
Define the following `appconfig.yaml` and apply it to the Kubernetes cluster using the command `kubectl apply -f appconfig.yaml`.
```yaml
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
name: appconfig
spec:
secrets:
scopes:
- storeName: kubernetes
defaultAccess: deny
```
For applications that need to be deined access to the Kubernetes secret store, follow [these instructions](../configure-k8s/README.md), and add the following annotation to the application pod.
```yaml
dapr.io/config: appconfig
```
With this defined, the application no longer has access to Kubernetes secret store.
### Scenario 2 : Allow access to only certain secrets in a secret store
To allow a Dapr application to have access to only certain secrets, define the following `config.yaml`:
```yaml
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
name: appconfig
spec:
secrets:
scopes:
- storeName: vault
defaultAccess: deny
allowedSecrets: ["secret1", "secret2"]
```
This example defines configuration for secret store named vault. The default access to the secret store is `deny`, whereas some secrets are accessible by the application based on the `allowedSecrets` list. Follow [these instructions](../../concepts/configuration/README.md) to apply configuration to the sidecar.
### Scenario 3: Deny access to certain senstive secrets in a secret store
Define the following `config.yaml`:
```yaml
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
name: appconfig
spec:
secrets:
scopes:
- storeName: vault
defaultAccess: allow # this is the default value, line can be omitted
deniedSecrets: ["secret1", "secret2"]
```
The above configuration explicitly denies access to `secret1` and `secret2` from the secret store named vault while allowing access to all other secrets. Follow [these instructions](../../concepts/configuration/README.md) to apply configuration to the sidecar.

View File

@ -1,6 +1,6 @@
---
title: "Hosting options for Dapr"
linkTitle: "Hosting Options"
linkTitle: "Hosting options"
weight: 100
description: "How to deploy Dapr into your environment."
---

View File

@ -7,8 +7,8 @@ description: "The available annotations available when configuring Dapr in your
The following table shows all the supported pod Spec annotations supported by Dapr.
| Annotation | Description
|---------------------------------------------------|-------|
| Annotation | Description |
|---------------------------------------------------|-------------|
| `dapr.io/enabled` | Setting this paramater to `true` injects the Dapr sidecar into the pod
| `dapr.io/app-port` | This parameter tells Dapr which port your application is listening on
| `dapr.io/app-id` | The unique ID of the application. Used for service discovery, state encapsulation and the pub/sub consumer ID

View File

@ -33,7 +33,7 @@ akswin000001 Ready agent 6d v1.17.9 10.240.0.
## Installing the Dapr Control Plane
If you are installing using the Dapr CLI or via a helm chart, simply follow the normal deployment procedures:
[Installing Dapr on a Kubernetes cluster](../../getting-started/environment-setup.md#installing-Dapr-on-a-kubernetes-cluster)
[Installing Dapr on a Kubernetes cluster]({{< ref "install-dapr.md#installing-Dapr-on-a-kubernetes-cluster" >}})
Affinity will be automatically set for kubernetes.io/os=linux. This will be sufficient for most users, as Kubernetes requires at least one Linux node pool.
@ -157,8 +157,8 @@ helm uninstall dapr
```
## Related links
- See the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/) for examples of more advanced configuration via node affinity
- [Get started: Prep Windows for containers](https://docs.microsoft.com/en-us/virtualization/windowscontainers/quick-start/set-up-environment)
- See the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/) for examples of more advanced configuration via node affinity
- [Get started: Prep Windows for containers](https://docs.microsoft.com/en-us/virtualization/windowscontainers/quick-start/set-up-environment)
- [Setting up a Windows enabled Kubernetes cluster on Azure AKS](https://docs.microsoft.com/en-us/azure/aks/windows-container-cli)
- [Setting up a Windows enabled Kubernetes cluster on AWS EKS](https://docs.aws.amazon.com/eks/latest/userguide/windows-support.html)
- [Setting up Windows on Google Cloud GKE](https://cloud.google.com/kubernetes-engine/docs/how-to/creating-a-cluster-windows)

View File

@ -7,7 +7,7 @@ description: "Overview of how to get Dapr running on your Kubernetes cluster"
Dapr can be configured to run on any [Kubernetes cluster](https://github.com/dapr/quickstarts/tree/master/hello-kubernetes). In Kubernetes the `dapr-sidecar-injector` and `dapr-operator` services provide first class integration to launch Dapr as a sidecar container in the same pod as the service container and provide notifications of Dapr component updates provisioned into the cluster. Additionally, the `dapr-sidecar-injector` also injects the environment variables `DAPR_HTTP_PORT` and `DAPR_GRPC_PORT` into **all** the containers in the pod to enable user defined applications to easily communicate with Dapr without hardcoding Dapr port values.
The `dapr-sentry` service is a certificate authority that enables mutual TLS between Dapr sidecar instances for secure data encryption. For more information on the `Sentry` service read the [security overview](../security/README.md#dapr-to-dapr-communication)
The `dapr-sentry` service is a certificate authority that enables mutual TLS between Dapr sidecar instances for secure data encryption. For more information on the `Sentry` service read the [security overview]({{< ref "security-concept.md" >}})
<img src="/images/overview_kubernetes.png" width=800>

View File

@ -13,14 +13,14 @@ The Dapr control plane pods are designed to be lightweight and require the follo
*Note: For more info on CPU and Memory resource units and their meaning, see [this](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) link*
| Deployment | CPU | Memory
| ------------| ---- | ------
| Operator | Limit: 1, Request: 100m | Limit: 200Mi, Request: 20Mi
|-------------|-----|-------
| Operator | Limit: 1, Request: 100m | Limit: 200Mi, Request: 20Mi
| Sidecar Injector | Limit: 1, Request: 100m | Limit: 200Mi, Request: 20Mi
| Sentry | Limit: 1, Request: 100m | Limit: 200Mi, Request: 20Mi
| Placement | Limit: 1, Request: 250m | Limit: 500Mi, Request: 100Mi
| Dashboard | Limit: 200m, Request: 50m | Limit: 200Mi, Request: 20Mi
| Sentry | Limit: 1, Request: 100m | Limit: 200Mi, Request: 20Mi
| Placement | Limit: 1, Request: 250m | Limit: 500Mi, Request: 100Mi
| Dashboard | Limit: 200m, Request: 50m | Limit: 200Mi, Request: 20Mi
To change the resource assignments for the Dapr sidecar, see the annotations [here](../configure-k8s/).
To change the resource assignments for the Dapr sidecar, see the annotations [here]({{< ref "kubernetes-annotations.md" >}}).
The specific annotations related to resource constraints are:
* `dapr.io/sidecar-cpu-limit`
@ -42,8 +42,8 @@ The following Dapr control plane deployments are optional:
The Dapr sidecar requires the following resources in a production-ready setup:
| CPU | Memory
| --------- | --------- |
| CPU | Memory |
|-----|--------|
| Limit: 4, Request: 100m | Limit: 4000Mi, Request: 250Mi
*Note: Since Dapr is intended to do much of the I/O heavy lifting for your app, it's expected that the resources given to Dapr enable you to drastically reduce the resource allocations for the application*
@ -53,7 +53,7 @@ The CPU and memory limits above account for the fact that Dapr is intended to do
## Deploying Dapr with Helm
When deploying to a production cluster, it's recommended to use Helm. The Dapr CLI installation into a Kubernetes cluster is for a development and test only setup.
You can find information [here](../../getting-started/environment-setup.md#using-helm-(advanced)) on how to deploy Dapr using Helm.
You can find information [here]({{< ref "install-dapr.md#using-helm-advanced" >}}) on how to deploy Dapr using Helm.
When deploying Dapr in a production-ready configuration, it's recommended to deploy with a highly available configuration of the control plane:
@ -63,7 +63,7 @@ helm install dapr dapr/dapr --namespace dapr-system --set global.ha.enabled=true
This command will run 3 replicas of each control plane pod with the exception of the Placement pod in the dapr-system namespace.
*Note: The Dapr Helm chart automatically deploys with affinity for nodes with the label `kubernetes.io/os=linux`. You can deploy the Dapr control plane to Windows nodes, but most users should not need to. For more information see [Deploying to a Hybrid Linux/Windows K8s Cluster](../windows-k8s/)*
*Note: The Dapr Helm chart automatically deploys with affinity for nodes with the label `kubernetes.io/os=linux`. You can deploy the Dapr control plane to Windows nodes, but most users should not need to. For more information see [Deploying to a Hybrid Linux/Windows K8s Cluster]({{< ref "kubernetes-hybrid-clusters.md" >}})*
## Upgrading Dapr with Helm
@ -73,7 +73,7 @@ Dapr supports zero downtime upgrades. The upgrade path includes the following st
2. Updating the Dapr control plane
3. Updating the data plane (Dapr sidecars)
### 1. Upgrading the CLI
### Upgrading the CLI
To upgrade the Dapr CLI, [download a release version](https://github.com/dapr/cli/releases) of the CLI that matches the Dapr runtime version.
For example, if upgrading to Dapr 0.9.0, download a CLI version of 0.9.x.
@ -198,24 +198,24 @@ Properly configured, Dapr not only be secured with regards to it's control plane
It is recommended that a production-ready deployment includes the following settings:
1. Mutual Authentication (mTLS) should be enabled. Note that Dapr has mTLS on by default. For details on how to bring your own certificates, see [here](../configure-mtls/README.md#bringing-your-own-certificates)
1. Mutual Authentication (mTLS) should be enabled. Note that Dapr has mTLS on by default. For details on how to bring your own certificates, see [here]({{< ref "mtls.md#bringing-your-own-certificates" >}})
2. Dapr API authentication is enabled (this is the between your application and the Dapr sidecar). To secure the Dapr API from unauthorized access, it is recommended to enable Dapr's token based auth. See [here](../enable-dapr-api-token-based-authentication/README.md) for details
2. Dapr API authentication is enabled (this is the between your application and the Dapr sidecar). To secure the Dapr API from unauthorized access, it is recommended to enable Dapr's token based auth. See [here]({{< ref "api-token.md" >}}) for details
3. All component YAMLs should have secret data configured in a secret store and not hard-coded in the YAML file. See [here](../../concepts/secrets/component-secrets.md) on how to use secrets with Dapr components
3. All component YAMLs should have secret data configured in a secret store and not hard-coded in the YAML file. See [here]({{< ref "component-secrets.md" >}}) on how to use secrets with Dapr components
4. The Dapr control plane is installed on a separate namespace such as `dapr-system`, and never into the `default` namespace
Dapr also supports scoping components for certain applications. This is not a required practice, and can be enabled according to your Sec-Ops needs. See [here](../components-scopes/README.md) for more info.
Dapr also supports scoping components for certain applications. This is not a required practice, and can be enabled according to your Sec-Ops needs. See [here]({{< ref "component-scopes.md" >}}) for more info.
## Tracing and metrics configuration
Dapr has tracing and metrics enabled by default.
To configure a tracing backend for Dapr visit [this](../diagnose-with-tracing) link.
To configure a tracing backend for Dapr visit [this]({{< ref "setup-tracing.md" >}}) link.
For metrics, Dapr exposes a Prometheus endpoint listening on port 9090 which can be scraped by Prometheus.
It is *recommended* that you set up distributed tracing and metrics for your applications and the Dapr control plane in production.
If you already have your own observability set-up, you can disable tracing and metrics for Dapr.
To setup Prometheus, Grafana and other monitoring tools with Dapr, visit [this](../setup-monitoring-tools) link.
To setup Prometheus, Grafana and other monitoring tools with Dapr, visit [this]({{< ref "monitoring" >}}) link.

View File

@ -19,9 +19,9 @@ The Dapr CLI provides an option to initialize Dapr using slim init, without the
dapr init --slim
```
In this mode two different binaries are installed `daprd` and `placement`. The `placement` binary is needed to enable [actors](../../concepts/actors/README.md) in a Dapr self-hosted installation.
In this mode two different binaries are installed `daprd` and `placement`. The `placement` binary is needed to enable [actors]({{< ref "actors-overview.md" >}}) in a Dapr self-hosted installation.
In this mode no default components such as Redis are installed for state management or pub/sub. This means, that aside from [Service Invocation](../../concepts/service-invocation/README.md), no other building block functionality is available on install out of the box. Users are free to setup their own environment and custom components. Furthermore, actor based service invocation is possible if a state store is configured as explained in the following sections.
In this mode no default components such as Redis are installed for state management or pub/sub. This means, that aside from [Service Invocation]({{< ref "service-invocation-overview.md" >}}), no other building block functionality is available on install out of the box. Users are free to setup their own environment and custom components. Furthermore, actor based service invocation is possible if a state store is configured as explained in the following sections.
## Service invocation
See [this sample](https://github.com/dapr/samples/tree/master/hello-dapr-slim) for an example on how to perform service invocation in this mode.
@ -65,4 +65,4 @@ INFO[0450] host removed: 192.168.1.6 instance=host.localhost
## Cleanup
Follow the uninstall [instructions](../../getting-started/environment-setup.md#Uninstall-Dapr-in-self-hosted-mode-(without-docker)) to remove the binaries.
Follow the uninstall [instructions]({{< ref "install-dapr.md#uninstall-dapr-in-a-self-hosted-mode" >}}) to remove the binaries.

View File

@ -9,7 +9,7 @@ Dapr can be configured to run on your local developer machine in self hosted mod
In self hosted mode, Redis is running locally in a container and is configured to serve as both the default component for state store and for pub/sub. A Zipkin container is also configured for diagnostics and tracing. After running `dapr init`, see the `$HOME/.dapr/components` directory (Mac/Linux) or `%USERPROFILE%\.dapr\components` on Windows.
The `dapr-placement` service is responsible for managing the actor distribution scheme and key range settings. This service is only required if you are using Dapr actors. For more information on the actor `Placement` service read [actor overview](../actors).
The `dapr-placement` service is responsible for managing the actor distribution scheme and key range settings. This service is only required if you are using Dapr actors. For more information on the actor `Placement` service read [actor overview]({{< ref "actors-overview.md" >}}).
<img src="/images/overview_standalone.png" width=800>

View File

@ -5,7 +5,6 @@ weight: 20000
description: "How to deploy and run Dapr in self-hosted mode using Docker"
---
# Run with Docker
This article provides guidance on running Dapr with Docker outside of Kubernetes. There are a number of different configurations in which you may wish to run Dapr with Docker that are documented below.
## Prerequisites
@ -35,7 +34,7 @@ There are published Docker images for each of the Dapr components available on [
- `major.minor.patch-arm`: A release version for ARM.
- `major.minor.patch-rc.iteration-arm`: A release candidate for ARM.
## Run Dapr in a Docker container with an app as a process
## Run app as a process
> For development purposes ONLY
If you are running Dapr in a Docker container and your app as a process on the host machine, then you need to configure
@ -49,7 +48,7 @@ Then you can run your app on the host and they should connect over the localhost
However, if you are not running your Docker daemon on a Linux host, it is recommended you follow the steps below to run
both your app and the [Dapr runtime in Docker containers using Docker Compose](#run-dapr-in-a-docker-container-using-docker-compose).
## Run Dapr and an app in a single Docker container
## Run app and Dapr in a single Docker container
> For development purposes ONLY
It is not recommended to run both the Dapr runtime and an application inside the same container. However, it is possible to do so for local development scenarios.
@ -78,7 +77,7 @@ CMD ["run", "--app-id", "nodeapp", "--app-port", "3000", "node", "app.js"]
Remember that if Dapr needs to communicate with other components i.e. Redis, these also need to
be made accessible to it.
## Run Dapr in a Docker container on a Docker network
## Run on a Docker network
If you have multiple instances of Dapr running in Docker containers and want them to be able to
communicate with each other i.e. for service invocation, then you'll need to create a shared Docker network
and make sure those Dapr containers are attached to it.
@ -93,7 +92,7 @@ docker run --net=my-dapr-network ...
```
Each container will receive a unique IP on that network and be able to communicate with other containers on that network.
## Run Dapr in a Docker container using Docker-Compose
## Run using Docker-Compose
[Docker Compose](https://docs.docker.com/compose/) can be used to define multi-container application
configurations. If you wish to run multiple apps with Dapr sidecars locally without Kubernetes then it is recommended to use a Docker Compose definition (`docker-compose.yml`).
@ -142,14 +141,8 @@ services:
To further learn how to run Dapr with Docker Compose, see the [Docker-Compose Sample](https://github.com/dapr/samples/tree/master/hello-docker-compose).
## Run Dapr in a Docker container on Kubernetes
## Run on Kubernetes
If your deployment target is Kubernetes then you're probably better of running your applicaiton and Dapr sidecars directly on
a Kubernetes platform. Running Dapr on Kubernetes is a first class experience and is documented separately. Please refer to the
following references:
- [Setup Dapr on a Kubernetes cluster](https://github.com/dapr/docs/blob/ea5b1918778a47555dbdccff0ed6c5b987ed10cf/getting-started/environment-setup.md#installing-dapr-on-a-kubernetes-cluster)
- [Hello Kubernetes Sample](https://github.com/dapr/quickstarts/tree/master/hello-kubernetes)
- [Configuring the Dapr sidecar on Kubernetes](https://github.com/dapr/docs/blob/c88d247a2611d6824d41bb5b6adfeb38152dbbc6/howto/configure-k8s/README.md)
- [Running Dapr in Kubernetes mode](https://github.com/dapr/docs/blob/a7668cab5e16d12f364a42d2fe7d75933c6398e9/overview/README.md#running-dapr-in-kubernetes-mode)
[Dapr on Kubernetes docs]({{< ref "kubernetes-overview.md" >}})
## Related links
- [Docker-Compose Sample](https://github.com/dapr/samples/hello-docker-compose)

View File

@ -12,12 +12,6 @@ description: "Enable Dapr metrics and logs with Azure Monitor for Azure Kubernet
- [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/)
- [Helm 3](https://helm.sh/)
## Contents
- [Enable Prometheus metric scrape using config map](#enable-prometheus-metric-scrape-using-config-map)
- [Install Dapr with JSON formatted logs](#install-dapr-with-json-formatted-logs)
- [Search metrics and logs with Azure Monitor](#Search-metrics-and-logs-with-azure-monitor)
## Enable Prometheus metric scrape using config map
1. Make sure that omsagnets are running
@ -35,9 +29,9 @@ omsagent-smtk7 1/1 Runnin
2. Apply config map to enable Prometheus metrics endpoint scrape.
You can use [azm-config-map.yaml](./azm-config-map.yaml) to enable prometheus metrics endpoint scrape.
You can use [azm-config-map.yaml](/docs/azm-config-map.yaml) to enable prometheus metrics endpoint scrape.
If you installed Dapr to the different namespace, you need to change the `monitor_kubernetes_pod_namespaces` array values. For example;
If you installed Dapr to the different namespace, you need to change the `monitor_kubernetes_pod_namespaces` array values. For example:
```yaml
...
@ -53,7 +47,7 @@ If you installed Dapr to the different namespace, you need to change the `monito
Apply config map:
```
```bash
kubectl apply -f ./azm-config.map.yaml
```

View File

@ -11,33 +11,27 @@ description: "How to install Fluentd, Elastic Search, and Kibana to search logs
- [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/)
- [Helm 3](https://helm.sh/)
## Contents
- [Install Fluentd, Elastic Search, and Kibana](#install-fluentd-elastic-search-and-kibana)
- [Install Fluentd](#install-fluentd)
- [Install Dapr with JSON formatted logs](#install-dapr-with-json-formatted-logs)
- [Search logs](#search-logs)
## Install Elastic search and Kibana
1. Create namespace for monitoring tool and add Helm repo for Elastic Search
```bash
kubectl create namespace dapr-monitoring
```
```bash
kubectl create namespace dapr-monitoring
```
2. Add Elastic helm repo
```bash
helm repo add elastic https://helm.elastic.co
helm repo update
```
```bash
helm repo add elastic https://helm.elastic.co
helm repo update
```
3. Install Elastic Search using Helm
By default the chart creates 3 replicas which must be on different nodes. If your cluster has less than 3 nodes, specify a lower number of replicas. For example, this sets it to 1:
```
```bash
helm install elasticsearch elastic/elasticsearch -n dapr-monitoring --set replicas=1
```
@ -47,40 +41,41 @@ Otherwise:
helm install elasticsearch elastic/elasticsearch -n dapr-monitoring
```
If you are using minikube or want to disable persistent volumes for development purposes, you can disable it by using the following command.
If you are using minikube or want to disable persistent volumes for development purposes, you can disable it by using the following command:
```bash
helm install elasticsearch elastic/elasticsearch -n dapr-monitoring --set persistence.enabled=false --replicas=1
```
4. Install Kibana
```bash
helm install kibana elastic/kibana -n dapr-monitoring
```
```bash
helm install kibana elastic/kibana -n dapr-monitoring
```
5. Validation
Ensure Elastic Search and Kibana are running in your Kubernetes cluster.
```bash
kubectl get pods -n dapr-monitoring
NAME READY STATUS RESTARTS AGE
elasticsearch-master-0 1/1 Running 0 6m58s
kibana-kibana-95bc54b89-zqdrk 1/1 Running 0 4m21s
```
Ensure Elastic Search and Kibana are running in your Kubernetes cluster.
```bash
kubectl get pods -n dapr-monitoring
NAME READY STATUS RESTARTS AGE
elasticsearch-master-0 1/1 Running 0 6m58s
kibana-kibana-95bc54b89-zqdrk 1/1 Running 0 4m21s
```
## Install Fluentd
1. Install config map and Fluentd as a daemonset
Navigate to the following path if you're not already there (the one this document is in):
```
docs/howto/setup-monitoring-tools
```
Download these config files:
- [fluentd-config-map.yaml](/docs/fluentd-config-map.yaml)
- [fluentd-dapr-with-rbac.yaml](/docs/fluentd-dapr-with-rbac.yaml)
> Note: If you already have Fluentd running in your cluster, please enable the nested json parser to parse JSON formatted log from Dapr.
Apply the configurations to your cluster:
```bash
kubectl apply -f ./fluentd-config-map.yaml
kubectl apply -f ./fluentd-dapr-with-rbac.yaml
@ -102,11 +97,11 @@ fluentd-sdrld 1/1 Running 0 14s
1. Install Dapr with enabling JSON-formatted logs
```bash
helm repo add dapr https://dapr.github.io/helm-charts/
helm repo update
helm install dapr dapr/dapr --namespace dapr-system --set global.logAsJson=true
```
```bash
helm repo add dapr https://dapr.github.io/helm-charts/
helm repo update
helm install dapr dapr/dapr --namespace dapr-system --set global.logAsJson=true
```
2. Enable JSON formatted log in Dapr sidecar
@ -155,37 +150,37 @@ Handling connection for 5601
3. Click Management -> Index Management
![kibana management](./img/kibana-1.png)
![kibana management](/images/kibana-1.png)
4. Wait until dapr-* is indexed.
![index log](./img/kibana-2.png)
![index log](/images/kibana-2.png)
5. Once dapr-* indexed, click Kibana->Index Patterns and Create Index Pattern
![create index pattern](./img/kibana-3.png)
![create index pattern](/images/kibana-3.png)
6. Define index pattern - type `dapr*` in index pattern
![define index pattern](./img/kibana-4.png)
![define index pattern](/images/kibana-4.png)
7. Select time stamp filed: `@timestamp`
![timestamp](./img/kibana-5.png)
![timestamp](/images/kibana-5.png)
8. Confirm that `scope`, `type`, `app_id`, `level`, etc are being indexed.
> Note: if you cannot find the indexed field, please wait. it depends on the volume of data and resource size where elastic search is running.
![indexing](./img/kibana-6.png)
![indexing](/images/kibana-6.png)
9. Click `discover` icon and search `scope:*`
> Note: it would take some time to make log searchable based on the data volume and resource.
![discover](./img/kibana-7.png)
![discover](/images/kibana-7.png)
# References
## References
* [Fluentd for Kubernetes](https://docs.fluentd.org/v/0.12/articles/kubernetes-fluentd)
* [Elastic search helm chart](https://github.com/elastic/helm-charts/tree/master/elasticsearch)

View File

@ -1,6 +1,6 @@
---
title: "Enable API token based authentication"
linkTitle: "API Token Auth"
linkTitle: "API token auth"
weight: 3000
description: "Require every incoming API request to include an authentication token before allowing that request to pass through"
---

View File

@ -9,7 +9,7 @@ Dapr supports in-transit encryption of communication between Dapr instances usin
Dapr allows operators and developers to bring in their own certificates, or let Dapr automatically create and persist self signed root and issuer certificates.
For detailed information on mTLS, go to the concepts section [here](../../concepts/security/README.md).
For detailed information on mTLS, go to the concepts section [here]({{< ref "security-concept.md" >}}).
If custom certificates have not been provided, Dapr will automatically create and persist self signed certs valid for one year.
In Kubernetes, the certs are persisted to a secret that resides in the namespace of the Dapr system pods, accessible only to them.

View File

@ -5,7 +5,7 @@ weight: 2000
description: "Enable OAUTH authorization on Dapr endpoints for your web APIs"
---
Dapr OAuth 2.0 [middleware](../../concepts/middleware/README.md) allows you to enable [OAuth](https://oauth.net/2/) authorization on Dapr endpoints for your web APIs using the [Authorization Code Grant flow](https://tools.ietf.org/html/rfc6749#section-4.1).
Dapr OAuth 2.0 [middleware]({{< ref "middleware-concept.md" >}}) allows you to enable [OAuth](https://oauth.net/2/) authorization on Dapr endpoints for your web APIs using the [Authorization Code Grant flow](https://tools.ietf.org/html/rfc6749#section-4.1).
You can also inject authorization tokens into your APIs which can be used for authorization towards external APIs called by your APIs using the [Client Credentials Grant flow](https://tools.ietf.org/html/rfc6749#section-4.4).
When the middleware is enabled any method invocation through Dapr needs to be authorized before getting passed to the user code.
@ -73,8 +73,8 @@ spec:
### Define a custom pipeline for an Authorization Code Grant
To use the OAuth middleware (Authorization Code), you should create a [custom pipeline](../../concepts/middleware/README.md)
using [Dapr configuration](../../concepts/configuration/README.md), as shown in the following sample:
To use the OAuth middleware (Authorization Code), you should create a [custom pipeline]({{< ref "middleware-concept.md" >}})
using [Dapr configuration]({{< ref "configuration-overview" >}}), as shown in the following sample:
```yaml
apiVersion: dapr.io/v1alpha1
@ -130,8 +130,8 @@ spec:
### Define a custom pipeline for a Client Credentials Grant
To use the OAuth middleware (Client Credentials), you should create a [custom pipeline](../../concepts/middleware/README.md)
using [Dapr configuration](../../concepts/configuration/README.md), as shown in the following sample:
To use the OAuth middleware (Client Credentials), you should create a [custom pipeline]({{< ref "middleware-concept.md" >}})
using [Dapr configuration]({{< ref "configuration-overview.md" >}}), as shown in the following sample:
```yaml
apiVersion: dapr.io/v1alpha1

View File

@ -81,11 +81,11 @@ The most common cause of this failure is that a component (such as a state store
To diagnose the root cause:
- Significantly increase the liveness probe delay - [link](../../howto/configure-k8s/README.md)
- Set the log level of the sidecar to debug - [link](./logs.md#setting-the-sidecar-log-level)
- Watch the logs for meaningful information - [link](./logs.md#viewing-logs-on-kubernetes)
- Significantly increase the liveness probe delay - [link]{{< ref "kubernetes-overview.md" >}})
- Set the log level of the sidecar to debug - [link]({{< ref "logs.md#setting-the-sidecar-log-level" >}})
- Watch the logs for meaningful information - [link]({{< ref "logs.md#viewing-logs-on-kubernetes" >}})
> :bulb: Remember to configure the liveness check delay and log level back to your desired values after solving the problem.
> Remember to configure the liveness check delay and log level back to your desired values after solving the problem.
## I am unable to save state or get state
@ -98,7 +98,7 @@ kubectl get components
```
If there isn't a state store component, it means you need to set one up.
Visit [here](../../howto/setup-state-store/setup-redis.md) for more details.
Visit [here]({{< ref "state-management" >}}) for more details.
If everything's set up correctly, make sure you got the credentials right.
Search the Dapr runtime logs and look for any state store errors:
@ -118,7 +118,7 @@ kubectl get components
```
If there isn't a pub/sub component, it means you need to set one up.
Visit [here](../../howto/setup-pub-sub-message-broker/README.md) for more details.
Visit [here]({{< ref "pubsub" >}}) for more details.
If everything is set up correctly, make sure you got the credentials right.
Search the Dapr runtime logs and look for any pub/sub errors:
@ -150,26 +150,26 @@ kubectl logs <name-of-pod> daprd
## I'm getting 404 Not Found responses when calling Dapr
This means you're trying to call an Dapr API endpoint that either doesn't exist or the URL is malformed.
Look at the Dapr API reference [here](../../reference/api/README.md) and make sure you're calling the right endpoint.
Look at the Dapr API reference [here]({{< ref "api" >}}) and make sure you're calling the right endpoint.
## I don't see any incoming events or calls from other services
Have you specified the port your app is listening on?
In Kubernetes, make sure the `dapr.io/app-port` annotation is specified:
<pre>
```yaml
annotations:
dapr.io/enabled: "true"
dapr.io/app-id: "nodeapp"
<b>dapr.io/app-port: "3000"</b>
</pre>
dapr.io/app-port: "3000"
```
If using Dapr Standalone and the Dapr CLI, make sure you pass the `--app-port` flag to the `dapr run` command.
## My Dapr-enabled app isn't behaving correctly
The first thing to do is inspect the HTTP error code returned from the Dapr API, if any.
If you still can't find the issue, try enabling `debug` log levels for the Dapr runtime. See [here](logs.md) how to do so.
If you still can't find the issue, try enabling `debug` log levels for the Dapr runtime. See [here]({{< ref "logs.md" >}}) how to do so.
You might also want to look at error logs from your own process. If running on Kubernetes, find the pod containing your app, and execute the following:

View File

@ -1,4 +1,7 @@
# Dapr API reference
---
title: Dapr API reference
linkTitle: "Dapr API"
---
Dapr is language agnostic and provides a RESTful HTTP & gRPC API.

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.9 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 5.8 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 798 B

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.3 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.7 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.7 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 4.8 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 423 B

Binary file not shown.

After

Width:  |  Height:  |  Size: 923 B

Binary file not shown.

Before

Width:  |  Height:  |  Size: 1.1 KiB

After

Width:  |  Height:  |  Size: 1.1 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 8.5 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 13 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 17 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.7 KiB