Skip to content

Commit

Permalink
Tech writing touch-ups (#1556)
Browse files Browse the repository at this point in the history
Co-authored-by: Aaron Crawfis <[email protected]>
  • Loading branch information
voipengineer and AaronCrawfis authored Jun 14, 2021
1 parent ae5b222 commit 3513781
Showing 1 changed file with 19 additions and 21 deletions.
40 changes: 19 additions & 21 deletions daprdocs/content/en/concepts/security-concept.md
Original file line number Diff line number Diff line change
Expand Up @@ -20,7 +20,7 @@ Dapr enables mTLS and all the features described in this document in your applic

## Sidecar-to-app 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 user with API level authentication using tokens. This feature guarantees that even on localhost, only an authenticated caller may call into Dapr.
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.

## Sidecar-to-sidecar communication

Expand All @@ -29,20 +29,20 @@ To achieve this, Dapr leverages a system service named `Sentry` which acts as a

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

When root certs are replaced (secret in Kubernetes mode and filesystem for self hosted mode), the Sentry picks them up and re-builds the trust chain without needing to restart, with zero downtime to Sentry.
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 to and is only accessible by the Dapr system pods.
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.

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 >}}).
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
Expand All @@ -58,13 +58,13 @@ The diagram below shows how the Sentry system service issues certificates for ap

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.

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 filesystem path.
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.

In Kubernetes, when the Dapr system services start, they automatically mount the secret containing the root and issuer certs and use those to secure the gRPC server that is used by the Dapr sidecar.
In Kubernetes, when Dapr system services start, they automatically mount the secret containing the root and issuer certs and use those to secure the gRPC server that is used by the Dapr sidecar.

In self hosted mode, each system service can be mounted to a filesystem path to get the credentials.
In self-hosted mode, each system service can be mounted to a filesystem path to get the credentials.

When the Dapr sidecar initializes, it authenticates with the system pods using the mounted leaf certificates and issuer private key. these are mounted as environment variables on the sidecar container.
When the Dapr sidecar initializes, it authenticates with the system pods using the mounted leaf certificates and issuer private key. These are mounted as environment variables on the sidecar container.

### mTLS to system services in Kubernetes
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
Expand All @@ -77,13 +77,11 @@ Dapr components are namespaced. That means a Dapr runtime sidecar instance can o

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.

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">}}).
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">}}).

## Network security

You can adopt common network security technologies such as network security groups (NSGs), demilitarized zones (DMZs) and firewalls to provide layers of protections 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.
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

Expand All @@ -95,7 +93,7 @@ Dapr doesn't transform the state data from applications. This means Dapr doesn't

Dapr does not store any data at rest.

Dapr uses the configured authentication method to authenticate with the underlying state store. And many state store implementations use official client libraries that generally use secured communication channels with the servers.
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.

## Management security

Expand All @@ -104,18 +102,18 @@ When deploying on Kubernetes, you can use regular [Kubernetes RBAC]( https://kub
When deploying on Azure Kubernetes Service (AKS), you can use [Azure Active Directory (AD) service principals]( https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) to control access to management activities and resource management.

## Threat model
Threat modeling is a process by which potential threats, such as structural vulnerabilities or the absence of appropriate safeguards, can be identified, enumerated, and mitigations can be prioritized. The Dapr threat model is below.
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>

## Security audit

### February 2021

In February 2021, Dapr has gone through a 2nd security audit targetting it's 1.0 release by Cure53.
In February 2021, Dapr went through a 2nd security audit targeting it's 1.0 release by Cure53.
The test focused on the following:

* Dapr runtime code base evaluation since last audit
* Dapr runtime codebase evaluation since last audit
* Access control lists
* Secrets management
* Penetration testing
Expand All @@ -128,12 +126,12 @@ As of February 16th 2021, Dapr has 0 criticals, 0 highs, 0 mediums, 2 lows, 2 in

### June 2020

In June 2020, Dapr has undergone a security audit from Cure53, a CNCF approved cybersecurity firm.
In June 2020, Dapr underwent a security audit from Cure53, a CNCF-approved cybersecurity firm.
The test focused on the following:

* Dapr runtime code base evaluation
* Dapr components code base evaluation
* Dapr CLI code base evaluation
* Dapr runtime codebase evaluation
* Dapr components codebase evaluation
* Dapr CLI codebase evaluation
* Privilege escalation
* Traffic spoofing
* Secrets management
Expand Down

0 comments on commit 3513781

Please sign in to comment.