mirror of https://github.com/dapr/docs.git
Update configuration section (#854)
* Enable robots, Update versions, add links * Update left column minimum width * Add Dapr docs image * Update spacing for list pages * Add home image * Update hosting references * Remove extra width * Add favicons * Update configuration section * Fix configuration reference
This commit is contained in:
Aaron Crawfis
GitHub
parent
91f08d7a39
commit
1502710ab1
|
|
@ -1,88 +0,0 @@
|
|||
# Limit the secrets that can be read from secret stores
|
||||
|
||||
Follow [these instructions](../setup-secret-store) to configure secret store for an application. Once configured, any secret defined within that store will be accessible from the Dapr application.
|
||||
|
||||
To limit the secrets to which the Dapr application has access, users can define secret scopes by augmenting existing configuration CRD with restrictive permissions.
|
||||
|
||||
Follow [these instructions](../../concepts/configuration/README.md) to define a configuration CRD.
|
||||
|
||||
## Scenario 1 : Deny access to all secrets for a secret store
|
||||
|
||||
In Kubernetes cluster, the native Kubernetes secret store is added to Dapr application by default. In some scenarios it may be necessary to deny access to Dapr secrets for a given application. To add this configuration follow the steps below:
|
||||
|
||||
Define the following `appconfig.yaml` and apply it to the Kubernetes cluster using the command `kubectl apply -f appconfig.yaml`.
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Configuration
|
||||
metadata:
|
||||
name: appconfig
|
||||
spec:
|
||||
secrets:
|
||||
scopes:
|
||||
- storeName: kubernetes
|
||||
defaultAccess: deny
|
||||
```
|
||||
|
||||
For applications that need to be deined access to the Kubernetes secret store, follow [these instructions](../configure-k8s/README.md), and add the following annotation to the application pod.
|
||||
|
||||
```yaml
|
||||
dapr.io/config: appconfig
|
||||
```
|
||||
|
||||
With this defined, the application no longer has access to Kubernetes secret store.
|
||||
|
||||
## Scenario 2 : Allow access to only certain secrets in a secret store
|
||||
|
||||
To allow a Dapr application to have access to only certain secrets, define the following `config.yaml`:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Configuration
|
||||
metadata:
|
||||
name: appconfig
|
||||
spec:
|
||||
secrets:
|
||||
scopes:
|
||||
- storeName: vault
|
||||
defaultAccess: deny
|
||||
allowedSecrets: ["secret1", "secret2"]
|
||||
```
|
||||
|
||||
This example defines configuration for secret store named vault. The default access to the secret store is `deny`, whereas some secrets are accessible by the application based on the `allowedSecrets` list. Follow [these instructions](../../concepts/configuration/README.md) to apply configuration to the sidecar.
|
||||
|
||||
## Scenario 3: Deny access to certain senstive secrets in a secret store
|
||||
|
||||
Define the following `config.yaml`:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Configuration
|
||||
metadata:
|
||||
name: appconfig
|
||||
spec:
|
||||
secrets:
|
||||
scopes:
|
||||
- storeName: vault
|
||||
defaultAccess: allow # this is the default value, line can be omitted
|
||||
deniedSecrets: ["secret1", "secret2"]
|
||||
```
|
||||
|
||||
The above configuration explicitly denies access to `secret1` and `secret2` from the secret store named vault while allowing access to all other secrets. Follow [these instructions](../../concepts/configuration/README.md) to apply configuration to the sidecar.
|
||||
|
||||
## Permission priority
|
||||
|
||||
The `allowedSecrets` and `deniedSecrets` list values take priorty over the `defaultAccess`.
|
||||
|
||||
Scenarios | defaultAccess | allowedSecrets | deniedSecrets | permission
|
||||
---- | ------- | -----------| ----------| ------------
|
||||
1 - Only default access | deny/allow | empty | empty | deny/allow
|
||||
2 - Default deny with allowed list | deny | ["s1"] | empty | only "s1" can be accessed
|
||||
3 - Default allow with deneied list | allow | empty | ["s1"] | only "s1" cannot be accessed
|
||||
4 - Default allow with allowed list | allow | ["s1"] | empty | only "s1" can be accessed
|
||||
5 - Default deny with denied list | deny | empty | ["s1"] | deny
|
||||
6 - Default deny/allow with both lists | deny/allow | ["s1"] | ["s2"] | only "s1" can be accessed
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
---
|
||||
title: "Configuration"
|
||||
linkTitle: "Configuration"
|
||||
weight: 400
|
||||
description: "Change the behavior of Dapr sidecars or globally on Dapr system services"
|
||||
---
|
||||
|
||||
Dapr configurations are settings that enable you to change the behavior of individual Dapr application sidecars or globally on the system services in the Dapr control plane.
|
||||
An example of a per Dapr application sidecar setting is configuring trace settings. An example of a Dapr control plane setting is mutual TLS which is a global setting on the Sentry system service.
|
||||
|
||||
Read [this page]({{< ref "configuration-overview.md" >}}) for a list of all configuration options.
|
||||
|
|
@ -1,263 +0,0 @@
|
|||
---
|
||||
title: "Configuration"
|
||||
linkTitle: "Configuration"
|
||||
weight: 400
|
||||
description: "Change the behavior of Dapr sidecars or globally on Dapr system services"
|
||||
---
|
||||
|
||||
Dapr configurations are settings that enable you to change the behavior of individual Dapr application sidecars or globally on the system services in the Dapr control plane.
|
||||
An example of a per Dapr application sidecar setting is configuring trace settings. An example of a Dapr control plane setting is mutual TLS which is a global setting on the Sentry system service.
|
||||
|
||||
## Setting self hosted sidecar configuration
|
||||
In self hosted mode the Dapr configuration is a configuration file, for example `config.yaml`. By default the Dapr sidecar looks in the default Dapr folder for the runtime configuration eg: `$HOME/.dapr/config.yaml` in Linux/MacOS and `%USERPROFILE%\.dapr\config.yaml` in Windows.
|
||||
|
||||
A Dapr sidecar can also apply a configuration by using a ```--config``` flag to the file path with ```dapr run``` CLI command.
|
||||
|
||||
## Setting Kubernetes sidecar configuration
|
||||
In Kubernetes mode the Dapr configuration is a Configuration CRD, that is applied to the cluster. For example;
|
||||
|
||||
```cli
|
||||
kubectl apply -f myappconfig.yaml
|
||||
```
|
||||
|
||||
You can use the Dapr CLI to list the Configuration CRDs
|
||||
|
||||
```cli
|
||||
dapr configurations -k
|
||||
```
|
||||
|
||||
A Dapr sidecar can apply a specific configuration by using a ```dapr.io/config``` annotation. For example:
|
||||
|
||||
```yml
|
||||
annotations:
|
||||
dapr.io/enabled: "true"
|
||||
dapr.io/app-id: "nodeapp"
|
||||
dapr.io/app-port: "3000"
|
||||
dapr.io/config: "myappconfig"
|
||||
```
|
||||
Note: There are more [Kubernetes annotations](../../howto/configure-k8s/README.md) available to configure the Dapr sidecar on activation by sidecar Injector system service.
|
||||
|
||||
## Sidecar configuration settings
|
||||
|
||||
The following configuration settings can be applied to Dapr application sidecars;
|
||||
- [Tracing](#tracing)
|
||||
- [Middleware](#middleware)
|
||||
- [Scoping secrets for secret stores](#scoping-secrets-for-secret-stores)
|
||||
- [Access control allow lists for service invocation](#access-control-allow-lists-for-service-invocation)
|
||||
- [Example application sidecar configuration](#example-application-sidecar-configuration)
|
||||
|
||||
### Tracing
|
||||
|
||||
Tracing configuration turns on tracing for an application.
|
||||
|
||||
The `tracing` section under the `Configuration` spec contains the following properties:
|
||||
|
||||
```yml
|
||||
tracing:
|
||||
samplingRate: "1"
|
||||
```
|
||||
|
||||
The following table lists the properties for tracing:
|
||||
|
||||
Property | Type | Description
|
||||
---- | ------- | -----------
|
||||
samplingRate | string | Set sampling rate for tracing to be enabled or disabled.
|
||||
|
||||
|
||||
`samplingRate` is used to enable or disable the tracing. To disable the sampling rate ,
|
||||
set `samplingRate : "0"` in the configuration. The valid range of samplingRate is between 0 and 1 inclusive. The sampling rate determines whether a trace span should be sampled or not based on value. `samplingRate : "1"` samples all traces. By default, the sampling rate is (0.0001) or 1 in 10,000 traces.
|
||||
|
||||
See [Observability distributed tracing](../observability/traces.md) for more information
|
||||
|
||||
### Middleware
|
||||
|
||||
Middleware configuration set named Http pipeline middleware handlers
|
||||
The `httpPipeline` section under the `Configuration` spec contains the following properties:
|
||||
|
||||
```yml
|
||||
httpPipeline:
|
||||
handlers:
|
||||
- name: oauth2
|
||||
type: middleware.http.oauth2
|
||||
- name: uppercase
|
||||
type: middleware.http.uppercase
|
||||
```
|
||||
|
||||
The following table lists the properties for HTTP handlers:
|
||||
|
||||
Property | Type | Description
|
||||
---- | ------- | -----------
|
||||
name | string | name of the middleware component
|
||||
type | string | type of middleware component
|
||||
|
||||
See [Middleware pipelines](../middleware/README.md) for more information
|
||||
|
||||
### Scoping secrets for secret stores
|
||||
|
||||
In addition to scoping which applications can access a given component, for example a secret store component (see [Scoping components](../../howto/components-scopes)), a named secret store component itself can be scoped to one or more secrets for an application. By defining `allowedSecrets` and/or `deniedSecrets` list, applications can be restricted to access only specific secrets.
|
||||
|
||||
The `secrets` section under the `Configuration` spec contains the following properties:
|
||||
|
||||
```yml
|
||||
secrets:
|
||||
scopes:
|
||||
- storeName: kubernetes
|
||||
defaultAccess: allow
|
||||
allowedSecrets: ["redis-password"]
|
||||
- storeName: localstore
|
||||
defaultAccess: allow
|
||||
deniedSecrets: ["redis-password"]
|
||||
```
|
||||
|
||||
The following table lists the properties for secret scopes:
|
||||
|
||||
Property | Type | Description
|
||||
---- | ------- | -----------
|
||||
storeName | string | name of the secret store component. storeName must be unique within the list
|
||||
defaultAccess | string | access modifier. Accepted values "allow" (default) or "deny"
|
||||
allowedSecrets | list | list of secret keys that can be accessed
|
||||
deniedSecrets | list | list of secret keys that cannot be accessed
|
||||
|
||||
When an `allowedSecrets` list is present with at least one element, only those secrets defined in the list can be accessed by the application.
|
||||
|
||||
See the [Scoping secrets](../../howto/secrets-scopes/README.md) HowTo for examples on how to scope secrets to an application.
|
||||
|
||||
### Access Control allow lists for service invocation
|
||||
Access control enables the configuration of policies that restrict what operations *calling* applications can perform, via service invocation, on the *called* application.
|
||||
An access control policy is specified in configuration and be applied to Dapr sidecar for the *called* application. Example access policies are shown below and access to the called app is based on the matched policy action. You can provide a default global action for all calling applications and if no access control policy is specified, the default behavior is to allow all calling applicatons to access to the called app.
|
||||
|
||||
## Concepts
|
||||
**TrustDomain** - A "trust domain" is a logical group to manage trust relationships. Every application is assigned a trust domain which can be specified in the access control list policy spec. If no policy spec is defined or an empty trust domain is specified, then a default value "public" is used. This trust domain is used to generate the identity of the application in the TLS cert.
|
||||
|
||||
**App Identity** - Dapr generates a [SPIFFE](https://spiffe.io/) id for all applications which is attached in the TLS cert. The SPIFFE id is of the format: **spiffe://\<trustdomain>/ns/\<namespace\>/\<appid\>**. For matching policies, the trust domain, namespace and app ID values of the calling app are extracted from the SPIFFE id in the TLS cert of the calling app. These values are matched against the trust domain, namespace and app ID values specified in the policy spec. If all three of these match, then more specific policies are further matched.
|
||||
|
||||
```
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Configuration
|
||||
metadata:
|
||||
name: appconfig
|
||||
spec:
|
||||
accessControl:
|
||||
defaultAction: deny --> Global default action in case no other policy is matched
|
||||
trustDomain: "public" --> The called application is assigned a trust domain and is used to generate the identity of this app in the TLS certificate.
|
||||
policies:
|
||||
- appId: app1 --> AppId of the calling app to allow/deny service invocation from
|
||||
defaultAction: deny --> App level default action in case the app is found but no specific operation is matched
|
||||
trustDomain: 'public' --> Trust domain of the calling app is matched against the specified value here.
|
||||
namespace: "default" --> Namespace of the calling app is matched against the specified value here.
|
||||
operations:
|
||||
- name: /op1 --> operation name on the called app
|
||||
httpVerb: ['POST', 'GET'] --> specific http verbs, unused for grpc invocation
|
||||
action: deny --> allow/deny access
|
||||
- name: /op2/* --> operation name with a postfix
|
||||
httpVerb: ["*"] --> wildcards can be used to match any http verb
|
||||
action: allow
|
||||
- appId: app2
|
||||
defaultAction: allow
|
||||
trustDomain: "public"
|
||||
namespace: "default"
|
||||
operations:
|
||||
- name: /op3
|
||||
httpVerb: ['POST', 'PUT']
|
||||
action: deny
|
||||
```
|
||||
|
||||
The following tables lists the different properties for access control, policies and operations:
|
||||
|
||||
Access Control
|
||||
Property | Type | Description
|
||||
---- | ------- | -----------
|
||||
defaultAction | string | Global default action when no other policy is matched
|
||||
trustDomain | string | Trust domain assigned to the application. Default is "public".
|
||||
policies | string | Policies to determine what operations the calling app can do on the called app
|
||||
|
||||
Policies
|
||||
Property | Type | Description
|
||||
---- | ------- | -----------
|
||||
app | string | AppId of the calling app to allow/deny service invocation from
|
||||
namespace | string | Namespace value that needs to be matched with the namespace of the calling app
|
||||
trustDomain | string | Trust domain that needs to be matched with the trust domain of the calling app. Default is "public"
|
||||
defaultAction | string | App level default action in case the app is found but no specific operation is matched
|
||||
operations | string | operations that are allowed from the calling app
|
||||
|
||||
Operations
|
||||
Property | Type | Description
|
||||
---- | ------- | -----------
|
||||
name | string | Path name of the operations allowed on the called app. Wildcard "\*" can be used to under a path to match
|
||||
httpVerb | list | list specific http verbs that can be used by the calling app. Wildcard "\*" can be used to match any http verb. Unused for grpc invocation
|
||||
action | string | Access modifier. Accepted values "allow" (default) or "deny"
|
||||
|
||||
See the [Allow lists for service invocation](../../howto/allowlists-serviceinvocation/README.md) HowTo for examples on how to set allow lists.
|
||||
|
||||
### Example application sidecar configuration
|
||||
The following yaml shows an example configuration file that can be applied to an applications' Dapr sidecar.
|
||||
|
||||
```yml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Configuration
|
||||
metadata:
|
||||
name: myappconfig
|
||||
namespace: default
|
||||
spec:
|
||||
tracing:
|
||||
samplingRate: "1"
|
||||
httpPipeline:
|
||||
handlers:
|
||||
- name: oauth2
|
||||
type: middleware.http.oauth2
|
||||
secrets:
|
||||
scopes:
|
||||
- storeName: localstore
|
||||
defaultAccess: allow
|
||||
deniedSecrets: ["redis-password"]
|
||||
accessControl:
|
||||
defaultAction: deny
|
||||
trustDomain: "public"
|
||||
policies:
|
||||
- appId: app1
|
||||
defaultAction: deny
|
||||
trustDomain: 'public'
|
||||
namespace: "default"
|
||||
operations:
|
||||
- name: /op1
|
||||
httpVerb: ['POST', 'GET']
|
||||
action: deny
|
||||
- name: /op2/*
|
||||
httpVerb: ["*"]
|
||||
action: allow
|
||||
```
|
||||
|
||||
## Setting Kubernetes control plane configuration
|
||||
There is a single configuration file called `default` installed with the Dapr control plane system services that applies global settings. This is set up when Dapr is deployed to Kubernetes
|
||||
|
||||
## Control plane configuration settings
|
||||
A Dapr control plane configuration can configure the following settings:
|
||||
|
||||
Property | Type | Description
|
||||
---- | ------- | -----------
|
||||
enabled | bool | Set mtls to be enabled or disabled
|
||||
allowedClockSkew | string | The extra time to give for certificate expiry based on possible clock skew on a machine. Default is 15 minutes.
|
||||
workloadCertTTL | string | Time a certificate is valid for. Default is 24 hours
|
||||
|
||||
See the [Mutual TLS](../../howto/configure-mtls/README.md) HowTo and [security concepts](../security/README.md) for more information.
|
||||
|
||||
### Example control plane configuration
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Configuration
|
||||
metadata:
|
||||
name: default
|
||||
namespace: default
|
||||
spec:
|
||||
mtls:
|
||||
enabled: true
|
||||
allowedClockSkew: 15m
|
||||
workloadCertTTL: 24h
|
||||
```
|
||||
|
||||
## References
|
||||
* [Distributed tracing](../observability/traces.md)
|
||||
* [Middleware pipelines](../middleware/README.md)
|
||||
* [Security](../security/README.md)
|
||||
* [How-To: Configuring the Dapr sidecar on Kubernetes](../../howto/configure-k8s/README.md)
|
||||
|
|
@ -0,0 +1,169 @@
|
|||
---
|
||||
title: "Overview of Dapr configuration options"
|
||||
linkTitle: "Overview"
|
||||
weight: 100
|
||||
description: "Information on Dapr configuration and how to set options for your application"
|
||||
---
|
||||
|
||||
## Sidecar configuration
|
||||
|
||||
### Setup sidecar configuration
|
||||
|
||||
#### Self-hosted sidecar
|
||||
In self hosted mode the Dapr configuration is a configuration file, for example `config.yaml`. By default the Dapr sidecar looks in the default Dapr folder for the runtime configuration eg: `$HOME/.dapr/config.yaml` in Linux/MacOS and `%USERPROFILE%\.dapr\config.yaml` in Windows.
|
||||
|
||||
A Dapr sidecar can also apply a configuration by using a ```--config``` flag to the file path with ```dapr run``` CLI command.
|
||||
|
||||
#### Kubernetes sidecar
|
||||
In Kubernetes mode the Dapr configuration is a Configuration CRD, that is applied to the cluster. For example;
|
||||
|
||||
```bash
|
||||
kubectl apply -f myappconfig.yaml
|
||||
```
|
||||
|
||||
You can use the Dapr CLI to list the Configuration CRDs
|
||||
|
||||
```bash
|
||||
dapr configurations -k
|
||||
```
|
||||
|
||||
A Dapr sidecar can apply a specific configuration by using a ```dapr.io/config``` annotation. For example:
|
||||
|
||||
```yml
|
||||
annotations:
|
||||
dapr.io/enabled: "true"
|
||||
dapr.io/app-id: "nodeapp"
|
||||
dapr.io/app-port: "3000"
|
||||
dapr.io/config: "myappconfig"
|
||||
```
|
||||
Note: There are more [Kubernetes annotations]({{< ref "kubernetes-annotations.md" >}}) available to configure the Dapr sidecar on activation by sidecar Injector system service.
|
||||
|
||||
### Sidecar configuration settings
|
||||
|
||||
The following configuration settings can be applied to Dapr application sidecars;
|
||||
- [Tracing](#tracing)
|
||||
- [Middleware](#middleware)
|
||||
- [Scoping secrets for secret stores](#scoping-secrets-for-secret-stores)
|
||||
- [Access control allow lists for service invocation](#access-control-allow-lists-for-service-invocation)
|
||||
- [Example application sidecar configuration](#example-application-sidecar-configuration)
|
||||
|
||||
#### Tracing
|
||||
|
||||
Tracing configuration turns on tracing for an application.
|
||||
|
||||
The `tracing` section under the `Configuration` spec contains the following properties:
|
||||
|
||||
```yml
|
||||
tracing:
|
||||
samplingRate: "1"
|
||||
```
|
||||
|
||||
The following table lists the properties for tracing:
|
||||
|
||||
| Property | Type | Description |
|
||||
|--------------|--------|-------------|
|
||||
| samplingRate | string | Set sampling rate for tracing to be enabled or disabled.
|
||||
|
||||
|
||||
`samplingRate` is used to enable or disable the tracing. To disable the sampling rate ,
|
||||
set `samplingRate : "0"` in the configuration. The valid range of samplingRate is between 0 and 1 inclusive. The sampling rate determines whether a trace span should be sampled or not based on value. `samplingRate : "1"` samples all traces. By default, the sampling rate is (0.0001) or 1 in 10,000 traces.
|
||||
|
||||
See [Observability distributed tracing]({{< ref "tracing.md" >}}) for more information
|
||||
|
||||
#### Middleware
|
||||
|
||||
Middleware configuration set named Http pipeline middleware handlers
|
||||
The `httpPipeline` section under the `Configuration` spec contains the following properties:
|
||||
|
||||
```yml
|
||||
httpPipeline:
|
||||
handlers:
|
||||
- name: oauth2
|
||||
type: middleware.http.oauth2
|
||||
- name: uppercase
|
||||
type: middleware.http.uppercase
|
||||
```
|
||||
|
||||
The following table lists the properties for HTTP handlers:
|
||||
|
||||
| Property | Type | Description |
|
||||
|----------|--------|-------------|
|
||||
| name | string | Name of the middleware component
|
||||
| type | string | Type of middleware component
|
||||
|
||||
See [Middleware pipelines]({{< ref "middleware-concept.md" >}}) for more information
|
||||
|
||||
#### Scope secret store access
|
||||
|
||||
See the [Scoping secrets]({{< ref "secret-scope.md" >}}) guide for information and examples on how to scope secrets to an application.
|
||||
|
||||
#### Access Control allow lists for service invocation
|
||||
|
||||
See the [Allow lists for service invocation]({{< ref "invoke-allowlist.md" >}}) guide for information and examples on how to set allow lists.
|
||||
|
||||
### Example sidecar configuration
|
||||
The following yaml shows an example configuration file that can be applied to an applications' Dapr sidecar.
|
||||
|
||||
```yml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Configuration
|
||||
metadata:
|
||||
name: myappconfig
|
||||
namespace: default
|
||||
spec:
|
||||
tracing:
|
||||
samplingRate: "1"
|
||||
httpPipeline:
|
||||
handlers:
|
||||
- name: oauth2
|
||||
type: middleware.http.oauth2
|
||||
secrets:
|
||||
scopes:
|
||||
- storeName: localstore
|
||||
defaultAccess: allow
|
||||
deniedSecrets: ["redis-password"]
|
||||
accessControl:
|
||||
defaultAction: deny
|
||||
trustDomain: "public"
|
||||
policies:
|
||||
- appId: app1
|
||||
defaultAction: deny
|
||||
trustDomain: 'public'
|
||||
namespace: "default"
|
||||
operations:
|
||||
- name: /op1
|
||||
httpVerb: ['POST', 'GET']
|
||||
action: deny
|
||||
- name: /op2/*
|
||||
httpVerb: ["*"]
|
||||
action: allow
|
||||
```
|
||||
|
||||
## Control-plane configuration
|
||||
There is a single configuration file called `default` installed with the Dapr control plane system services that applies global settings. This is only set up when Dapr is deployed to Kubernetes.
|
||||
|
||||
### Control-plane configuration settings
|
||||
A Dapr control plane configuration can configure the following settings:
|
||||
|
||||
| Property | Type | Description |
|
||||
|------------------|--------|-------------|
|
||||
| enabled | bool | Set mtls to be enabled or disabled
|
||||
| allowedClockSkew | string | The extra time to give for certificate expiry based on possible clock skew on a machine. Default is 15 minutes.
|
||||
| workloadCertTTL | string | Time a certificate is valid for. Default is 24 hours
|
||||
|
||||
See the [Mutual TLS]({{< ref "mtls.md" >}}) HowTo and [security concepts]({{< ref "security-concept.md" >}}) for more information.
|
||||
|
||||
### Example control plane configuration
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Configuration
|
||||
metadata:
|
||||
name: default
|
||||
namespace: default
|
||||
spec:
|
||||
mtls:
|
||||
enabled: true
|
||||
allowedClockSkew: 15m
|
||||
workloadCertTTL: 24h
|
||||
```
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: "Control concurrency and rate limit applications"
|
||||
linkTitle: "Concurrency & rate limits"
|
||||
weight: 1000
|
||||
weight: 2000
|
||||
description: "Control how many requests and events will invoke your application simultaneously"
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: "Configure Dapr to use gRPC"
|
||||
linkTitle: "Use gRPC interface"
|
||||
weight: 3000
|
||||
weight: 5000
|
||||
description: "How to configure Dapr to use gRPC for low-latency, high performance scenarios"
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,23 +1,49 @@
|
|||
---
|
||||
title: "Apply access control list configuration for service invocation"
|
||||
linkTitle: "Service Invocation access control"
|
||||
weight: 2000
|
||||
weight: 4000
|
||||
description: "Restrict what operations *calling* applications can perform, via service invocation, on the *called* application"
|
||||
---
|
||||
|
||||
Access control enables the configuration of policies that restrict what operations *calling* applications can perform, via service invocation, on the *called* application. To limit access to a called applications from specific operations and HTTP verbs from the calling applications, you can define an access control policy specification in configuration.
|
||||
|
||||
- [Concepts](#concepts)
|
||||
- [Policy rules](#policy-rules)
|
||||
- [Policy priority](#policy-priority)
|
||||
- [Example scenarios](#example-scenarios)
|
||||
- [Hello world example](#hello-world-example)
|
||||
|
||||
An access control policy is specified in configuration and be applied to Dapr sidecar for the *called* application. Example access policies are shown below and access to the called app is based on the matched policy action. You can provide a default global action for all calling applications and if no access control policy is specified, the default behavior is to allow all calling applicatons to access to the called app.
|
||||
|
||||
## Concepts
|
||||
|
||||
**TrustDomain** - A "trust domain" is a logical group to manage trust relationships. Every application is assigned a trust domain which can be specified in the access control list policy spec. If no policy spec is defined or an empty trust domain is specified, then a default value "public" is used. This trust domain is used to generate the identity of the application in the TLS cert.
|
||||
|
||||
**App Identity** - Dapr generates a [SPIFFE](https://spiffe.io/) id for all applications which is attached in the TLS cert. The SPIFFE id is of the format: **spiffe://\<trustdomain>/ns/\<namespace\>/\<appid\>**. For matching policies, the trust domain, namespace and app ID values of the calling app are extracted from the SPIFFE id in the TLS cert of the calling app. These values are matched against the trust domain, namespace and app ID values specified in the policy spec. If all three of these match, then more specific policies are further matched.
|
||||
**App Identity** - Dapr generates a [SPIFFE](https://spiffe.io/) id for all applications which is attached in the TLS cert. The SPIFFE id is of the format: `**spiffe://\<trustdomain>/ns/\<namespace\>/\<appid\>**`. For matching policies, the trust domain, namespace and app ID values of the calling app are extracted from the SPIFFE id in the TLS cert of the calling app. These values are matched against the trust domain, namespace and app ID values specified in the policy spec. If all three of these match, then more specific policies are further matched.
|
||||
|
||||
## Configuration properties
|
||||
|
||||
The following tables lists the different properties for access control, policies and operations:
|
||||
|
||||
### Access Control
|
||||
|
||||
| Property | Type | Description |
|
||||
|---------------|--------|-------------|
|
||||
| defaultAction | string | Global default action when no other policy is matched
|
||||
| trustDomain | string | Trust domain assigned to the application. Default is "public".
|
||||
| policies | string | Policies to determine what operations the calling app can do on the called app
|
||||
|
||||
### Policies
|
||||
|
||||
| Property | Type | Description |
|
||||
|---------------|--------|-------------|
|
||||
| app | string | AppId of the calling app to allow/deny service invocation from
|
||||
| namespace | string | Namespace value that needs to be matched with the namespace of the calling app
|
||||
| trustDomain | string | Trust domain that needs to be matched with the trust domain of the calling app. Default is "public"
|
||||
| defaultAction | string | App level default action in case the app is found but no specific operation is matched
|
||||
| operations | string | operations that are allowed from the calling app
|
||||
|
||||
### Operations
|
||||
|
||||
| Property | Type | Description |
|
||||
|----------|--------|-------------|
|
||||
| name | string | Path name of the operations allowed on the called app. Wildcard "\*" can be used to under a path to match
|
||||
| httpVerb | list | List specific http verbs that can be used by the calling app. Wildcard "\*" can be used to match any http verb. Unused for grpc invocation
|
||||
| action | string | Access modifier. Accepted values "allow" (default) or "deny"
|
||||
|
||||
## Policy rules
|
||||
|
||||
|
|
@ -36,9 +62,10 @@ The action corresponding to the most specific policy matched takes effect as ord
|
|||
|
||||
## Example scenarios
|
||||
|
||||
Below are some example scenarios for using access control list for service invocation. See [configuration guidance](../../concepts/configuration/README.md) to understand the available configuration settings for an application sidecar.
|
||||
Below are some example scenarios for using access control list for service invocation. See [configuration guidance]({{< ref "configuration-concept.md" >}}) to understand the available configuration settings for an application sidecar.
|
||||
|
||||
<font size=5>Scenario 1: Deny access to all apps except where trustDomain = public, namespace = default, appId = app1</font>
|
||||
|
||||
### Scenario 1 : Deny access to all apps except where trustDomain = public, namespace = default, appId = app1
|
||||
With this configuration, all calling methods with appId = app1 are allowed and all other invocation requests from other applications are denied
|
||||
|
||||
```yaml
|
||||
|
|
@ -57,7 +84,8 @@ spec:
|
|||
namespace: "default"
|
||||
```
|
||||
|
||||
### Scenario 2 : Deny access to all apps except trustDomain = public, namespace = default, appId = app1, operation = op1
|
||||
<font size=5>Scenario 2: Deny access to all apps except trustDomain = public, namespace = default, appId = app1, operation = op1</font>
|
||||
|
||||
With this configuration, only method op1 from appId = app1 is allowed and all other method requests from all other apps, including other methods on app1, are denied
|
||||
|
||||
```yaml
|
||||
|
|
@ -80,7 +108,7 @@ spec:
|
|||
action: allow
|
||||
```
|
||||
|
||||
### Scenario 3 : Deny access to all apps except when a specific verb for HTTP and operation for GRPC is matched
|
||||
<font size=5>Scenario 3: Deny access to all apps except when a specific verb for HTTP and operation for GRPC is matched</font>
|
||||
|
||||
With this configuration, the only scenarios below are allowed access and and all other method requests from all other apps, including other methods on app1 or app2, are denied
|
||||
* trustDomain = public, namespace = default, appID = app1, operation = op1, http verb = POST/PUT
|
||||
|
|
@ -114,7 +142,7 @@ spec:
|
|||
action: allow
|
||||
```
|
||||
|
||||
### Scenario 4 : Allow access to all methods except trustDomain = public, namespace = default, appId = app1, operation = /op1/*, all http verbs
|
||||
<font size=5>Scenario 4: Allow access to all methods except trustDomain = public, namespace = default, appId = app1, operation = /op1/*, all http verbs</font>
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
|
|
@ -136,7 +164,7 @@ spec:
|
|||
action: deny
|
||||
```
|
||||
|
||||
### Scenario 5 : Allow access to all methods for trustDomain = public, namespace = ns1, appId = app1 and deny access to all methods for trustDomain = public, namespace = ns2, appId = app1
|
||||
<font size=5>Scenario 5: Allow access to all methods for trustDomain = public, namespace = ns1, appId = app1 and deny access to all methods for trustDomain = public, namespace = ns2, appId = app1</font>
|
||||
|
||||
This scenario shows how applications with the same app ID but belonging to different namespaces can be specified
|
||||
|
||||
|
|
@ -161,7 +189,7 @@ spec:
|
|||
```
|
||||
|
||||
## Hello world example
|
||||
This scenario shows how to apply access control to the [hello world](https://github.com/dapr/quickstarts/blob/master/hello-world/README.md) or [hello kubernetes](https://github.com/dapr/quickstarts/blob/master/hello-world/README.md) samples where a python app invokes a node.js app. You can create and apply these configuration files `nodeappconfig.yaml` and `pythonappconfig.yaml` as described in the [configuration](../../concepts/configuration/README.md) article.
|
||||
This scenario shows how to apply access control to the [hello world](https://github.com/dapr/quickstarts/blob/master/hello-world/README.md) or [hello kubernetes](https://github.com/dapr/quickstarts/blob/master/hello-world/README.md) samples where a python app invokes a node.js app. You can create and apply these configuration files `nodeappconfig.yaml` and `pythonappconfig.yaml` as described in the [configuration]({{< ref "configuration-concept.md" >}}) article.
|
||||
|
||||
The nodeappconfig example below shows how to deny access to the `neworder` method from the `pythonapp`, where the python app is in the `myDomain` trust domain and `default` namespace. The nodeapp is in the `public` trust domain.
|
||||
|
||||
|
|
@ -232,7 +260,3 @@ spec:
|
|||
- name: python
|
||||
image: dapriosamples/hello-k8s-python:edge
|
||||
```
|
||||
|
||||
## Related Links
|
||||
|
||||
* [Configuration concepts](../../concepts/configuration/README.md)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,115 @@
|
|||
---
|
||||
title: "Limit the secrets that can be read from secret stores"
|
||||
linkTitle: "Limit secret store access"
|
||||
weight: 3000
|
||||
description: "To limit the secrets to which the Dapr application has access, users can define secret scopes by augmenting existing configuration CRD with restrictive permissions."
|
||||
---
|
||||
|
||||
In addition to scoping which applications can access a given component, for example a secret store component (see [Scoping components]({{< ref "component-scopes.md">}})), a named secret store component itself can be scoped to one or more secrets for an application. By defining `allowedSecrets` and/or `deniedSecrets` list, applications can be restricted to access only specific secrets.
|
||||
|
||||
Follow [these instructions]({{< ref "configuration-overview.md" >}}) to define a configuration CRD.
|
||||
|
||||
## Configure secrets access
|
||||
|
||||
The `secrets` section under the `Configuration` spec contains the following properties:
|
||||
|
||||
```yml
|
||||
secrets:
|
||||
scopes:
|
||||
- storeName: kubernetes
|
||||
defaultAccess: allow
|
||||
allowedSecrets: ["redis-password"]
|
||||
- storeName: localstore
|
||||
defaultAccess: allow
|
||||
deniedSecrets: ["redis-password"]
|
||||
```
|
||||
|
||||
The following table lists the properties for secret scopes:
|
||||
|
||||
| Property | Type | Description |
|
||||
|----------------|--------|-------------|
|
||||
| storeName | string | Name of the secret store component. storeName must be unique within the list
|
||||
| defaultAccess | string | Access modifier. Accepted values "allow" (default) or "deny"
|
||||
| allowedSecrets | list | List of secret keys that can be accessed
|
||||
| deniedSecrets | list | List of secret keys that cannot be accessed
|
||||
|
||||
When an `allowedSecrets` list is present with at least one element, only those secrets defined in the list can be accessed by the application.
|
||||
|
||||
## Permission priority
|
||||
|
||||
The `allowedSecrets` and `deniedSecrets` list values take priorty over the `defaultAccess`.
|
||||
|
||||
| Scenarios | defaultAccess | allowedSecrets | deniedSecrets | permission
|
||||
|----- | ------- | -----------| ----------| ------------
|
||||
| 1 - Only default access | deny/allow | empty | empty | deny/allow
|
||||
| 2 - Default deny with allowed list | deny | ["s1"] | empty | only "s1" can be accessed
|
||||
| 3 - Default allow with deneied list | allow | empty | ["s1"] | only "s1" cannot be accessed
|
||||
| 4 - Default allow with allowed list | allow | ["s1"] | empty | only "s1" can be accessed
|
||||
| 5 - Default deny with denied list | deny | empty | ["s1"] | deny
|
||||
| 6 - Default deny/allow with both lists | deny/allow | ["s1"] | ["s2"] | only "s1" can be accessed
|
||||
|
||||
## Examples
|
||||
|
||||
### Scenario 1 : Deny access to all secrets for a secret store
|
||||
|
||||
In Kubernetes cluster, the native Kubernetes secret store is added to Dapr application by default. In some scenarios it may be necessary to deny access to Dapr secrets for a given application. To add this configuration follow the steps below:
|
||||
|
||||
Define the following `appconfig.yaml` and apply it to the Kubernetes cluster using the command `kubectl apply -f appconfig.yaml`.
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Configuration
|
||||
metadata:
|
||||
name: appconfig
|
||||
spec:
|
||||
secrets:
|
||||
scopes:
|
||||
- storeName: kubernetes
|
||||
defaultAccess: deny
|
||||
```
|
||||
|
||||
For applications that need to be deined access to the Kubernetes secret store, follow [these instructions](../configure-k8s/README.md), and add the following annotation to the application pod.
|
||||
|
||||
```yaml
|
||||
dapr.io/config: appconfig
|
||||
```
|
||||
|
||||
With this defined, the application no longer has access to Kubernetes secret store.
|
||||
|
||||
### Scenario 2 : Allow access to only certain secrets in a secret store
|
||||
|
||||
To allow a Dapr application to have access to only certain secrets, define the following `config.yaml`:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Configuration
|
||||
metadata:
|
||||
name: appconfig
|
||||
spec:
|
||||
secrets:
|
||||
scopes:
|
||||
- storeName: vault
|
||||
defaultAccess: deny
|
||||
allowedSecrets: ["secret1", "secret2"]
|
||||
```
|
||||
|
||||
This example defines configuration for secret store named vault. The default access to the secret store is `deny`, whereas some secrets are accessible by the application based on the `allowedSecrets` list. Follow [these instructions](../../concepts/configuration/README.md) to apply configuration to the sidecar.
|
||||
|
||||
### Scenario 3: Deny access to certain senstive secrets in a secret store
|
||||
|
||||
Define the following `config.yaml`:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Configuration
|
||||
metadata:
|
||||
name: appconfig
|
||||
spec:
|
||||
secrets:
|
||||
scopes:
|
||||
- storeName: vault
|
||||
defaultAccess: allow # this is the default value, line can be omitted
|
||||
deniedSecrets: ["secret1", "secret2"]
|
||||
```
|
||||
|
||||
The above configuration explicitly denies access to `secret1` and `secret2` from the secret store named vault while allowing access to all other secrets. Follow [these instructions](../../concepts/configuration/README.md) to apply configuration to the sidecar.
|
||||
Loading…
Reference in New Issue