mirror of https://github.com/dapr/docs.git
Updates from adding the Configuration API
This commit is contained in:
Mark Fussell
parent
153a3c54e5
commit
9a550c60b2
|
|
@ -6,13 +6,13 @@ weight: 300
|
|||
description: "Modular functionality used by building blocks and applications"
|
||||
---
|
||||
|
||||
Dapr uses a modular design where functionality is delivered as a component. Each component has an interface definition. All of the components are pluggable so that you can swap out one component with the same interface for another. The [components contrib repo](https://github.com/dapr/components-contrib) is where you can contribute implementations for the component interfaces and extends Dapr's capabilities.
|
||||
Dapr uses a modular design where functionality is delivered as a component. Each component has an interface definition. All of the components are pluggable so that you can swap out one component with the same interface for another. The [components contrib repository](https://github.com/dapr/components-contrib) is where you can contribute implementations for the component interfaces and extend Dapr's capabilities.
|
||||
|
||||
A building block can use any combination of components. For example the [actors]({{<ref "actors-overview.md">}}) building block and the [state management]({{<ref "state-management-overview.md">}}) building block both use [state components](https://github.com/dapr/components-contrib/tree/master/state). As another example, the [Pub/Sub]({{<ref "pubsub-overview.md">}}) building block uses [Pub/Sub components](https://github.com/dapr/components-contrib/tree/master/pubsub).
|
||||
A building block can use any combination of components. For example the [actors]({{<ref "actors-overview.md">}}) building block and the [state management]({{<ref "state-management-overview.md">}}) building block both use [state components](https://github.com/dapr/components-contrib/tree/master/state). As another example, the [pub/sub]({{<ref "pubsub-overview.md">}}) building block uses [pub/sub components](https://github.com/dapr/components-contrib/tree/master/pubsub).
|
||||
|
||||
You can get a list of current components available in the current hosting environment using the `dapr components` CLI command.
|
||||
You can get a list of current components available in the hosting environment using the `dapr components` CLI command.
|
||||
|
||||
The following are the component types provided by Dapr:
|
||||
The following are the component types provided by Dapr:
|
||||
|
||||
## State stores
|
||||
|
||||
|
|
@ -25,8 +25,8 @@ State store components are data stores (databases, files, memory) that store key
|
|||
|
||||
Name resolution components are used with the [service invocation]({{<ref "service-invocation-overview.md">}}) building block to integrate with the hosting environment to provide service-to-service discovery. For example, the Kubernetes name resolution component integrates with the Kubernetes DNS service, self-hosted uses mDNS and clusters of VMs can use the Consul name resolution component.
|
||||
|
||||
- [List of state stores]({{< ref supported-name-resolution >}})
|
||||
- [Service discovery name resolution implementations](https://github.com/dapr/components-contrib/tree/master/nameresolution)
|
||||
- [List of name resolution components]({{< ref supported-name-resolution >}})
|
||||
- [Name resolution implementations](https://github.com/dapr/components-contrib/tree/master/nameresolution)
|
||||
|
||||
## Pub/sub brokers
|
||||
|
||||
|
|
@ -37,14 +37,14 @@ Pub/sub broker components are message brokers that can pass messages to/from ser
|
|||
|
||||
## Bindings
|
||||
|
||||
External resources can connect to Dapr in order to trigger a service or be called from a service as part of the [bindings]({{< ref bindings-overview.md >}}) building block.
|
||||
External resources can connect to Dapr in order to trigger a method on an application or be called from an application as part of the [bindings]({{< ref bindings-overview.md >}}) building block.
|
||||
|
||||
- [List of supported bindings]({{< ref supported-bindings >}})
|
||||
- [Binding implementations](https://github.com/dapr/components-contrib/tree/master/bindings)
|
||||
|
||||
## Secret stores
|
||||
|
||||
A [secret]({{<ref "secrets-overview.md">}}) is any piece of private information that you want to guard against unwanted users. Secrets stores are used to store secrets that can be retrieved and used in services.
|
||||
A [secret]({{<ref "secrets-overview.md">}}) is any piece of private information that you want to guard against unwanted access. Secrets stores are used to store secrets that can be retrieved and used in applications.
|
||||
|
||||
- [List of supported secret stores]({{< ref supported-secret-stores >}})
|
||||
- [Secret store implementations](https://github.com/dapr/components-contrib/tree/master/secretstores)
|
||||
|
|
@ -58,7 +58,7 @@ Configuration stores are used to save application data which can then be read by
|
|||
|
||||
## Middleware
|
||||
|
||||
Dapr allows custom [middleware]({{<ref "middleware.md">}}) to be plugged into the HTTP request processing pipeline. Middleware can perform additional actions on a HTTP request, such as authentication, encryption and message transformation before the request is routed to the user code, or before the request is returned to the client. The middleware components are used with the [service invocation]({{<ref "service-invocation-overview.md">}}) building block.
|
||||
Dapr allows custom [middleware]({{<ref "middleware.md">}}) to be plugged into the HTTP request processing pipeline. Middleware can perform additional actions on an HTTP request, such as authentication, encryption and message transformation before the request is routed to the user code, or before the request is returned to the client. The middleware components are used with the [service invocation]({{<ref "service-invocation-overview.md">}}) building block.
|
||||
|
||||
- [List of supported middleware components]({{< ref supported-middleware >}})
|
||||
- [Middleware implementations](https://github.com/dapr/components-contrib/tree/master/middleware)
|
||||
|
|
@ -1,14 +1,14 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Configuration"
|
||||
title: "Application and control plane configuration"
|
||||
linkTitle: "Configuration"
|
||||
weight: 400
|
||||
description: "Change the behavior of Dapr sidecars or globally on Dapr system services"
|
||||
description: "Change the behavior of Dapr application sidecars or globally on Dapr control plane system services"
|
||||
---
|
||||
|
||||
Dapr configurations are settings and policies that enable you to change both the behavior of individual Dapr applications, or the global behavior of the system services in the Dapr control plane. For example you can set an ACL policy using configuration which indicates which methods can be called on the application, or you can change the certificate renewal period on the Dapr control plane configuration.
|
||||
Dapr configurations are settings and policies that enable you to change both the behavior of individual Dapr applications, or the global behavior of the Dapr control plane system services. For example, you can set an ACL policy on the application sidecar configuration which indicates which methods can be called from another application, or on the Dapr control plane configuration you can change the certificate renewal period for all certificates that are deployed to application sidecar instances.
|
||||
|
||||
Configurations are defined and deployed as a YAML file. An application configuration example is shown below, which demonstrates an example of setting a tracing endpoint to send metrics information to capturing all the sample traces.
|
||||
Configurations are defined and deployed as a YAML file. An application configuration example is shown below, which demonstrates an example of setting a tracing endpoint for where to send the metrics information, capturing all the sample traces.
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
|
|
@ -23,10 +23,26 @@ spec:
|
|||
endpointAddress: "http://localhost:9411/api/v2/spans"
|
||||
```
|
||||
|
||||
This configuration configures tracing for telemetry recording. It can be loaded in self-hosted mode by editing the default configuration file called `config.yaml` file in your `.dapr` directory, or by applying it to your Kubernetes cluster with kubectl/helm.
|
||||
This configuration configures tracing for metrics recording. It can be loaded in local self-hosted mode by editing the default configuration file called `config.yaml` file in your `.dapr` directory, or by applying it to your Kubernetes cluster with kubectl/helm.
|
||||
|
||||
Here is an example of the Dapr control plane configuration in the `daprsystem` namespace.
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Configuration
|
||||
metadata:
|
||||
name: daprsystem
|
||||
namespace: default
|
||||
spec:
|
||||
mtls:
|
||||
enabled: true
|
||||
workloadCertTTL: "24h"
|
||||
allowedClockSkew: "15m"
|
||||
```
|
||||
|
||||
Visit [overview of Dapr configuration options]({{<ref "configuration-overview.md">}}) for a list of the configuration options.
|
||||
For an
|
||||
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
Dapr sidecar and control plane configurations should not be confused with the configuration building block API that enables applications to retrieve key/value data from configuration store components. Read the [Configuration building block]({{< ref configuration-api-overview >}}) for more information.
|
||||
Dapr application and control plane configurations should not be confused with the configuration building block API that enables applications to retrieve key/value data from configuration store components. Read the [Configuration building block]({{< ref configuration-api-overview >}}) for more information.
|
||||
{{% /alert %}}
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Dapr operator service overview"
|
||||
title: "Dapr Operator control plane service overview"
|
||||
linkTitle: "Operator"
|
||||
description: "Overview of the Dapr operator process"
|
||||
description: "Overview of the Dapr operator service"
|
||||
---
|
||||
|
||||
When running Dapr in [Kubernetes mode]({{< ref kubernetes >}}), a pod running the Dapr operator service manages [Dapr component]({{< ref components >}}) updates and provides Kubernetes services endpoints for Dapr.
|
||||
When running Dapr in [Kubernetes mode]({{< ref kubernetes >}}), a pod running the Dapr Operator service manages [Dapr component]({{< ref components >}}) updates and provides Kubernetes services endpoints for Dapr.
|
||||
|
||||
## Running the operator service
|
||||
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Dapr placement service overview"
|
||||
title: "Dapr Placement control plane service overview"
|
||||
linkTitle: "Placement"
|
||||
description: "Overview of the Dapr placement process"
|
||||
description: "Overview of the Dapr placement service"
|
||||
---
|
||||
|
||||
The Dapr placement service is used to calculate and distribute distributed hash tables for the location of [Dapr actors]({{< ref actors >}}) running in [self-hosted mode]({{< ref self-hosted >}}) or on [Kubernetes]({{< ref kubernetes >}}). This hash table maps actor IDs to pods or processes so a Dapr application can communicate with the actor.Anytime a Dapr application activates a Dapr actor, the placement updates the hash tables with the latest actor locations.
|
||||
The Dapr Placement service is used to calculate and distribute distributed hash tables for the location of [Dapr actors]({{< ref actors >}}) running in [self-hosted mode]({{< ref self-hosted >}}) or on [Kubernetes]({{< ref kubernetes >}}). This hash table maps actor IDs to pods or processes so a Dapr application can communicate with the actor.Anytime a Dapr application activates a Dapr actor, the placement updates the hash tables with the latest actor locations.
|
||||
|
||||
## Self-hosted mode
|
||||
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Dapr sentry service overview"
|
||||
title: "Dapr Sentry control plane service overview"
|
||||
linkTitle: "Sentry"
|
||||
description: "Overview of the Dapr sentry process"
|
||||
description: "Overview of the Dapr sentry service"
|
||||
---
|
||||
|
||||
The Dapr sentry service manages mTLS between services and acts as a certificate authority. It generates mTLS certificates and distributes them to any running sidecars. This allows sidecars to communicate with encrypted, mTLS traffic. For more information read the [sidecar-to-sidecar communication overview]({{< ref "security-concept.md#sidecar-to-sidecar-communication" >}}).
|
||||
The Dapr Sentry service manages mTLS between services and acts as a certificate authority. It generates mTLS certificates and distributes them to any running sidecars. This allows sidecars to communicate with encrypted, mTLS traffic. For more information read the [sidecar-to-sidecar communication overview]({{< ref "security-concept.md#sidecar-to-sidecar-communication" >}}).
|
||||
|
||||
## Self-hosted mode
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +1,13 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Dapr sidecar injector overview"
|
||||
title: "Dapr Sidecar Injector control plane service overview"
|
||||
linkTitle: "Sidecar injector"
|
||||
description: "Overview of the Dapr sidecar injector process"
|
||||
---
|
||||
|
||||
When running Dapr in [Kubernetes mode]({{< ref kubernetes >}}), a pod is created running the dapr-sidecar-injector service, which looks for pods initialized with the [Dapr annotations]({{< ref arguments-annotations-overview.md >}}), and then creates another container in that pod for the [daprd service]({{< ref sidecar >}})
|
||||
When running Dapr in [Kubernetes mode]({{< ref kubernetes >}}), a pod is created running the Dapr Sidecar Injector service, which looks for pods initialized with the [Dapr annotations]({{< ref arguments-annotations-overview.md >}}), and then creates another container in that pod for the [daprd service]({{< ref sidecar >}})
|
||||
|
||||
## Running the sidecar injector
|
||||
|
||||
The sidecar injector service is deployed as part of `dapr init -k`, or via the Dapr Helm charts. For more information on running Dapr on Kubernetes, visit the [Kubernetes hosting page]({{< ref kubernetes >}}).
|
||||
|
||||
|
|
|
|||
|
|
@ -91,10 +91,10 @@ To make using Dapr more natural for different languages, it also includes [langu
|
|||
- Go
|
||||
- Java
|
||||
- JavaScript
|
||||
- Python
|
||||
- Rust
|
||||
- .NET
|
||||
- PHP
|
||||
- Python
|
||||
- Rust
|
||||
|
||||
These SDKs expose the functionality of the Dapr building blocks through a typed language API, rather than calling the http/gRPC API. This enables you to write a combination of stateless and stateful functions and actors all in the language of your choice. And because these SDKs share the Dapr runtime, you get cross-language actor and function support.
|
||||
|
||||
|
|
@ -106,7 +106,7 @@ Dapr can be used from any developer framework. Here are some that have been inte
|
|||
|
||||
| Language | Frameworks | Description |
|
||||
|----------|------------|-------------|
|
||||
| [.NET]({{< ref dotnet >}}) | [ASP.NET]({{< ref dotnet-aspnet.md >}}) | Brings stateful routing controllers that respond to pub/sub events from other services. Can also take advantage of [ASP.NET Core gRPC Services](https://docs.microsoft.com/aspnet/core/grpc/).
|
||||
| [.NET]({{< ref dotnet >}}) | [ASP.NET Core]({{< ref dotnet-aspnet.md >}}) | Brings stateful routing controllers that respond to pub/sub events from other services. Can also take advantage of [ASP.NET Core gRPC Services](https://docs.microsoft.com/aspnet/core/grpc/).
|
||||
| [Java]({{< ref java >}}) | [Spring Boot](https://spring.io/)
|
||||
| [Python]({{< ref python >}}) | [Flask]({{< ref python-flask.md >}})
|
||||
| [Javascript](https://github.com/dapr/js-sdk) | [Express](http://expressjs.com/)
|
||||
|
|
@ -116,7 +116,6 @@ Dapr can be used from any developer framework. Here are some that have been inte
|
|||
|
||||
Visit the [integrations]({{< ref integrations >}}) page to learn about some of the first-class support Dapr has for various frameworks and external products, including:
|
||||
- Public cloud services
|
||||
- KEDA
|
||||
- Visual Studio Code
|
||||
- GitHub
|
||||
|
||||
|
|
|
|||
|
|
@ -2,12 +2,12 @@
|
|||
type: docs
|
||||
title: "Dapr and service meshes"
|
||||
linkTitle: "Service meshes"
|
||||
weight: 700
|
||||
weight: 900
|
||||
description: >
|
||||
How Dapr compares to, and works with, service meshes
|
||||
How Dapr compares to and works with service meshes
|
||||
---
|
||||
|
||||
Dapr uses a sidecar architecture, running as a separate process alongside the application and includes features such as service invocation, network security, and distributed tracing. This often raises the question: how does Dapr compare to service mesh solutions such as Linkerd, Istio and Open Service Mesh (OSM)?
|
||||
Dapr uses a sidecar architecture, running as a separate process alongside the application and includes features such as service invocation, network security, and distributed tracing. This often raises the question: how does Dapr compare to service mesh solutions such as [Linkerd](https://linkerd.io/[), [Istio](https://istio.io/) and [Open Service Mesh](https://openservicemesh.io/) amoung others?
|
||||
|
||||
## How Dapr and service meshes compare
|
||||
While Dapr and service meshes do offer some overlapping capabilities, **Dapr is not a service mesh**, where a service mesh is defined as a *networking* service mesh. Unlike a service mesh which is focused on networking concerns, Dapr is focused on providing building blocks that make it easier for developers to build applications as microservices. Dapr is developer-centric, versus service meshes which are infrastructure-centric.
|
||||
|
|
@ -34,10 +34,9 @@ Dapr does work with service meshes. In the case where both are deployed together
|
|||
Watch these recordings from the Dapr community calls showing presentations on running Dapr together with different service meshes:
|
||||
- General overview and a demo of [Dapr and Linkerd](https://youtu.be/xxU68ewRmz8?t=142)
|
||||
- Demo of running [Dapr and Istio](https://youtu.be/ngIDOQApx8g?t=335)
|
||||
- Learn more about [running Dapr with Open Service Mesh (OSM)]({{<ref open-service-mesh>}}).
|
||||
|
||||
Also, learn more about [running Dapr with Open Service Mesh (OSM)]({{<ref open-service-mesh>}}).
|
||||
|
||||
## When to choose using Dapr, a service mesh, or both
|
||||
## When to choose using Dapr a service mesh or both
|
||||
Should you be using Dapr, a service mesh, or both? The answer depends on your requirements. If, for example, you are looking to use Dapr for one or more building blocks such as state management or pub/sub, and you are considering using a service mesh just for network security or observability, you may find that Dapr is a good fit and that a service mesh is not required.
|
||||
|
||||
Typically you would use a service mesh with Dapr where there is a corporate policy that traffic on the network must be encrypted for all applications. For example, you may be using Dapr in only part of your application, and other services and processes that are not using Dapr in your application also need their traffic encrypted. In this scenario a service mesh is the better option, and most likely you should use mTLS and distributed tracing on the service mesh and disable this on Dapr.
|
||||
|
|
|
|||
|
|
@ -32,13 +32,13 @@ The Dapr SDKs are the easiest way for you to get Dapr into your application. Cho
|
|||
| Language | Status | Client SDK | Server extensions | Actor SDK |
|
||||
|----------|:------|:----------:|:-----------:|:---------:|
|
||||
| [.NET]({{< ref dotnet >}}) | Stable | ✔ | [ASP.NET Core]({{< ref dotnet-aspnet >}}) | ✔ |
|
||||
| [Python]({{< ref python >}}) | Stable | ✔ | [gRPC]({{< ref python-grpc.md >}}) | [FastAPI]({{< ref python-fastapi.md >}})<br />[Flask]({{< ref python-flask.md >}}) |
|
||||
| [Python]({{< ref python >}}) | Stable | ✔ | [gRPC]({{< ref python-grpc.md >}}) <br />[FastAPI]({{< ref python-fastapi.md >}})<br />[Flask]({{< ref python-flask.md >}})| ✔ |
|
||||
| [Java]({{< ref java >}}) | Stable | ✔ | Spring Boot | ✔ |
|
||||
| [Go]({{< ref go >}}) | Stable | ✔ | ✔ | |
|
||||
| [Go]({{< ref go >}}) | Stable | ✔ | ✔ | ✔ |
|
||||
| [PHP]({{< ref php >}}) | Stable | ✔ | ✔ | ✔ |
|
||||
| [Javascript](https://github.com/dapr/js-sdk) | Stable| ✔ | | ✔ |
|
||||
| [C++](https://github.com/dapr/cpp-sdk) | In development | ✔ | |
|
||||
| [Rust](https://github.com/dapr/rust-sdk) | In development | ✔ | | |
|
||||
| [Javascript](https://github.com/dapr/js-sdk) | In development| ✔ | |
|
||||
|
||||
## Further reading
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Setup an Azure Kubernetes Service cluster"
|
||||
linkTitle: "Azure Kubernetes Service"
|
||||
title: "Setup an Azure Kubernetes Service (AKS) cluster"
|
||||
linkTitle: "Azure Kubernetes Service (AKS)"
|
||||
weight: 2000
|
||||
description: >
|
||||
How to setup Dapr on an Azure Kubernetes Cluster.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Setup a Google Kubernetes Engine cluster"
|
||||
linkTitle: "Google Kubernetes Engine"
|
||||
title: "Setup a Google Kubernetes Engine (GKE) cluster"
|
||||
linkTitle: "Google Kubernetes Engine (GKE)"
|
||||
weight: 3000
|
||||
description: "Setup a Google Kubernetes Engine cluster"
|
||||
---
|
||||
|
|
|
|||
|
|
@ -40,7 +40,6 @@ The Dapr control-plane and sidecar images come from the [daprio Docker Hub](http
|
|||
|
||||
For information about pulling your application images from a private registry, reference the [Kubernetes documentation](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/). If you are using Azure Container Registry with Azure Kubernetes Service, reference the [AKS documentation](https://docs.microsoft.com/azure/aks/cluster-container-registry-integration).
|
||||
|
||||
|
||||
## Quickstart
|
||||
|
||||
You can see some examples [here](https://github.com/dapr/quickstarts/tree/master/hello-kubernetes) in the Kubernetes getting started quickstart.
|
||||
|
|
|
|||
|
|
@ -190,3 +190,9 @@ To configure a tracing backend for Dapr visit [this]({{< ref "setup-tracing.md"
|
|||
For metrics, Dapr exposes a Prometheus endpoint listening on port 9090 which can be scraped by Prometheus.
|
||||
|
||||
To setup Prometheus, Grafana and other monitoring tools with Dapr, visit [this]({{< ref "monitoring" >}}) link.
|
||||
|
||||
## Best Practices
|
||||
Watch this video for a deep dive into the best practices for running Dapr in production with Kubernetes
|
||||
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="360" height="315" src="https://www.youtube.com/embed/_U9wJqq-H1g" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
|
|
|||
|
|
@ -1,25 +1,23 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Setup & configure mutual TLS"
|
||||
linkTitle: "mTLS"
|
||||
title: "Setup & configure mTLS certificates"
|
||||
linkTitle: "Setup & configure mTLS certificates"
|
||||
weight: 1000
|
||||
description: "Encrypt communication between Dapr instances"
|
||||
description: "Encrypt communication between applications using self-signed or user supplied x.509 certificates"
|
||||
---
|
||||
|
||||
Dapr supports in-transit encryption of communication between Dapr instances using Sentry, a central Certificate Authority.
|
||||
Dapr supports in-transit encryption of communication between Dapr instances using the Dapr control plane, Sentry service, which is a central Certificate Authority (CA).
|
||||
|
||||
Dapr allows operators and developers to bring in their own certificates, or let Dapr automatically create and persist self signed root and issuer certificates.
|
||||
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.
|
||||
|
||||
For detailed information on mTLS, go to the concepts section [here]({{< ref "security-concept.md" >}}).
|
||||
For detailed information on mTLS, read the [security concepts section]({{< ref "security-concept.md" >}}).
|
||||
|
||||
If custom certificates have not been provided, Dapr will automatically create and persist self signed certs valid for one year.
|
||||
If custom certificates have not been provided, Dapr automatically creates 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.
|
||||
In Self Hosted mode, the certs are persisted to disk. More information on that is shown below.
|
||||
In self hosted mode, the certs are persisted to disk.
|
||||
|
||||
## Sentry configuration
|
||||
|
||||
mTLS settings reside in a Dapr configuration file.
|
||||
The following file shows all the available settings for mTLS in a configuration resource:
|
||||
## Control plane Sentry service configuration
|
||||
The mTLS settings reside in a Dapr control plane configuration file. For example when you deploy the Dapr control plane to Kubernetes this configuration file is automatically created and then you can edit this. The following file shows the available settings for mTLS in a configuration resource, deployed in the `daprsystem` namespace:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
|
|
@ -34,20 +32,20 @@ spec:
|
|||
allowedClockSkew: "15m"
|
||||
```
|
||||
|
||||
The file here shows the default `daprsystem` configuration settings. The examples below show you how to change and apply this configuration to Sentry in Kubernetes and Self hosted modes.
|
||||
The file here shows the default `daprsystem` configuration settings. The examples below show you how to change and apply this configuration to the control plane Sentry service either in Kubernetes and self hosted modes.
|
||||
|
||||
## Kubernetes
|
||||
|
||||
### Setting up mTLS with the configuration resource
|
||||
|
||||
In Kubernetes, Dapr creates a default configuration resource with mTLS enabled.
|
||||
Sentry, the certificate authority system pod, is installed both with Helm and with the Dapr CLI using `dapr init --kubernetes`.
|
||||
In Kubernetes, Dapr creates a default control plane configuration resource with mTLS enabled.
|
||||
The Sentry service, the certificate authority system pod, is installed both with Helm and with the Dapr CLI using `dapr init --kubernetes`.
|
||||
|
||||
You can view the configuration resource with the following command:
|
||||
You can view the control plane configuration resource with the following command:
|
||||
|
||||
`kubectl get configurations/daprsystem --namespace <DAPR_NAMESPACE> -o yaml`.
|
||||
|
||||
To make changes to the configuration resource, you can run the following command to edit it:
|
||||
To make changes to the control plane configuration resource, run the following command to edit it:
|
||||
|
||||
```
|
||||
kubectl edit configurations/daprsystem --namespace <DAPR_NAMESPACE>
|
||||
|
|
@ -61,7 +59,7 @@ kubectl rollout restart deploy/dapr-operator -n <DAPR_NAMESPACE>
|
|||
kubectl rollout restart statefulsets/dapr-placement-server -n <DAPR_NAMESPACE>
|
||||
```
|
||||
|
||||
*Note: the sidecar injector does not need to be redeployed*
|
||||
*Note: the control plane Sidecar Injector service does not need to be redeployed*
|
||||
|
||||
### Disabling mTLS with Helm
|
||||
|
||||
|
|
@ -83,7 +81,7 @@ dapr init --kubernetes --enable-mtls=false
|
|||
|
||||
### Viewing logs
|
||||
|
||||
In order to view Sentry logs, run the following command:
|
||||
In order to view the Sentry service logs, run the following command:
|
||||
|
||||
```
|
||||
kubectl logs --selector=app=dapr-sentry --namespace <DAPR_NAMESPACE>
|
||||
|
|
@ -91,7 +89,7 @@ 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 Sentry.
|
||||
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.
|
||||
|
||||
_Note: This example uses the OpenSSL command line tool, this is a widely distributed package, easily installed on Linux via the package manager. On Windows OpenSSL can be installed [using chocolatey](https://community.chocolatey.org/packages/openssl). On MacOS it can be installed using brew `brew install openssl`_
|
||||
|
||||
|
|
@ -154,7 +152,7 @@ helm install \
|
|||
dapr/dapr
|
||||
```
|
||||
|
||||
### Updating Root or Issuer Certs
|
||||
### Updating root or issuer certs
|
||||
|
||||
If the Root or Issuer certs are about to expire, you can update them and restart the required system services.
|
||||
|
||||
|
|
@ -176,29 +174,32 @@ The recommended way to do this is to perform a rollout restart of your deploymen
|
|||
```
|
||||
kubectl rollout restart deploy/myapp
|
||||
```
|
||||
### Kubernetes video demo
|
||||
Watch this video to show how to update mTLS certificates on Kubernetes
|
||||
|
||||
## Self-hosted
|
||||
<iframe width="1280" height="720" src="https://www.youtube.com/embed/_U9wJqq-H1g" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
||||
### Running Sentry system service
|
||||
## Self hosted
|
||||
### Running the control plane Sentry service
|
||||
|
||||
In order to run Sentry, you can either build from source, or download a release binary from [here](https://github.com/dapr/dapr/releases).
|
||||
In order to run the Sentry service, you can either build from source, or download a release binary from [here](https://github.com/dapr/dapr/releases).
|
||||
|
||||
When building from source, please refer to [this](https://github.com/dapr/dapr/blob/master/docs/development/developing-dapr.md#build-the-dapr-binaries) guide on how to build Dapr.
|
||||
|
||||
Second, create a directory for Sentry to create the self signed root certs:
|
||||
Second, create a directory for the Sentry service to create the self signed root certs:
|
||||
|
||||
```
|
||||
mkdir -p $HOME/.dapr/certs
|
||||
```
|
||||
|
||||
Run Sentry locally with the following command:
|
||||
Run the Sentry service locally with the following command:
|
||||
|
||||
```bash
|
||||
./sentry --issuer-credentials $HOME/.dapr/certs --trust-domain cluster.local
|
||||
```
|
||||
|
||||
If successful, sentry will run and create the root certs in the given directory.
|
||||
This command uses default configuration values as no custom config file was given. See below on how to start Sentry with a custom configuration.
|
||||
If successful, the Sentry service runs and create the root certs in the given directory.
|
||||
This command uses default configuration values as no custom config file was given. See below on how to start Sentry service with a custom configuration.
|
||||
|
||||
### Setting up mTLS with the configuration resource
|
||||
|
||||
|
|
@ -217,7 +218,7 @@ spec:
|
|||
enabled: true
|
||||
```
|
||||
|
||||
In addition to the Dapr configuration, you will also need to provide the TLS certificates to each Dapr sidecar instance. You can do so by setting the following environment variables before running the Dapr instance:
|
||||
In addition to the Dapr configuration, you also need to provide the TLS certificates to each Dapr sidecar instance. You can do so by setting the following environment variables before running the Dapr instance:
|
||||
|
||||
{{< tabs "Linux/MacOS" Windows >}}
|
||||
|
||||
|
|
@ -255,7 +256,7 @@ If using `daprd` directly, use the following flags to enable mTLS:
|
|||
daprd --app-id myapp --enable-mtls --sentry-address localhost:50001 --config=./config.yaml
|
||||
```
|
||||
|
||||
#### Sentry configuration
|
||||
#### Sentry service configuration
|
||||
|
||||
Here's an example of a configuration for Sentry that changes the workload cert TTL to 25 seconds:
|
||||
|
||||
|
|
@ -271,7 +272,7 @@ spec:
|
|||
workloadCertTTL: "25s"
|
||||
```
|
||||
|
||||
In order to start Sentry with a custom config, use the following flag:
|
||||
In order to start Sentry service with a custom config, use the following flag:
|
||||
|
||||
```
|
||||
./sentry --issuer-credentials $HOME/.dapr/certs --trust-domain cluster.local --config=./config.yaml
|
||||
|
|
@ -280,9 +281,9 @@ In order to start Sentry with a custom config, use the following flag:
|
|||
### Bringing your own certificates
|
||||
|
||||
In order to provide your own credentials, create ECDSA PEM encoded root and issuer certificates and place them on the file system.
|
||||
Tell Sentry where to load the certificates from using the `--issuer-credentials` flag.
|
||||
Tell the Sentry service where to load the certificates from using the `--issuer-credentials` flag.
|
||||
|
||||
The next examples creates root and issuer certs and loads them with Sentry.
|
||||
The next examples creates root and issuer certs and loads them with the Sentry service.
|
||||
|
||||
*Note: This example uses the step tool to create the certificates. You can install step tool from [here](https://smallstep.com/docs/getting-started/). Windows binaries available [here](https://github.com/smallstep/cli/releases)*
|
||||
|
||||
|
|
@ -305,7 +306,7 @@ Place `ca.crt`, `issuer.crt` and `issuer.key` in a desired path (`$HOME/.dapr/ce
|
|||
./sentry --issuer-credentials $HOME/.dapr/certs --trust-domain cluster.local
|
||||
```
|
||||
|
||||
### Updating Root or Issuer Certs
|
||||
### Updating root or issuer certificates
|
||||
|
||||
If the Root or Issuer certs are about to expire, you can update them and restart the required system services.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Configure API authorization with OAuth"
|
||||
linkTitle: "OAuth"
|
||||
title: "Configure endpoint authorization with OAuth"
|
||||
linkTitle: "Configure endpoint authorization with OAuth"
|
||||
weight: 2000
|
||||
description: "Enable OAUTH authorization on Dapr endpoints for your web APIs"
|
||||
description: "Enable OAuth authorization on application endpoints for your web APIs"
|
||||
---
|
||||
|
||||
Dapr OAuth 2.0 [middleware]({{< ref "middleware.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).
|
||||
You can also inject authorization tokens into your endpoint 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.
|
||||
|
||||
The main difference between the two flows is that the `Authorization Code Grant flow` needs user interaction and authorizes a user where the `Client Credentials Grant flow` doesn't need a user interaction and authorizes a service/application.
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 241 KiB After Width: | Height: | Size: 156 KiB |
Loading…
Reference in New Issue