服务网格 ASM：零信任安全概述

为什么要使用ASM实现零信任

借助ASM，可以使用单个控制平面来实施强大的身份和访问管理、透明的TLS和加密、身份认证和授权以及审核日志记录。ASM开箱即用地提供了这些功能，简单地安装和管理使开发人员、系统管理员和安全团队可以保护其微服务应用程序。

如何使用ASM中的零信任体系

ASM能够减小云原生环境中的被攻击面积，并提供零信任应用网络所需的基础框架。通过ASM管理服务到服务的安全性，可以确保ASM的端到端加密、服务级别身份认证和细粒度授权策略。

当前ASM提供了工作负载身份、对等身份认证、请求身份认证、授权策略、OPA策略的零信任安全基本能力。

工作负载身份

当应用程序在ASM环境中运行时，ASM会为每个服务提供一个唯一标识。连接到ASM中运行的其他微服务时将使用该标识。服务标识可用于服务的双向验证，以此进行验证是否允许服务间的访问，同时该服务标识也可用于授权策略中。

当使用ASM管理运行在Kubernetes上的工作负载或者基于WorkloadEntry定义虚拟机工作负载时，ASM会为每个工作负载提供服务身份，该身份基于工作负载的服务账户令牌实现。

ASM中的服务身份符合SPIFFE标准，并具有以下格式：spiffe://<trust-domain>/ns/<namespace>/sa/<service-account>。

对等身份认证

ASM提供了两种身份认证：对等身份认证和请求身份认证。对等身份认证是指当两个微服务相互交互时，可以启用双向TLS进行对等身份认证。

1. 安装部署bookinfo示例，详细信息，请参见入门指引。

2. 执行如下命令，使用HTTP从同一命名空间（本示例中为default）中的Productpage Pod访问details服务。

   kubectl exec $(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://details:9080/details/1 -o /dev/null -s -w '%{http_code}\n'

   默认情况下请求以status 200成功返回。这是因为在默认情况下，TLS和纯文本流量都可以被接受。

3. 在命名空间default下定义对等身份认证。

   1. 登录ASM控制台，打开对应的ASM实例，在左侧导航栏中单击网格安全中心 > 对等身份认证。在右侧页面中，单击创建双向mTLS模式，为工作负载details定义mTLS模式为STRICT，然后单击创建。

   2. 执行如下命令，使用HTTP从同一命名空间（本示例中为default）中的Productpage Pod访问details服务。

      kubectl exec $(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://details:9080/details/1 -o /dev/null -s -w '%{http_code}\n'

      预期输出：

      000
      command terminated with exit code 56

      退出码56表示接收网络数据失败。这是符合预期的，工作负载details定义了mTLS模式为STRICT，这样在每个请求中都需要TLS证书认证。

4. 为了允许正常访问，可以将mTLS模式（命名空间级）设置为PERMISSIVE-支持明文或双向TLS认证，将对等身份认证从STRICT修改为PERMISSIVE。对应的YAML定义如下：

   apiVersion: security.istio.io/v1beta1
   kind: PeerAuthentication
   metadata:
     name: details-strict
     namespace: default
   spec:
     mtls:
       mode: PERMISSIVE
     selector:
       matchLabels:
         app: details

请求身份认证

ASM提供了两种身份认证：对等身份认证和请求身份认证。请求身份认证是允许最终用户和系统使用请求身份认证，与微服务进行交互。通常使用JSON Web令牌（JWT）执行该操作。

1. 安装部署bookinfo示例，详细信息，请参见入门指引。

2. 创建一个请求身份认证策略来对details服务的入站请求强制执行JWT身份认证。

   1. 登录ASM控制台，打开对应的ASM实例，在左侧导航栏中单击网格安全中心 > 请求身份认证。

   2. 在右侧页面中，单击创建，为工作负载details定义JWT规则。

      • issuer：设置为testing@secure.istio.io。

      • jwks：它的值取自jwks.json。

      

   3. 单击创建。

3. 执行如下命令，使用HTTP从同一命名空间（本示例中为default）中的Productpage Pod访问details服务。请将Token替换为实际值。

   export TOKEN=eyJhbGciOiJSUzI1NiIsImtpZCI6IkRIRmJwb0lVcXJZOHQyenBBMnFYZkNtcjVWTzVaRXI0UnpIVV8tZW52dlEiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjQ2ODU5ODk3MDAsImZvbyI6ImJhciIsImlhdCI6MTUzMjM4OTcwMCwiaXNzIjoidGVzdGluZ0BzZWN1cmUuaXN0aW8uaW8iLCJzdWIiOiJ0ZXN0aW5nQHNlY3VyZS5pc3Rpby5pbyJ9.CfNnxWP2tcnR9q0vxyxweaF3ovQYHYZl82hAUsn21bwQd9zP7c-LS9qd_vpdLG4Tn1A15NxfCjp5f7QNBUo-KC9PJqYpgGbaXhaGx7bEdFWjcwv3nZzvc7M__ZpaCERdwU7ig****YGBYQ51vr2njU9ZimyKkfDe3axcyiBZde7G6dabliUosJvvKOPcKIWPccCgefSj_GNfwIip3-SsFdlR7BtbVUcqR-yv-XOxJ3Uc1MI0tz3uMiiZcy****NCU4KRnemRIMHVOfuvHsU60_Gh****zgPTAa9WTltbnarTbxudb_YEOx12JiwYToeX0DCPb43W1tzIBxgm8NxUg
   
   kubectl exec $(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://details:9080/details/1 -o /dev/null --header "Authorization: Bearer $TOKEN" -s -w '%{http_code}\n'

   预期输出：

   200

   • 如果传递的是无效Token，可以看到401 响应：

     kubectl exec $(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://details:9080/details/1 -o /dev/null --header "Authorization: Bearer badtoken" -s -w '%{http_code}\n'
     
     401

   • 如果未传递Token，RequestAuthentication则不会调用该策略。不使用JWT Token的请求，同样也返回200。

     kubectl exec $(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://details:9080/details/1 -o /dev/null  -s -w '%{http_code}\n'
     
     200

授权策略

ASM提供了授权策略，您可以使用授权策略AuthorizationPolicy资源来激活微服务之间的授权机制。

1. 登录ASM控制台，打开对应的ASM实例，在左侧导航栏中单击网格安全中心 > 授权策略。

2. 建立流量授权策略机制。

   • 方式一：在右侧页面中，单击创建。

   • 方式二：在右侧页面中，单击使用YAML创建。对应的YAML定义如下：

     apiVersion: security.istio.io/v1beta1
     kind: AuthorizationPolicy
     metadata:
       name: require-jwt
       namespace: default
     spec:
       action: ALLOW
       rules:
         - from:
             - source:
                 requestPrincipals:
                   - testing@secure.istio.io/testing@secure.istio.io
       selector:
         matchLabels:
           app: details

     字段	字段说明
     selector	工作负载标签选择，指定策略目标。
     action	指定是ALLOW还是DENY请求。如果您未指定操作，则默认设置为ALLOW。为清晰起见，建议您始终指定操作。此外授权政策还支持AUDIT和CUSTOM操作。
     rules	指定何时触发操作。
     rules.from	指定请求的来源。
     rules.to	指定请求的操作。
     when	指定为了应用规则所需满足的其他条件。

3. 执行如下命令，使用不带有JWT Token的请求访问服务。

    kubectl exec $(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://details:9080/details/1 -o /dev/null  -s -w '%{http_code}\n'

   预期输出：

   403

   回显403说明AuthorizationPolicy生效了，所有前端请求都必须有一个JWT Token。

OPA策略

OPA是一个策略引擎，可为您的应用程序实现细粒度的访问控制。OPA作为通用策略引擎，可以与微服务一起部署为独立服务。为了保护应用程序，必须先授权对微服务的每个请求，然后才能对其进行处理。为了检查授权，微服务对OPA进行API调用，以确定请求是否被授权。更多信息，请参见OPA。

ASM集成了开放策略代理（OPA）插件，通过OPA定义访问控制策略，可以使您的应用实现细粒度的访问控制，并支持动态更新OPA策略。详细信息，请参见在ASM中实现动态更新OPA策略。

总结及参考案例

每一个工作负载通过X509 TLS证书建立身份，每个Sidecar代理都使用该证书。ASM会提供并定期轮换证书和私钥。如果某个特定的私钥被盗用，ASM很快就会用新的私钥替换它，从而大大减少了攻击面。

参考案例

• 使用授权策略在入口网关上实施基于IP的访问控制或者基于自定义外部授权的访问控制等。

• 某互联金融客户在解决跨集群多语言应用的访问权限控制方面，使用ASM提供的授权策略隔离外联区域和应用区域。同时结合出口网关审计网格的流量，配合授权策略，控制应用对第三方服务的访问权限。