<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Securing Dapr deployments on Dapr Docs</title><link>https://v1-18.docs.dapr.io/operations/security/</link><description>Recent content in Securing Dapr deployments on Dapr Docs</description><generator>Hugo</generator><language>en</language><atom:link href="https://v1-18.docs.dapr.io/operations/security/index.xml" rel="self" type="application/rss+xml"/><item><title>Setup &amp; configure mTLS certificates</title><link>https://v1-18.docs.dapr.io/operations/security/mtls/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://v1-18.docs.dapr.io/operations/security/mtls/</guid><description>&lt;p>Dapr supports in-transit encryption of communication between Dapr instances using the Dapr control plane, Sentry service, which is a central Certificate Authority (CA).&lt;/p>
&lt;p>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.&lt;/p>
&lt;p>For detailed information on mTLS, read the &lt;a href="https://v1-18.docs.dapr.io/concepts/security-concept/">security concepts section&lt;/a>.&lt;/p>
&lt;p>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.&lt;/p></description></item><item><title>Configure endpoint authorization with OAuth</title><link>https://v1-18.docs.dapr.io/operations/security/oauth/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://v1-18.docs.dapr.io/operations/security/oauth/</guid><description>&lt;p>Dapr OAuth 2.0 &lt;a href="https://v1-18.docs.dapr.io/operations/components/middleware/">middleware&lt;/a> allows you to enable &lt;a href="https://oauth.net/2/">OAuth&lt;/a> authorization on Dapr endpoints for your web APIs using the &lt;a href="https://tools.ietf.org/html/rfc6749#section-4.1">Authorization Code Grant flow&lt;/a>.
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 &lt;a href="https://tools.ietf.org/html/rfc6749#section-4.4">Client Credentials Grant flow&lt;/a>.
When the middleware is enabled any method invocation through Dapr needs to be authorized before getting passed to the user code.&lt;/p>
&lt;p>The main difference between the two flows is that the &lt;code>Authorization Code Grant flow&lt;/code> needs user interaction and authorizes a user where the &lt;code>Client Credentials Grant flow&lt;/code> doesn&amp;rsquo;t need a user interaction and authorizes a service/application.&lt;/p></description></item><item><title>Enable API token authentication in Dapr</title><link>https://v1-18.docs.dapr.io/operations/security/api-token/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://v1-18.docs.dapr.io/operations/security/api-token/</guid><description>&lt;p>By default, Dapr relies on the network boundary to limit access to its public API. If you plan on exposing the Dapr API outside of that boundary, or if your deployment demands an additional level of security, consider enabling the token authentication for Dapr APIs. This will cause Dapr to require every incoming gRPC and HTTP request for its APIs for to include authentication token, before allowing that request to pass through.&lt;/p></description></item><item><title>Authenticate requests from Dapr using token authentication</title><link>https://v1-18.docs.dapr.io/operations/security/app-api-token/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://v1-18.docs.dapr.io/operations/security/app-api-token/</guid><description>&lt;p>For some building blocks such as pub/sub, service invocation and input bindings, Dapr communicates with an app over HTTP or gRPC.
To enable the application to authenticate requests that are arriving from the Dapr sidecar, you can configure Dapr to send an API token as a header (in HTTP requests) or metadata (in gRPC requests).&lt;/p>
&lt;h2 id="create-a-token">Create a token&lt;/h2>
&lt;p>Dapr uses shared tokens for API authentication. You are free to define the API token to use.&lt;/p></description></item></channel></rss>