安全是 Dapr 的基礎，本文我們將來說明在分布式應用中使用 Dapr 時的安全特性和能力，主要可以分為以下幾個方面。

與服務調(diào)用和 pub/sub APIs 的安全通信。

組件上的安全策略并通過配置進行應用。

運維操作安全實踐。

狀態(tài)安全，專注于靜態(tài)的數(shù)據(jù)。

Dapr 通過服務調(diào)用 API 提供端到端的安全性，能夠使用 Dapr 對應用程序進行身份驗證并設置端點訪問策略。

安全通信

服務調(diào)用范圍訪問策略

跨命名空間的服務調(diào)用

Dapr 應用程序可以被限定在特定的命名空間，以實現(xiàn)部署和安全，當然我們?nèi)匀豢梢栽诓渴鸬讲煌臻g的服務之間進行調(diào)用。默認情況下，服務調(diào)用支持通過簡單地引用應用 ID (比如 nodeapp) 來調(diào)用同一命名空間內(nèi)的服務：

localhost:3500/v1.0/invoke/nodeapp/method/neworder

服務調(diào)用還支持跨命名空間的調(diào)用，在所有受支持的托管平臺上，Dapr 應用程序 ID 符合包含目標命名空間的有效 FQDN 格式，可以同時指定：

應用 ID (如 nodeapp)

應用程序運行的命名空間（production）。

比如在 production 命名空間中的 nodeapp 應用上調(diào)用 neworder 方法，則可以使用下面的方式：

localhost:3500/v1.0/invoke/nodeapp.production/method/neworder

當使用服務調(diào)用在命名空間中調(diào)用應用程序時，我們可以使用命名空間對其進行限定，特別在 Kubernetes 集群中的跨命名空間調(diào)用是非常有用的。

為服務調(diào)用應用訪問控制列表配置

訪問控制策略在配置文件中被指定，并被應用于被調(diào)用應用程序的 Dapr sidecar，對被調(diào)用應用程序的訪問是基于匹配的策略動作，你可以為所有調(diào)用應用程序提供一個默認的全局動作，如果沒有指定訪問控制策略，默認行為是允許所有調(diào)用應用程序訪問被調(diào)用的應用程序。

在具體學習訪問控制策略配置之前，我們需要先了解兩個概念：

TrustDomain - “信任域”是管理信任關系的邏輯組。每個應用程序都分配有一個信任域，可以在訪問控制列表策略規(guī)范中指定。如果未定義策略規(guī)范或指定了空的信任域，則使用默認值 public，該信任域用于在 TLS 證書中生成應用程序的身份。

App Identity - Dapr 請求 sentry 服務為所有應用程序生成一個 SPIFFE id，這個 id 附加在 TLS 證書中。SPIFFE id 的格式為：spiffe:///ns//，對于匹配策略，調(diào)用應用的信任域、命名空間和應用 ID 值從調(diào)用應用的 TLS 證書中的 SPIFFE id 中提取，這些值與策略規(guī)范中指定的信任域、命名空間和應用 ID 值相匹配。如果這三個都匹配，則更具體的策略將進一步匹配。

訪問控制策略會遵循如下所示的一些規(guī)則：

如果未指定訪問策略，則默認行為是允許所有應用訪問被調(diào)用應用上的所有方法

如果未指定全局默認操作且未定義應用程序特定策略，則將空訪問策略視為未指定訪問策略，并且默認行為是允許所有應用程序訪問被調(diào)用應用程序上的所有方法

如果未指定全局默認操作，但已定義了一些特定于應用程序的策略，則會采用更安全的選項，即假設全局默認操作拒絕訪問被調(diào)用應用程序上的所有方法

如果定義了訪問策略并且無法驗證傳入的應用程序憑據(jù)，則全局默認操作將生效

如果傳入應用的信任域或命名空間與應用策略中指定的值不匹配，則應用策略將被忽略并且全局默認操作生效

下面是一些使用訪問控制列表進行服務調(diào)用的示例場景。

場景 1：拒絕所有應用程序的訪問，除非 trustDomain = public、namespace = default、appId = app1，使用如下所示的配置，允許所有 appId = app1 的調(diào)用方法，并拒絕來自其他應用程序的所有其他調(diào)用請求。

apiVersion:dapr.io/v1alpha1
kind:Configuration
metadata:
name:appconfig
spec:
accessControl:
defaultAction:deny
trustDomain:"public"
policies:
-appId:app1
defaultAction:allow
trustDomain:"public"
namespace:"default"

場景 2：拒絕訪問除 trustDomain = public、namespace = default、appId = app1、operation = op1 之外的所有應用程序，使用此配置僅允許來自 appId = app1 的方法 op1，并且拒絕來自所有其他應用程序的所有其他方法請求，包括 app1 上的其他方法。

apiVersion:dapr.io/v1alpha1
kind:Configuration
metadata:
name:appconfig
spec:
accessControl:
defaultAction:deny
trustDomain:"public"
policies:
-appId:app1
defaultAction:deny
trustDomain:"public"
namespace:"default"
operations:
-name:/op1
httpVerb:["*"]
action:allow

場景 3：拒絕對所有應用程序的訪問，除非 HTTP 的特定 verb 和 GRPC 的操作匹配，使用如下所示的配置，僅允許以下場景訪問，并且來自所有其他應用程序的所有其他方法請求（包括 app1 或 app2 上的其他方法）都會被拒絕。

trustDomain = public、namespace = default、appID = app1、operation = op1、http verb = POST/PUT

trustDomain = “myDomain”、namespace = “ns1”、appID = app2、operation = op2 并且應用程序協(xié)議是 GRPC，僅允許來自 appId = app1 的方法 op1 上的 POST/PUT 請求以及來自所有其他應用程序的所有其他方法請求，包括 app1 上的其他方法，被拒絕

apiVersion:dapr.io/v1alpha1
kind:Configuration
metadata:
name:appconfig
spec:
accessControl:
defaultAction:deny
trustDomain:"public"
policies:
-appId:app1
defaultAction:deny
trustDomain:"public"
namespace:"default"
operations:
-name:/op1
httpVerb:["POST","PUT"]
action:allow
-appId:app2
defaultAction:deny
trustDomain:"myDomain"
namespace:"ns1"
operations:
-name:/op2
action:allow

場景 4：允許訪問除 trustDomain = public、namespace = default、appId = app1、operation = /op1/* 所有 http verb 之外的所有方法。

apiVersion:dapr.io/v1alpha1
kind:Configuration
metadata:
name:appconfig
spec:
accessControl:
defaultAction:allow
trustDomain:"public"
policies:
-appId:app1
defaultAction:allow
trustDomain:"public"
namespace:"default"
operations:
-name:/op1/*
httpVerb:["*"]
action:deny

場景 5：允許訪問 trustDomain = public、namespace = ns1、appId = app1 的所有方法并拒絕訪問 trustDomain = public、namespace = ns2、appId = app1 的所有方法，此場景展示了如何指定具有相同應用 ID 但屬于不同命名空間的應用。

apiVersion:dapr.io/v1alpha1
kind:Configuration
metadata:
name:appconfig
spec:
accessControl:
defaultAction:allow
trustDomain:"public"
policies:
-appId:app1
defaultAction:allow
trustDomain:"public"
namespace:"ns1"
-appId:app1
defaultAction:deny
trustDomain:"public"
namespace:"ns2"

場景 6：允許訪問除 trustDomain = public、namespace = default、appId = app1、operation = /op1/**/a、所有 http 動詞之外的所有方法。

apiVersion:dapr.io/v1alpha1
kind:Configuration
metadata:
name:appconfig
spec:
accessControl:
defaultAction:allow
trustDomain:"public"
policies:
-appId:app1
defaultAction:allow
trustDomain:"public"
namespace:"default"
operations:
-name:/op1/**/a
httpVerb:["*"]
action:deny

下面我們通過一個具體的示例來展示下訪問控制策略的使用，同樣還是使用 quickstarts 示例中的 hello-world 進行說明。

gitclone[-b]https://github.com/dapr/quickstarts.git
cdquickstarts/tutorials/hello-world/node

該示例應用中包含一個 python 應用去調(diào)用一個 node.js 應用程序，訪問控制列表依靠 Dapr Sentry 服務來生成帶有 SPIFFE id 的 TLS 證書進行認證，這意味著 Sentry 服務必須在本地運行或部署到你的托管環(huán)境，比如 Kubernetes 集群。

下面的 nodeappconfig 例子顯示了如何拒絕來自 pythonapp 的 neworder 方法的訪問，其中 pythonapp 是在 myDomain 信任域和 default 命名空間中，nodeapp 在 public 公共信任域中。

#nodeappconfig.yaml
apiVersion:dapr.io/v1alpha1
kind:Configuration
metadata:
name:nodeappconfig
spec:
tracing:
samplingRate:"1"
accessControl:
defaultAction:allow
trustDomain:"public"
policies:
-appId:pythonapp
defaultAction:allow
trustDomain:"myDomain"
namespace:"default"
operations:
-name:/neworder
httpVerb:["POST"]
action:deny

#pythonappconfig.yaml
apiVersion:dapr.io/v1alpha1
kind:Configuration
metadata:
name:pythonappconfig
spec:
tracing:
samplingRate:"1"
accessControl:
defaultAction:allow
trustDomain:"myDomain"

接下來我們先在本地自拓管模式下來使用啟用訪問策略配置，首先需要在啟用 mTLS 的情況下在本地運行 Sentry 服務，我們可以直接在 https://github.com/dapr/dapr/releases 頁面下載對應的 sentry 二進制文件，比如我們這里是 Mac M1，則可以使用下面的命令直接下載：

#wgethttps://github.91chi.fun/https://github.com/dapr/dapr/releases/download/v1.8.4/sentry_darwin_arm64.tar.gz
$wgethttps://github.com/dapr/dapr/releases/download/v1.8.4/sentry_darwin_arm64.tar.gz
$tar-xvfsentry_darwin_arm64.tar.gz

然后為 Sentry 服務創(chuàng)建一個目錄以創(chuàng)建自簽名根證書：

$mkdir-p$HOME/.dapr/certs

使用以下命令在本地運行 Sentry 服務：

$./sentry--issuer-credentials$HOME/.dapr/certs--trust-domaincluster.local
INFO[0000]startingsentrycertificateauthority--version1.8.4--commit18575823c74318c811d6cd6f57ffac76d5debe93instance=MBP2022.localscope=dapr.sentrytype=logver=1.8.4
INFO[0000]configuration:[port]:50001,[castore]:default,[allowedclockskew]:15m0s,[workloadcertttl]:24h0m0sinstance=MBP2022.localscope=dapr.sentry.configtype=logver=1.8.4
WARN[0000]loadingdefaultconfig.couldn'tfindconfigname:daprsystem:statdaprsystem:nosuchfileordirectoryinstance=MBP2022.localscope=dapr.sentrytype=logver=1.8.4
INFO[0000]startingwatchonfilesystemdirectory:/Users/cnych/.dapr/certsinstance=MBP2022.localscope=dapr.sentrytype=logver=1.8.4
INFO[0000]certificateauthorityloadedinstance=MBP2022.localscope=dapr.sentrytype=logver=1.8.4
INFO[0000]rootandissuercertsnotfound:generatingselfsignedCAinstance=MBP2022.localscope=dapr.sentry.catype=logver=1.8.4
#......
INFO[0000]sentrycertificateauthorityisrunning,protectingya'llinstance=MBP2022.localscope=dapr.sentrytype=logver=1.8.4

運行成功后 Sentry 服務將在指定目錄中創(chuàng)建根證書，可以通過如下所示的命令來配置環(huán)境變量指定相關證書路徑：

exportDAPR_TRUST_ANCHORS=`cat$HOME/.dapr/certs/ca.crt`
exportDAPR_CERT_CHAIN=`cat$HOME/.dapr/certs/issuer.crt`
exportDAPR_CERT_KEY=`cat$HOME/.dapr/certs/issuer.key`
exportNAMESPACE=default

然后我們就可以運行 daprd 為啟用了 mTLS 的 node.js 應用啟動 Dapr sidecar，并引用本地的 Sentry 服務：

daprd--app-idnodeapp--dapr-grpc-port50002-dapr-http-port3501-metrics-port9091--log-leveldebug--app-port3000--enable-mtls--sentry-addresslocalhost:50001--confignodeappconfig.yaml

上面的命令我們通過 --enable-mtls 啟用了 mTLS，通過 --config 指定了上面的 nodeappconfig.yaml 這個配置文件。

然后啟動 node.js 應用：

$cdnode&&yarn
$nodeapp.js

NodeApplisteningonport3000!

同樣的方式在另外的終端中設置環(huán)境變量：

exportDAPR_TRUST_ANCHORS=`cat$HOME/.dapr/certs/ca.crt`
exportDAPR_CERT_CHAIN=`cat$HOME/.dapr/certs/issuer.crt`
exportDAPR_CERT_KEY=`cat$HOME/.dapr/certs/issuer.key`
exportNAMESPACE=default

然后運行 daprd 為啟用了 mTLS 的 python 應用啟動 Dapr sidecar，并引用本地的 Sentry 服務：

daprd--app-idpythonapp--dapr-grpc-port50003--metrics-port9092--log-leveldebug--enable-mtls--sentry-addresslocalhost:50001--configpythonappconfig.yaml

在重新開一個終端直接啟動 Python 應用即可：

$cdpython&&pip3install-rrequirements.txt
$python3app.py

HTTP403=>{"errorCode":"ERR_DIRECT_INVOKE","message":"failtoinvoke,id:nodeapp,err:rpcerror:code=PermissionDenieddesc=accesscontrolpolicyhasdeniedaccesstoappid:pythonappoperation:neworderverb:POST"}
HTTP403=>{"errorCode":"ERR_DIRECT_INVOKE","message":"failtoinvoke,id:nodeapp,err:rpcerror:code=PermissionDenieddesc=accesscontrolpolicyhasdeniedaccesstoappid:pythonappoperation:neworderverb:POST"}
#......

由于 nodeappconfig 文件中我們配置了對 /neworder 接口的 POST 拒絕操作，所以應該會在 python 應用程序命令提示符中看到對 node.js 應用程序的調(diào)用失敗，如果我們將上面的 nodeappconfig 配置中的 action: deny 修改為 action: allow 并重新運行應用程序，然后我們應該會看到此調(diào)用成功。

對于 Kubernetes 模式則更簡單，只需要創(chuàng)建上述配置文件 nodeappconfig.yaml 和 pythonappconfig.yaml 并將其應用于 Kubernetes 集群，然后在應用的注解中添加 dapr.io/config: "pythonappconfig" 來指定配置即可開啟服務訪問控制。

annotations:
dapr.io/enabled:"true"
dapr.io/app-id:"pythonapp"
dapr.io/config:"pythonappconfig"

Pub/sub 主題范圍訪問策略

對于 Pub/sub 組件，你可以限制允許哪些主題類型和應用程序發(fā)布和訂閱特定主題。

命名空間或組件范圍可用于限制組件對特定應用程序的訪問，這些添加到組件的應用程序范圍僅限制具有特定 ID 的應用程序能夠使用該組件。如下所示顯示了如何將兩個啟用 Dapr 的應用程序（應用程序 ID 為 app1 和 app2）授予名為 statestore 的 Redis 組件，該組件本身位于 production 命名空間中：

apiVersion:dapr.io/v1alpha1
kind:Component
metadata:
name:statestore
namespace:production
spec:
type:state.redis
version:v1
metadata:
-name:redisHost
value:redis-master:6379
scopes:
-app1
-app2

除了這個通用組件的 scopes 范圍之外，發(fā)布/訂閱組件還可以限制以下內(nèi)容：

可以使用哪些主題（發(fā)布或訂閱）

允許哪些應用發(fā)布到特定主題

允許哪些應用訂閱特定主題

這被稱為發(fā)布/訂閱主題范圍。我們可以為每個發(fā)布/訂閱組件定義發(fā)布/訂閱范圍，比如你可能有一個名為 pubsub 的 pub/sub 組件，它具有一組范圍，另一個 pubsub2 具有另外不同的范圍。

示例 1：主題訪問范圍。如果你的主題包含敏感信息并且僅允許你的應用程序的子集發(fā)布或訂閱這些信息，那么限制哪些應用程序可以發(fā)布/訂閱主題可能會很有用。如下以下是三個應用程序和三個主題的示例：

apiVersion:dapr.io/v1alpha1
kind:Component
metadata:
name:pubsub
spec:
type:pubsub.redis
version:v1
metadata:
-name:redisHost
value:"localhost:6379"
-name:redisPassword
value:""
-name:publishingScopes
value:"app1=topic1;app2=topic2,topic3;app3="
-name:subscriptionScopes
value:"app2=;app3=topic1"

這里我們設置了 publishingScopes 和 subscriptionScopes 兩個屬性，分別用于配置發(fā)布范圍和訂閱范圍。要拒絕應用發(fā)布到任何主題，請將主題列表留空，比如我們這里配置的 app1=topic1;app2=topic2,topic3;app3=，其中的 app3= 就表示該應用不允許發(fā)布到任何主題上去。

根據(jù)我們的配置下表顯示了允許哪些應用程序發(fā)布到主題中：

下表顯示了哪些應用程序可以訂閱主題：

注意：如果未列出應用程序（例如，subscriptionScopes 中的 app1），則允許它訂閱所有主題。因為不使用 allowedTopics 并且 app1 沒有任何訂閱范圍，所以它也可以使用上面未列出的其他主題。

示例 2：限制允許的主題。如果 Dapr 應用程序向其發(fā)送消息，則會創(chuàng)建一個主題，在某些情況下，應管理此主題的創(chuàng)建。例如：

Dapr 應用程序中生成主題名稱的錯誤可能導致創(chuàng)建無限數(shù)量的主題

精簡主題名稱和總數(shù)，防止主題無限增長

在這些情況下，可以使用 allowedTopics 屬性進行配置，以下就是三個允許主題的示例：

apiVersion:dapr.io/v1alpha1
kind:Component
metadata:
name:pubsub
spec:
type:pubsub.redis
version:v1
metadata:
-name:redisHost
value:"localhost:6379"
-name:redisPassword
value:""
-name:allowedTopics
value:"topic1,topic2,topic3"

示例 3：組合 allowedTopics 和范圍。有時你想結(jié)合這兩個范圍，因此只有一組固定的允許主題并為某些應用程序指定范圍。以下是三個應用程序和兩個主題的示例：

apiVersion:dapr.io/v1alpha1
kind:Component
metadata:
name:pubsub
spec:
type:pubsub.redis
version:v1
metadata:
-name:redisHost
value:"localhost:6379"
-name:redisPassword
value:""
-name:allowedTopics
value:"A,B"
-name:publishingScopes
value:"app1=A"
-name:subscriptionScopes
value:"app1=;app2=A"

注意這里我們沒有列出第三個應用程序，如果沒有在范圍內(nèi)指定應用程序，則允許它使用所有主題。

根據(jù)上面的配置下表顯示了允許哪個應用程序發(fā)布到主題中：

下表顯示了允許哪個應用程序訂閱主題：

審核編輯：湯梓紅