Additional clarifications

This commit is contained in:
Aaron Schlesinger 2020-06-05 16:10:34 -07:00
parent 9793cfd251
commit 1da68e34e2
2 changed files with 16 additions and 14 deletions

View File

@ -1,14 +1,14 @@
# Bindings
Dapr provides a mechanism that can either (a) trigger your app in response to an event or (b) trigger an external system when your app does something.
For example, bindings allow your microservice to respond to incoming Twilio/SMS messages without adding/configuring a third-party Twilio SDK, worrying about polling from Twilio (or doing websockets, etc...).
Dapr provides a mechanism that can either trigger your app with events coming in from external systems, or invoke external systems.
Bindings give you some additional advantages:
* Handle retries and failure recovery
* Switch between bindings at runtime time
* Enable portable applications where environment-specific bindings are set-up and no code changes are required
* Your code doesn't have to deal with the complexities of connecting to, and polling from, messaging systems such as queues, message buses, etc...
* You can focus on business logic and not the implementation details of how interact with a system
* You can keep your code free from SDKs or libraries
For a specific example, bindings allow your microservice to respond to incoming Twilio/SMS messages without adding/configuring a third-party Twilio SDK, worrying about polling from Twilio (or doing websockets, etc...).
Bindings are developed independently of Dapr runtime. You can view and contribute to the bindings [here](https://github.com/dapr/components-contrib/tree/master/bindings).

View File

@ -1,13 +1,6 @@
# Security
End-to-end encryption for communication between microservices is generally a best practice, but it's also hard to set up. A common way to secure microservice inter-communication is to use [mutual authentication TLS](https://en.wikipedia.org/wiki/Mutual_authentication) or mTLS. `mTLS` offers a few key features for network traffic inside your app:
- Two way authentication - the client proving its identify 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 supports mTLS in your application with a variety of different deployments, all without adding any code to your application, and usually without complex configuration inside your production systems:
Security is a general term in Dapr that encompasses several important features that your microservices automatically takes advantage of:
- [Sidecar-to-App Communication](#sidecar-to-app-communication)
- [Sidecar-to-Sidecar Communication](#sidecar-to-sidecar-communication)
@ -18,6 +11,15 @@ Dapr supports mTLS in your application with a variety of different deployments,
- [State Store Security](#state-store-security)
- [Management Security](#management-security)
Many (but not all) of these security features centralize around encryption, which is a way to secure data. One of the security mechanisms that Dapr employs is called [mutual authentication TLS](https://en.wikipedia.org/wiki/Mutual_authentication) or mTLS. `mTLS` offers a few key features for network traffic inside your app:
- Two way authentication - the client proving its identify 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
## Sidecar-to-App communication
The Dapr sidecar runs close to the application through **localhost**. Dapr assumes it runs in the same security domain of the application. As a result, there are no authentication, authorization or encryption between a Dapr sidecar and the application.