如果用户选择在K8s中部署微服务应用，则可以直接使用K8s原生的RBAC策略。
2.2.2 基于Istio的授权服务
Istio还提供授权机制，其主要用于对服务进行授权。在Istio 1.4版本之前，授权机制依赖于K8s的RBAC策略，相比K8s的原生RBAC策略，Istio对其进行了进一步的封装，可让用户直接通过Istio的声明式API对具体的服务进行授权。不过为了更好的用户体验，Istio在其1.6版本中引入了授权自定义策略（AuthorizationPolicy Custom Resource Definition，CRD），相比1.4版本，CRD带来了更多的优势：一方面，该CRD将RBAC的配置变得更为简化，从而大幅改善了用户体验；另一方面，该CRD支持更多的用例，例如对Ingress/Egress的支持，且不会增加复杂性。
此外，Istio的授权模式也是基于其提供的授权策略实现的。
如图4所示，Istio授权流程可以归纳总结为以下内容：
管理员（Administrator）使用yaml文件指定Istio授权策略并将其部署至Istiod核心组件中，Istiod通过K8s的API服务端组件（API Server）监测授权策略变更，若有更改，则获取新的策略，Istiod将授权策略下发至服务的边车（Sidecar）代理，每个Sidecar代理均包含一个授权引擎，在引擎运行时对请求进行授权。
以下是一个简单的Istio授权策略：
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: httpbin
namespace: foo
spec:
selector:
matchLabels:
app: httpbin
version: v1
rules:
- from:
- source:
principals: ["cluster.local/ns/default/sa/sleep"]
to:
- operation:
methods: ["GET"]
when:
- key: request.headers[version]
values: ["v1", "v2"]
可以看出，以上策略适用于foo命名空间下，且满足标签为app: httpbin和version: v1的目标Pod, 并设置授权规则为当访问源为“cluster.local/ns/default/sa/sleep”的服务，且请求头中包含v1或v2的version字段时，才允许访问。默认情况下，任何与策略不匹配的请求都将被拒绝。
2.3 数据安全
在微服务应用架构下，服务间通信不仅使用HTTP协议，还会使用gRPC协议等，数据安全防护尤为必要。可以通过安全编码、使用密钥管理系统和安全协议的方式防止数据泄露，在微服务应用架构中，可以考虑使用K8s原生的安全机制或微服务治理框架的安全机制进行防护。
针对K8s原生的安全机制，例如密钥机制（Secret），我们可以使用其进行密钥存储，从而规避了敏感信息硬编码带来的数据泄露风险。
针对微服务治理框架的安全机制，如Istio支持服务间的TLS双向加密、密钥管理及服务间的授权，可以有效规避由中间人攻击或未授权访问攻击带来的数据泄露风险。
2.4 其他防护机制
通过以上介绍，我们可以看出采用微服务治理框架的防护方式可在一定程度上有效规避云原生应用的新风险，但其防护点主要针对微服务架构下应用的东西向流量，针对南北向的流量防护稍显脆弱。由于微服务架构下的应用防护应当是全流量防护，因而针对南北向所存在的问题，我们可以考虑将微服务治理框架与API网关和WAF防火墙相结合，从而提升南北向的防护能力。
本节将以微服务治理框架Istio为例，介绍Istio和API网关协同的全面防护以及Istio与WAF结合的深度防护。
2.4.1 Istio和API网关协同的全面防护
针对应用的南北流量而言，Istio采取的解决方案为使用边缘代理Ingress与Egress分别接管用户或外界服务到服务网格内部的入/出站流量，Ingress与Egress实则为Istio部署的两个Pod，Pod内部为一个透明代理（Envoy），借助Envoy代理的安全过滤（Filter）机制，在一定程度上可对恶意Web攻击进行相应防护。但现有的Envoy安全Filter种类相对较少，面对复杂变化场景下的Web攻击仍然无法应对，可行的解决方案为在服务网格之外部署一层云原生API网关，具体如图5所示。
安全功能上，云原生API网关可提供全方位的安全防护，例如访问控制、认证授权、证书管理、机器流量检测（Bot）、数据丢失防护、黑白名单限制等，在这些有效防护基础之上，应用的南北向得到了控制。