taking latest from hugo-docs branch

OLD/overview/README.md

@@ -1 +0,0 @@
-

daprdocs/content/en/docs/concepts/configuration-concept.md

@@ -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.

daprdocs/content/en/docs/concepts/configuration.md

@@ -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)

daprdocs/content/en/docs/operations/components/component-scopes.md

@@ -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>

daprdocs/content/en/docs/operations/components/component-secrets.md

@@ -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
 

daprdocs/content/en/docs/operations/configuration/configuration-overview.md

@@ -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
+```

daprdocs/content/en/docs/operations/configuration/control-concurrency.md

@@ -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"
 ---
 

daprdocs/content/en/docs/operations/configuration/grpc.md

@@ -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"
 ---
 

daprdocs/content/en/docs/operations/configuration/invoke-allowlist.md

@@ -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)

daprdocs/content/en/docs/operations/configuration/secret-scope.md

@@ -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.

daprdocs/content/en/docs/operations/hosting/_index.md

@@ -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."
 ---

daprdocs/content/en/docs/operations/hosting/kubernetes/kubernetes-annotations.md

@@ -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

daprdocs/content/en/docs/operations/hosting/kubernetes/kubernetes-hybrid-clusters.md

@@ -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)

daprdocs/content/en/docs/operations/hosting/kubernetes/kubernetes-overview.md

@@ -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>
 

daprdocs/content/en/docs/operations/hosting/kubernetes/kubernetes-production.md

@@ -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.

daprdocs/content/en/docs/operations/hosting/self-hosted/self-hosted-no-docker.md

@@ -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.

daprdocs/content/en/docs/operations/hosting/self-hosted/self-hosted-overview.md

@@ -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>
 

daprdocs/content/en/docs/operations/hosting/self-hosted/self-hosted-with-docker.md

@@ -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)

daprdocs/content/en/docs/operations/monitoring/azure-monitor.md

@@ -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
 ```
 

daprdocs/content/en/docs/operations/monitoring/fluentd.md

@@ -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.
+    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
-```
+    ```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)

daprdocs/content/en/docs/operations/security/api-token.md

@@ -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"
 ---

daprdocs/content/en/docs/operations/security/mtls.md

@@ -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.

daprdocs/content/en/docs/operations/security/oauth.md

@@ -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

daprdocs/content/en/docs/operations/troubleshooting/common_issues.md

@@ -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:
 

daprdocs/content/en/docs/reference/api/_index.md

@@ -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.