Merge branch 'v1.6' into v1.7

Signed-off-by: Nick Greenfield <nigreenf@microsoft.com>

daprdocs/content/en/concepts/security-concept.md

@@ -3,60 +3,83 @@ type: docs
 title: "Security"
 linkTitle: "Security"
 weight: 600
-description: >
-  How Dapr is designed with security in mind
+description: How Dapr is designed with security in mind
 ---
 
-This article addresses multiple security considerations when using Dapr in a distributed application including:
+Security is fundamental to Dapr. This article describes the security features and capabiliies when using Dapr in a distributed application. These can be divided into:
 
-Several of the areas above are addressed through encryption of data in transit. One of the security mechanisms that Dapr employs for encrypting data in transit is [mutual authentication TLS](https://en.wikipedia.org/wiki/Mutual_authentication) or mTLS. mTLS offers a few key features for network traffic inside your application:
+- Secure communication with service invocation and pub/sub APIs
+- Security policies on components and applied through configuration.
+- Operational security practices.
+- State security, focusing on data at rest.
 
-- Two way authentication - the client proving its identity to the server, and vice-versa
+An example application is used to illustrate many of the security features available in Dapr.
+
+# Secure communication
+Dapr has end-to-end security with the service invocation API, the ability to authentication an application with Dapr and the to set endpoint access policies. This is shown in the diagram below.
+
+<img src="/images/security-end-to-end-communication.png" width=1000>
+
+## Service invocation scoping access policy
+Dapr applications can be scoped to namespaces for deployment and security and you can call between services deployed to different namespaces. Read the [Service invocation across namespaces]({{< ref "service-invocation-namespaces.md" >}}) for more details.
+
+Dapr applications can restrict which operations can be called, including which applications are allowed (or denied) to call it. Read [How-To: Apply access control list configuration for service invocation]({{<ref "invoke-allowlist.md">}}) for more details.
+
+## Pub/Sub topic scoping access policy
+For pub/sub components you can limit which topic types and which applications are allowed to published and subscribed to specific topics. Read [Scope Pub/Sub topic access]({{< ref "pubsub-scopes.md" >}}) for more details.
+
+## Encryption of data using mTLS
+One of the security mechanisms that Dapr employs for encrypting data in transit is [mutual authentication TLS](https://en.wikipedia.org/wiki/Mutual_authentication) or mTLS. mTLS offers a few key features for network traffic inside your application:
+
+- Two way authentication, the client proving its identity to the server, and vice-versa
 - An encrypted channel for all in-flight communication, after two-way authentication is established
 
 Mutual TLS is useful in almost all scenarios, but especially so for systems subject to regulations such as [HIPAA](https://en.wikipedia.org/wiki/Health_Insurance_Portability_and_Accountability_Act) and [PCI](https://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard).
 
-Dapr enables mTLS and all the features described in this document in your application with little to no extra code or complex configuration inside your production systems
+## Secure Dapr to Dapr communication
+Dapr enables mTLS with no extra code or complex configuration inside your production systems. Equally Dapr side cars prevent all IP addresses by default other than localhost from calling it, unless explicitly listed.
 
-## Sidecar-to-app communication
+Dapr includes an "on by default", automatic mutual TLS that provides in-transit encryption for traffic between Dapr sidecars. To achieve this, Dapr leverages a system service named `Sentry` which acts as a Certificate Authority (CA)/Identity Provider and signs workload (app) certificate requests originating from the Dapr sidecar.
 
-The Dapr sidecar runs close to the application through **localhost**, and is recommended to run under the same network boundary as the app. While many cloud-native systems today consider the pod level (on Kubernetes, for example) as a trusted security boundary, Dapr provides the user with API level authentication using tokens. This feature guarantees that even on localhost, only an authenticated caller may call into Dapr.
+By default, a workload cert is valid for 24 hours and the clock skew is set to 15 minutes.
 
-## Sidecar-to-sidecar communication
-
-Dapr includes an "on by default", automatic mutual TLS that provides in-transit encryption for traffic between Dapr sidecars.
-To achieve this, Dapr leverages a system service named `Sentry` which acts as a Certificate Authority (CA) and signs workload (app) certificate requests originating from the Dapr sidecar.
-
-Dapr also manages workload certificate rotation, and does so with zero downtime to the application.
-
-Sentry, the CA service, automatically creates and persists self-signed root certificates valid for one year, unless existing root certs have been provided by the user.
+The Sentry service, automatically creates and persists self-signed root certificates valid for one year, unless existing root certs have been provided by the user. Dapr manages workload certificate rotation, and if you bring your own certificates, does so with zero downtime to the application. 
 
 When root certs are replaced (secret in Kubernetes mode and filesystem for self-hosted mode), the Sentry picks them up and rebuilds the trust chain without needing to restart, with zero downtime to Sentry.
 
 When a new Dapr sidecar initializes, it first checks if mTLS is enabled. If it is, an ECDSA private key and certificate signing request are generated and sent to Sentry via a gRPC interface. The communication between the Dapr sidecar and Sentry is authenticated using the trust chain cert, which is injected into each Dapr instance by the Dapr Sidecar Injector system service.
 
-In a Kubernetes cluster, the secret that holds the root certificates is scoped to the namespace in which the Dapr components are deployed and is only accessible by the Dapr system pods.
-
-Dapr also supports strong identities when deployed on Kubernetes, relying on a pod's Service Account token which is sent as part of the certificate signing request (CSR) to Sentry.
-
-By default, a workload cert is valid for 24 hours and the clock skew is set to 15 minutes.
-
+### Configuring mTLS
 Mutual TLS can be turned off/on by editing the default configuration that is deployed with Dapr via the `spec.mtls.enabled` field.
+
 This can be done for both Kubernetes and self-hosted modes. Details for how to do this can be found [here]({{< ref mtls.md >}}).
 
-### mTLS self hosted
-The diagram below shows how the Sentry system service issues certificates for applications based on the root/issuer certificate that is provided by an operator or generated by the Sentry service as stored in a file
+#### mTLS in self hosted mode
+The diagram below shows how the Sentry system service issues certificates for applications based on the root/issuer certificate that is provided by an operator or generated by the Sentry service as stored in a file.
 
 <img src="/images/security-mTLS-sentry-selfhosted.png" width=1000>
 
-### mTLS in Kubernetes
+#### mTLS in Kubernetes mode
+In a Kubernetes cluster, the secret that holds the root certificates is scoped to the namespace in which the Dapr components are deployed and is only accessible by the Dapr control plane system pods.
+
+Dapr also supports strong identities when deployed on Kubernetes, relying on a pod's Service Account token which is sent as part of the certificate signing request (CSR) to Sentry.
+
 The diagram below shows how the Sentry system service issues certificates for applications based on the root/issuer certificate that is provided by an operator or generated by the Sentry service and stored as a Kubernetes secret
 
 <img src="/images/security-mTLS-sentry-kubernetes.png" width=1000>
 
-## Sidecar to system services communication
+### Preventing IP addresses on Dapr
+To prevent Dapr side cars from being called on any IP address especially in production environments such as Kubernetes, Dapr restricts its listening IP addresses to only local host. Before the v1.4 release any Dapr sidecar could call any other sidecar in a cluster by default. This is no longer possible and needs to be enabled explicitly. Use the [dapr-listen-addresses](https://docs.dapr.io/reference/arguments-annotations-overview/) setting if there are other addresses you need to enable.
 
-In addition to automatic mTLS between Dapr sidecars, Dapr offers mandatory mTLS between the Dapr sidecar and the Dapr system services, namely the Sentry service (Certificate Authority), Placement service (actor placement) and the Kubernetes Operator.
+## Secure Dapr to application communication
+The Dapr sidecar runs close to the application through **localhost**, and is recommended to run under the same network boundary as the app. While many cloud-native systems today consider the pod level (on Kubernetes, for example) as a trusted security boundary, Dapr provides the app with API level authentication using tokens. This feature guarantees that even on localhost, only an authenticated application may call into Dapr and equally an application can check that Dpar is calling it back. For more details on configuring API token security read,
+
+- [Using an API token to authentication requests from an application to Dapr]({{< ref api-token.md >}}).
+- [Using an API token to authentication requests from Dapr to the application]({{< ref app-api-token.md >}})
+
+## Secure Dapr to control plane communication
+
+In addition to automatic mTLS between Dapr sidecars, Dapr offers mandatory mTLS between the Dapr sidecar and the Dapr control plane system services, namely the Sentry service (a Certificate Authority), the Placement service (actor placement) and the Kubernetes Operator service.
 
 When mTLS is enabled, Sentry writes the root and issuer certificates to a Kubernetes secret that is scoped to the namespace where the control plane is installed. In self-hosted mode, Sentry writes the certificates to a configurable file system path.
 
@@ -70,38 +93,73 @@ When the Dapr sidecar initializes, it authenticates with the system pods using t
 The diagram below shows secure communication between the Dapr sidecar and the Dapr Sentry (Certificate Authority), Placement (actor placement) and the Kubernetes Operator system services
 
 <img src="/images/security-mTLS-dapr-system-services.png" width=1000>
+</br>
 
-## Component namespace scopes and secrets
 
-Dapr components are namespaced. That means a Dapr runtime sidecar instance can only access the components that have been deployed to the same namespace. See the [components scope documentation]({{<ref "component-scopes.md">}}) for more details.
+# Operational Security 
+Dapr is designed for operators to manage mTLS certificate and enforce OAuth policies.
 
-Dapr components uses Dapr's built-in secret management capability to manage secrets. See the [secret store overview]({{<ref "secrets-overview.md">}}) for more details.
+## mTLS Certificate deployment and rotation
+Dapr allows operators and developers to bring in their own certificates, or instead let Dapr automatically create and persist self-signed root and issuer certificates. Read [Setup & configure mTLS certificates]({{<ref "mtls.md">}}) for more details.
 
-In addition, Dapr offers application-level scoping for components by allowing users to specify which applications can consume given components. For more information about application level scoping, see [here]({{<ref "component-scopes.md#application-access-to-components-with-scopes">}}).
+## Middleware endpoint authorization with OAuth
+Dapr OAuth 2.0 middleware allows you to enable OAuth authorization on Dapr endpoints for your APIs. Read [Configure endpoint authorization with OAuth]({{<ref "oauth.md">}}) for details. Dapr has other middleware components that can be used for OpenID Connect and OPA Policies which you can [read about]({{<ref "supported-middleware.md">}}) for more details.
 
 ## Network security
-
 You can adopt common network security technologies such as network security groups (NSGs), demilitarized zones (DMZs) and firewalls to provide layers of protection over your networked resources. For example, unless configured to talk to an external binding target, Dapr sidecars don’t open connections to the internet. And most binding implementations use outbound connections only. You can design your firewall rules to allow outbound connections only through designated ports.
 
-## Bindings security
+# Security policies
+Dapr has an extensive set of security policies that can be applied to your applications to scope what they are able to do either through a policy setting in the sidecar configuration or with the component specification. 
 
+## API access policy
+In certain scenarios such as zero trust networks or when exposing the Dapr sidecar to external traffic through a frontend, it’s recommended to only enable the Dapr sidecar APIs that are being used by the app. Doing so reduces the attack surface and helps keep the Dapr APIs scoped to the actual needs of the application. You can control which APIs are accessible to the application by setting an API allow list in configuration, as shown in the diagram below.
+
+<img src="/images/security-dapr-API-scoping.png" width=1000>
+
+Read [How-To: Selectively enable Dapr APIs on the Dapr sidecar]({{<ref "api-allowlist.md">}}) for more details.
+
+## Secret scoping access policy
+To limit the secrets to which the Dapr application has access to, you can define secret scopes by adding a secret scope policy to the application configuration with restrictive permissions. Read [How To: Use secret scoping]({{<ref "secret-scope.md">}}) for more details.
+
+## Component application scoping access policy and secret usage 
+Dapr components can be namespaced. That means a Dapr sidecar instance can only access the components that have been deployed to the same namespace. Read [How-To: Scope components to one or more applications using namespaces]({{<ref "component-scopes.md">}}) for more details.
+
+Dapr provides application-level scoping for components by allowing you to specify which applications can consume specific components and deny others. Read [restricting application access to components with scopes]({{<ref "component-scopes.md#application-access-to-components-with-scopes">}}) for more details.
+
+Dapr components can use Dapr's built-in secret management capability to manage secrets. Read the [secret store overview]({{<ref "secrets-overview.md">}}) and [How-To: Reference secrets in components]({{<ref "component-secrets.md">}}) for more details.
+
+## Bindings security
 Authentication with a binding target is configured by the binding’s configuration file. Generally, you should configure the minimum required access rights. For example, if you only read from a binding target, you should configure the binding to use an account with read-only access rights.
 
-## State store security
+# State security
 
-Dapr doesn't transform the state data from applications. This means Dapr doesn't attempt to encrypt/decrypt state data. However, your application can adopt encryption/decryption methods of your choice, and the state data remains opaque to Dapr.
+## State store encrytion at rest
+By default Dapr doesn't transform the state data from applications. This means Dapr doesn't attempt to encrypt/decrypt state data and your application can adopt encryption/decryption methods of your choice, where the state data remains opaque to Dapr. Dapr components can use a configured authentication method to authenticate with the underlying state store. Many state store implementations use official client libraries that generally use secured communication channels with the servers.
 
-Dapr does not store any data at rest.
+However application state often needs to get encrypted at rest to provide stronger security in enterprise workloads or regulated environments and Dapr does provide automatic client side state encryption based on AES256. Read [How-To: Encrypt application state]({{< ref howto-encrypt-state.md >}}) for more details.
 
-Dapr uses the configured authentication method to authenticate with the underlying state store. Many state store implementations use official client libraries that generally use secured communication channels with the servers.
+## Dapr Runtrime state
+Importantly the Dapr runtime does not store any data at rest, meaning that Dapr runtime has no dependency on any state stores for its operation and can be considered stateless.
 
-## Management security
+# Using security capabilies in an example application
+The diagram below shows a number of the security capabilities put together into an example application hosted on Kubernetes. You can see that the Dapr control plane, the Redis state store and each of the services have been deployed to their own namespaces. Also when deploying on Kubernetes, you can use regular Kubernetes RBAC to control access to management activities.
 
-When deploying on Kubernetes, you can use regular [Kubernetes RBAC]( https://kubernetes.io/docs/reference/access-authn-authz/rbac/) to control access to management activities.
+In the application, requests are received by the ingress reverse-proxy which has a Dapr sidecar running next to it. From the reverse proxy, Dapr uses service invocation to call onto service A which then publishes a message to Serivce B. Service B retrieves a secret in order to read and save state to a Redis state store. 
 
-When deploying on Azure Kubernetes Service (AKS), you can use [Azure Active Directory (AD) service principals]( https://docs.microsoft.com/azure/active-directory/develop/app-objects-and-service-principals) to control access to management activities and resource management.
+<img src="/images/security-overview-capabilities-example.png" width=1000>
 
-## Threat model
+Let's go over each of the security capabilities and describe how they are protecting this application.
+
+1. API Token authentication is used to ensure the the reverse-proxy knows it is communication with the correct Dapr sidecar instance. This prevents it forwarding message to anything expect this Dapr side car. 
+2. Service invocation mTLS is used for authentication between the reverse proxy and Service A and a in addition service access policy configured on Service A restricts it to only receive calls on a specific endpoint from the reverse proxy and no other services. 
+3. Service B uses a pub/sub topic security policy to indicate that it can only receive messages published from Service A.
+4. The Redis component definition uses a component scoping security policy to say only Service B is allowed to call it.
+5. Service B restricts the Dapr sidecar to only use the pub/sub, state management and secrets APIs. All other API calls, for example service invocation, would fail.
+6. A secrets security policy set in configuration restricts which secrets Service B it is able to access, in this case it can only read the secret needed to connect to the Redis state store component, and no others.
+7. Service B is deployed to namespace "B" which further isolates it from other services meaning that even if the service invocation API was enabled on it, it could not be accidently called by being in the space namespace as Service A. Furthermore Service B must explicity set the Redis Host namespace in its component YAML file to call onto the "Redis" namespace, otherwise this call also fails.
+8. The data in the Redis state store is encrypted at rest and can only be read using the correctly configured Dapr Redis state store component.      
+
+# Threat model
 Threat modeling is a process by which potential threats, such as structural vulnerabilities or the absence of appropriate safeguards, can be identified and enumerated, and mitigations can be prioritized. The Dapr threat model is below.
 
 <img src="/images/security-threat-model.png" alt="Dapr threat model" width=1000>
@@ -146,3 +204,6 @@ The full report can be found [here](/docs/Dapr-july-2020-security-audit-report.p
 ## Reporting a security issue
 
 Visit [this page]({{< ref support-security-issues.md >}}) to report a security issue to the Dapr maintainers.
+
+## Related links
+ - [Operational Security]({{< ref "security.md" >}})

daprdocs/content/en/contributing/presentations.md

@@ -20,6 +20,7 @@ We welcome community members giving presentations on Dapr and spreading the word
 
 | Presentation | Recording | Deck |
 |--------------|-----------|------|
+| Running Event-Driven Pub/Sub Microservices In Kubernetes With Dapr | [Link](https://youtu.be/-4sHUvfk2Eg) | N/A
 | Ignite 2019: Mark Russinovich Presents the Future of Cloud Native Applications | [Link](https://www.youtube.com/watch?v=LAUDVk8PaCY) | [Link](/presentations/2019IgniteCloudNativeApps.pdf)
 | Azure Community Live: Build microservice applications using DAPR with Mark Fussell | [Link](https://www.youtube.com/watch?v=CgqI7nen-Ng) | N/A
 | Ready 2020: Mark Russinovich Presents Cloud Native Applications | [Link](https://youtu.be/eJCu6a-x9uo?t=1614) | [Link](/presentations/2020ReadyCloudNativeApps.pdf)

daprdocs/content/en/developing-applications/building-blocks/service-invocation/service-invocation-namespaces.md

@@ -0,0 +1,36 @@
+---
+type: docs
+title: "Service invocation across namespaces"
+linkTitle: "Service invocation namespaces"
+weight: 1000
+description: "Call between services deployed to different namespaces"
+---
+
+This article describes how you can call between services deployed to different namespaces. By default, you can invoke services within the *same* namespace by simply referencing the app ID (`nodeapp`):
+
+```sh
+localhost:3500/v1.0/invoke/nodeapp/method/neworder
+```
+Service invocation also supports calls across namespaces. On all supported hosting platforms, Dapr app IDs conform to a valid FQDN format that includes the target namespace. You can therefore specify both the app ID (`nodeapp`) in addition to the namespace the app runs in (`production`). For example to call the `neworder` method on the `nodeapp`, in the `production` namespace would look like this:
+
+```sh
+localhost:3500/v1.0/invoke/nodeapp.production/method/neworder
+```
+
+When using service invocation to call an application in a namespace you qualify it with the namespace. This is especially useful in cross namespace calls in a Kubernetes cluster. As another example, calling the `ping` method on `myapp` which is scoped to the `production` namespace would look like this:
+
+```bash
+https://localhost:3500/v1.0/invoke/myapp.production/method/ping
+```
+
+**Example 3**
+
+Call the same `ping` method as example 2 using a curl command from an external DNS address (in this case, `api.demo.dapr.team`) and supply the Dapr API token for authentication:
+
+MacOS/Linux:
+```
+curl -i -d '{ "message": "hello" }' \
+     -H "Content-type: application/json" \
+     -H "dapr-api-token: ${API_TOKEN}" \
+     https://api.demo.dapr.team/v1.0/invoke/myapp.production/method/ping
+```

daprdocs/content/en/developing-applications/building-blocks/service-invocation/service-invocation-overview.md

@@ -2,7 +2,7 @@
 type: docs
 title: "Service invocation overview"
 linkTitle: "Overview"
-weight: 1000
+weight: 900
 description: "Overview of the service invocation API building block"
 ---
 
@@ -39,23 +39,9 @@ The diagram below is an overview of how Dapr's service invocation works.
 ## Features
 Service invocation provides several features to make it easy for you to call methods between applications.
 
-### Namespaces scoping
+### Namespace scoping
 
-By default, users can invoke services within the same namespaces by simply referencing the app ID (`nodeapp`):
-
-```sh
-localhost:3500/v1.0/invoke/nodeapp/method/neworder
-```
-
-Service invocation also supports calls across namespaces. On all supported hosting platforms, Dapr app IDs conform to a valid FQDN format that includes the target namespace.
-
-Users can specify both the app ID (`nodeapp`) in addition to the namespace the app runs in (`production`):
-
-```sh
-localhost:3500/v1.0/invoke/nodeapp.production/method/neworder
-```
-
-This is especially useful in cross namespace calls in a Kubernetes cluster.
+Applications can be scoped to namespaces for deployment and security, and you can call between services deployed to different namespaces. For more information, read the [Service invocation across namespaces]({{< ref "service-invocation-namespaces.md" >}}) article.
 
 ### Service-to-service security
 

daprdocs/content/en/developing-applications/building-blocks/state-management/howto-encrypt-state.md

@@ -90,3 +90,7 @@ metadata:
 When Dapr starts, it will fetch the secrets containing the encryption keys listed in the `metadata` section. Dapr knows which state item has been encrypted with which key automatically, as it appends the `secretKeyRef.name` field to the end of the actual state key.
 
 To rotate a key, simply change the `primaryEncryptionKey` to point to a secret containing your new key, and move the old primary encryption key to the `secondaryEncryptionKey`. New data will be encrypted using the new key, and old data that's retrieved will be decrypted using the secondary key. Any updates to data items encrypted using the old key will be re-encrypted using the new key.
+
+## Related links
+ - [Security overview]({{< ref "security-concept.md" >}})
+ - [State store query API implementation guide](https://github.com/dapr/components-contrib/blob/master/state/Readme.md#implementing-state-query-api)

daprdocs/content/en/developing-applications/building-blocks/state-management/howto-get-save-state.md

@@ -333,7 +333,7 @@ Restart your sidecar and try retrieving state again to observe that state persis
 Begin by launching a Dapr sidecar:
 
 ```bash
-dapr --app-id orderprocessing --port 3601 run
+dapr --app-id orderprocessing --dapr-http-port 3601 run
 ```
 
 Then in a separate terminal save a key/value pair into your statestore:

daprdocs/content/en/developing-applications/integrations/Azure/azure-kubernetes-service-extension.md

@@ -86,4 +86,4 @@ Once the k8-extension finishes provisioning, you can confirm that the Dapr contr
 kubectl get pods -n dapr-system
 ```
 
-For further information such as configuration options and targeting specific versions of Dapr, please see the official [AKS Dapr Extension Docs](https://docs.microsoft.com/azure/aks/dapr).
+For further information such as configuration options and targeting specific versions of Dapr, see the official [AKS Dapr Extension Docs](https://docs.microsoft.com/azure/aks/dapr).

daprdocs/content/en/getting-started/get-started-component.md

@@ -65,7 +65,7 @@ Run the following command to launch a Dapr sidecar that will listen on port 3500
 dapr run --app-id myapp --dapr-http-port 3500 --components-path ./my-components
 ```
 
-> If you encounter a error message stating the app ID is already in use, it may be that the sidecar you ran in the previous step is still running. Make sure you stop the sidecar before running the above command (e.g. using "Control-C").
+> If you encounter a error message stating the app ID is already in use, it may be that the sidecar you ran in the previous step is still running. Make sure you stop the sidecar before running the above command using "Control-C" or running the command `dapr stop --app-id myapp`.
 
 ## Step 4: Get a secret
 

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

@@ -72,31 +72,15 @@ In this example, the Redis component is only accessible to Dapr instances runnin
 
 {{< /tabs >}}
 
-## Using namespaces with service invocation
+{{% alert title="Note" color="primary" %}}
+The component YAML applied to namespace "A" can *reference* the implementation in namespace "B". For example, a component YAML for Redis in namespace "production-A" can point the Redis host address to the Redis instance deployed in namespace "production-B". 
 
-When using service invocation an application in a namespace you have to qualify it with the namespace. For example calling the `ping` method on `myapp` which is scoped to the `production` namespace would be like this.
-
-```bash
-https://localhost:3500/v1.0/invoke/myapp.production/method/ping
-```
-
-Or using a curl command from an external DNS address, in this case `api.demo.dapr.team` would be like this.
-
-MacOS/Linux:
-```
-curl -i -d '{ "message": "hello" }' \
-     -H "Content-type: application/json" \
-     -H "dapr-api-token: ${API_TOKEN}" \
-     https://api.demo.dapr.team/v1.0/invoke/myapp.production/method/ping
-```
-
-## Using namespaces with pub/sub
-Read [Configure Pub/Sub components with multiple namespaces]({{< ref "pubsub-namespaces.md" >}}) for more information on using namespaces with pub/sub.
+See [Configure Pub/Sub components with multiple namespaces]({{< ref "pubsub-namespaces.md" >}}) for an example.
+{{% /alert %}}
 
 ## Application access to components with scopes
-
-Developers and operators might want to limit access for one database to a certain application, or a specific set of applications.
-To achieve this, Dapr allows you to specify `scopes` on the component YAML. Application scopes added to a component limit only the applications with specific IDs to be able to use the component.
+Developers and operators might want to limit access to one database from a certain application, or a specific set of applications.
+To achieve this, Dapr allows you to specify `scopes` on the component YAML. Application scopes added to a component limit only the applications with specific IDs from using the component.
 
 The following example shows how to give access to two Dapr enabled apps, with the app IDs of `app1` and `app2` to the Redis component named `statestore` which itself is in the `production` namespace
 
@@ -116,13 +100,18 @@ scopes:
 - app1
 - app2
 ```
-
-## Example
+### Community call demo
 
 <div class="embed-responsive embed-responsive-16by9">
 <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>
 </div>
 
+## Using namespaces with service invocation
+Read [Service invocation across namespaces]({{< ref "service-invocation-namespaces.md" >}}) for more information on using namespaces when calling between services.
+
+## Using namespaces with pub/sub
+Read [Configure Pub/Sub components with multiple namespaces]({{< ref "pubsub-namespaces.md" >}}) for more information on using namespaces with pub/sub.
+
 ## Related links
 
 - [Configure Pub/Sub components with multiple namespaces]({{< ref "pubsub-namespaces.md" >}})

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

@@ -62,6 +62,7 @@ kubectl rollout restart statefulsets/dapr-placement-server -n <DAPR_NAMESPACE>
 *Note: the control plane Sidecar Injector service does not need to be redeployed*
 
 ### Disabling mTLS with Helm
+*The control plane will continue to use mTLS*
 
 ```bash
 kubectl create ns dapr-system
@@ -74,6 +75,7 @@ helm install \
 ```
 
 ### Disabling mTLS with the CLI
+*The control plane will continue to use mTLS*
 
 ```
 dapr init --kubernetes --enable-mtls=false
@@ -86,7 +88,6 @@ In order to view the Sentry service logs, run the following command:
 ```
 kubectl logs --selector=app=dapr-sentry --namespace <DAPR_NAMESPACE>
 ```
-
 ### Bringing your own certificates
 
 Using Helm, you can provide the PEM encoded root cert, issuer cert and private key that will be populated into the Kubernetes secret used by the Sentry service.
@@ -163,9 +164,51 @@ helm install \
 If the Root or Issuer certs are about to expire, you can update them and restart the required system services.
 
 {{% alert title="Avoiding downtime when rotating certificates" color="warning" %}}
-To avoid downtime when rotating expiring certificates your new certificates must be signed with the same private root key as the previous certificates.
+To avoid downtime when rotating expiring certificates your new certificates must be signed with the same private root key as the previous certificates. This is not currently possible using self-signed certificates generated by Dapr.
 {{% /alert %}}
 
+#### Dapr-generated self-signed certificates
+
+1. Clear the existing Dapr Trust Bundle secret by saving the following YAML to a file (e.g. `clear-trust-bundle.yaml`) and applying this secret.
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: dapr-trust-bundle
+  labels:
+    app: dapr-sentry
+data:
+```
+
+```bash
+kubectl apply -f `clear-trust-bundle.yaml` -n <DAPR_NAMESPACE>
+```
+
+2. Restart the Dapr Sentry service. This will generate a new certificate bundle and update the `dapr-trust-bundle` Kubernetes secret.
+
+```bash
+kubectl rollout restart -n <DAPR_NAMESPACE> deployment/dapr-sentry
+```
+
+3. Once the Sentry service has been restarted, restart the rest of the Dapr control plane to pick up the new Dapr Trust Bundle.
+
+```bash
+kubectl rollout restart deploy/dapr-operator -n <DAPR_NAMESPACE>
+kubectl rollout restart statefulsets/dapr-placement-server -n <DAPR_NAMESPACE>
+```
+
+4. Restart your Dapr applications to pick up the latest trust bundle.
+
+{{% alert title="Potential application downtime with mTLS enabled." color="warning" %}}
+Restarts of deployments using service to service invocation using mTLS will fail until the callee service has also been restarted (thereby loading the new Dapr Trust Bundle). Additionally, the placement service will not be able to assign new actors (while existing actors remain unaffected) until applications have been restarted to load the new Dapr Trust Bundle.
+{{% /alert %}}
+
+```bash
+kubectl rollout restart deployment/mydaprservice1 kubectl deployment/myotherdaprservice2
+```
+
+#### Custom certificates (bring your own)
+
 First, issue new certificates using the step above in [Bringing your own certificates](#bringing-your-own-certificates).
 
 Now that you have the new certificates, use Helm to upgrade the certificates:
@@ -189,14 +232,21 @@ kubectl edit secret dapr-trust-bundle -n <DAPR_NAMESPACE>
 Replace the `ca.crt`, `issuer.crt` and `issuer.key` keys in the Kubernetes secret with their corresponding values from the new certificates.
 *__Note: The values must be base64 encoded__*
 
-If you signed the new cert root with the same private key the Dapr Sentry service will pick up the new certificates automatically. You can restart your application deployments using `kubectl rollout restart` with zero downtime. It is not necessary to restart all deployments at once, as long as deployments are restarted before original certificate expiration.
+If you signed the new cert root with the **same private key** the Dapr Sentry service will pick up the new certificates automatically. You can restart your application deployments using `kubectl rollout restart` with zero downtime. It is not necessary to restart all deployments at once, as long as deployments are restarted before original certificate expiration.
 
-If you signed the new cert root with a different private key, you must restart the Dapr sentry service.
+If you signed the new cert root with a **different private key**, you must restart the Dapr Sentry service, followed by the remainder of the Dapr control plane service.
 
 ```bash
 kubectl rollout restart deploy/dapr-sentry -n <DAPR_NAMESPACE>
 ```
 
+Once Sentry has been completely restarted run:
+
+```bash
+kubectl rollout restart deploy/dapr-operator -n <DAPR_NAMESPACE>
+kubectl rollout restart statefulsets/dapr-placement-server -n <DAPR_NAMESPACE>
+```
+
 Next, you must restart all Dapr-enabled pods.
 The recommended way to do this is to perform a rollout restart of your deployment:
 
@@ -342,9 +392,20 @@ Place `ca.crt`, `issuer.crt` and `issuer.key` in a desired path (`$HOME/.dapr/ce
 
 If the Root or Issuer certs are about to expire, you can update them and restart the required system services.
 
-First, issue new certificates using the step above in [Bringing your own certificates](#bringing-your-own-certificates).
+To have Dapr generate new certificates, delete the existing certificates at `$HOME/.dapr/certs` and restart the sentry service to generate new certificates.
+
+```bash
+./sentry --issuer-credentials $HOME/.dapr/certs --trust-domain cluster.local --config=./config.yaml
+```
+
+To replace with your own certificates, first generate new certificates using the step above in [Bringing your own certificates](#bringing-your-own-certificates).
 
 Copy `ca.crt`, `issuer.crt` and `issuer.key` to the filesystem path of every configured system service, and restart the process or container.
-By default, system services will look for the credentials in `/var/run/dapr/credentials`.
+By default, system services will look for the credentials in `/var/run/dapr/credentials`. The examples above use `$HOME/.dapr/certs` as a custom location.
 
-*Note:If you signed the cert root with a different private key, restart the Dapr instances.*
+*Note: If you signed the cert root with a different private key, restart the Dapr instances.*
+
+## Community call video on certificate rotation
+Watch this video on how to perform certificate rotation if your certicates are expiring.
+
+<iframe width="1280" height="720" src="https://www.youtube.com/watch?v=Hkcx9kBDrAc" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

daprdocs/content/en/reference/components-reference/supported-bindings/blobstorage.md

@@ -50,6 +50,8 @@ The above example uses secrets as plain strings. It is recommended to use a secr
 | getBlobRetryCount | N | Output | Specifies the maximum number of HTTP GET requests that will be made while reading from a RetryReader Defaults to `10` | `1`, `2`
 | publicAccessLevel | N | Output | Specifies whether data in the container may be accessed publicly and the level of access (only used if the container is created by Dapr). Defaults to `none` | `blob`, `container`, `none` 
 
+### Azure Active Directory (AAD) authentication
+The Azure Blob Storage binding component supports authentication using all Azure Active Directory mechanisms. For further information and the relevant component metadata fields to provide depending on the choice of AAD authentication mechanism, see the [docs for authenticating to Azure]({{< ref authenticating-azure.md >}}).
 
 ## Binding support
 

daprdocs/content/en/reference/components-reference/supported-bindings/cosmosdb.md

@@ -50,6 +50,9 @@ The above example uses secrets as plain strings. It is recommended to use a secr
 
 For more information see [Azure Cosmos DB resource model](https://docs.microsoft.com/azure/cosmos-db/account-databases-containers-items).
 
+### Azure Active Directory (AAD) authentication
+The Azure Cosmos DB binding component supports authentication using all Azure Active Directory mechanisms. For further information and the relevant component metadata fields to provide depending on the choice of AAD authentication mechanism, see the [docs for authenticating to Azure]({{< ref authenticating-azure.md >}}).
+
 ## Binding support
 
 This component supports **output binding** with the following operations:

daprdocs/content/en/reference/components-reference/supported-bindings/cosmosdbgremlinapi.md

@@ -38,7 +38,7 @@ The above example uses secrets as plain strings. It is recommended to use a secr
 |--------------------|:--------:|--------|---------|---------|
 | url | Y | Output | The CosmosDBGremlinAPI url | `"wss://******.gremlin.cosmos.azure.com:443/"` |
 | masterKey | Y | Output | The CosmosDBGremlinAPI account master key | `"masterKey"` |
-| database | Y | Output | The username of the CosmosDBGremlinAPI database | `"username"` |
+| username | Y | Output | The username of the CosmosDBGremlinAPI database | `"/dbs/<database_name>/colls/<graph_name>"` |
 
 For more information see [Quickstart: Azure Cosmos Graph DB using Gremlin ](https://docs.microsoft.com/azure/cosmos-db/graph/create-graph-console).
 
@@ -48,6 +48,17 @@ This component supports **output binding** with the following operations:
 
 - `query`
 
+## Request payload sample
+
+```json
+{
+  "data": {
+    "gremlin": "g.V().count()"
+    },
+  "operation": "query"
+}
+```
+
 ## Related links
 
 - [Basic schema for a Dapr component]({{< ref component-schema >}})

daprdocs/content/en/reference/components-reference/supported-bindings/servicebusqueues.md

@@ -43,6 +43,9 @@ The above example uses secrets as plain strings. It is recommended to use a secr
 | queueName | Y | Input/Output | The Service Bus queue name. Queue names are case-insensitive and will always be forced to lowercase. | `"queuename"` |
 | ttlInSeconds | N | Output | Parameter to set the default message [time to live](https://docs.microsoft.com/azure/service-bus-messaging/message-expiration). If this parameter is omitted, messages will expire after 14 days. See [also](#specifying-a-ttl-per-message) | `"60"` |
 
+### Azure Active Directory (AAD) authentication
+The Azure Service Bus Queues binding component supports authentication using all Azure Active Directory mechanisms. For further information and the relevant component metadata fields to provide depending on the choice of AAD authentication mechanism, see the [docs for authenticating to Azure]({{< ref authenticating-azure.md >}}).
+
 ## Binding support
 
 This component supports both **input and output** binding interfaces.

daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-eventhubs.md

@@ -65,6 +65,8 @@ The above example uses secrets as plain strings. It is recommended to use a secr
 | partitionCount | N | Number of partitions for the new event hub. Only used when entity management is enabled. Default: `"1"` | `"2"`
 | messageRetentionInDays | N | Number of days to retain messages for in the newly created event hub. Used only when entity management is enabled. Default: `"1"` | `"90"`
 
+### Azure Active Directory (AAD) authentication
+The Azure Event Hubs pubsub component supports authentication using all Azure Active Directory mechanisms. For further information and the relevant component metadata fields to provide depending on the choice of AAD authentication mechanism, see the [docs for authenticating to Azure]({{< ref authenticating-azure.md >}}).
 
 ## Create an Azure Event Hub
 

daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus.md

@@ -45,7 +45,7 @@ spec:
   # - name: defaultMessageTimeToLiveInSec # Optional
   #   value: 10
   # - name: autoDeleteOnIdleInSec # Optional
-  #   value: 10
+  #   value: 3600
   # - name: maxReconnectionAttempts # Optional
   #   value: 30
   # - name: connectionRecoveryInSec # Optional
@@ -78,12 +78,15 @@ The above example uses secrets as plain strings. It is recommended to use a secr
 | maxConcurrentHandlers | N  |Defines the maximum number of concurrent message handlers  | `10`
 | prefetchCount         | N  |Defines the number of prefetched messages (use for high throughput / low latency scenarios)| `5`
 | defaultMessageTimeToLiveInSec | N  |Default message time to live. | `10`
-| autoDeleteOnIdleInSec | N  |Time in seconds to wait before auto deleting messages. | `10`
+| autoDeleteOnIdleInSec | N  |Time in seconds to wait before auto deleting idle subscriptions. | `3600`
 | maxReconnectionAttempts | N  |Defines the maximum number of reconnect attempts. Default: `30` | `30`
 | connectionRecoveryInSec | N  |Time in seconds to wait between connection recovery attempts. Defaults: `2` | `2`
 | publishMaxRetries | N  | The max number of retries for when Azure Service Bus responds with "too busy" in order to throttle messages. Defaults: `5` | `5`
 | publishInitialRetryInternalInMs | N  | Time in milliseconds for the initial exponential backoff when Azure Service Bus throttle messages. Defaults: `500` | `500`
 
+### Azure Active Directory (AAD) authentication
+The Azure Service Bus pubsub component supports authentication using all Azure Active Directory mechanisms. For further information and the relevant component metadata fields to provide depending on the choice of AAD authentication mechanism, see the [docs for authenticating to Azure]({{< ref authenticating-azure.md >}}).
+
 ## Message metadata
 
 Azure Service Bus messages extend the Dapr message format with additional contextual metadata. Some metadata fields are set by Azure Service Bus itself (read-only) and others can be set by the client when publishing a message.

daprdocs/content/en/reference/components-reference/supported-pubsub/setup-jetstream.md

@@ -88,6 +88,14 @@ with NATS, find the service with: `kubectl get svc my-nats`.
 
 {{< /tabs >}}
 
+## Create JetStream
+
+It is essential to create a NATS JetStream for a specific subject. For example, for a NATS server running locally use:
+
+```bash
+nats -s localhost:4222 stream add myStream --subjects mySubject
+```
+
 ## Related links
 - [Basic schema for a Dapr component]({{< ref component-schema >}})
 - Read [this guide]({{< ref "howto-publish-subscribe.md#step-2-publish-a-topic" >}}) for instructions on configuring pub/sub components

daprdocs/content/en/reference/components-reference/supported-state-stores/setup-azure-cosmosdb.md

@@ -52,6 +52,9 @@ If you wish to use CosmosDb as an actor store, append the following to the yaml.
 | collection         | Y        | The name of the collection | `"collection"`
 | actorStateStore    | N         | Consider this state store for actors. Defaults to `"false"` | `"true"`, `"false"`
 
+### Azure Active Directory (AAD) authentication
+The Azure Cosmos DB state store component supports authentication using all Azure Active Directory mechanisms. For further information and the relevant component metadata fields to provide depending on the choice of AAD authentication mechanism, see the [docs for authenticating to Azure]({{< ref authenticating-azure.md >}}).
+
 ## Setup Azure Cosmos DB
 
 [Follow the instructions](https://docs.microsoft.com/azure/cosmos-db/how-to-manage-database-account) from the Azure documentation on how to create an Azure CosmosDB account.  The database and collection must be created in CosmosDB before Dapr can use it.