本博客地址：https://security.blog.csdn.net/article/details/130152887
一、认证服务
1.1、基于JWT的认证
在微服务架构下，每个服务是无状态的，由于服务端需要存储客户端的登录状态，因此传统的session认证方式在微服务中不再适用。理想的实现方式应为无状态登录，流程通常如下：
1、客户端请求某服务，服务端对用户进行登录认证。
2、认证通过，服务端将用户登录信息进行加密并形成令牌，最后再返回至客户端作为登录凭证。
3、在步骤2之后，客户端每次请求都须携带认证的令牌。
4、服务端对令牌进行解密，判断是否有效，若有效则认证通过，否则返回失败信息。
可通过JWT实现无状态登录，JWT是JSON风格轻量级认证和授权规范，也就是上述流程中提到的令牌，它主要用于分布式场景，需要注意的是，JWT令牌中会包含用户敏感信息，为防止被绕过，JWT令牌采用了签名机制。此外，传输时需要使用加密协议。
1.2、基于Istio的认证
Istio的基础知识可以参考此前写的一篇博文：https://security.blog.csdn.net/article/details/128449214
Istio主要有两种认证类型：传输认证、请求级认证
1、传输认证
传输认证是Istio的一种认证类型，其主要用于微服务应用架构中服务到服务的认证，从而可验证所连接的客户端。针对此类型的认证，Istio提供了双向TLS的解决方案，该解决方案提供以下功能 ：
1、确保服务到服务间的通信安全。
2、提供密钥管理系统，从而自动进行密钥及证书的生成、分发和轮换。
3、为每个服务提供一个代表其角色的身份，从而实现跨集群的互操作性。
具体地，我们可以通过使用传输认证策略为Istio中的服务指定认证要求，如命名空间级别TLS认证策略可以指定某命名空间下所有的Pod间的访问均使用TLS加密、Pod级别TLS认证策略可以指定某具体Pod被访问时需要进行TLS加密等。
2、请求级认证
请求级认证是Istio的一种认证类型，主要用于对终端用户的认证，与传输认证的主要区别为，请求级认证主要用于验证用户请求服务时携带的凭据，而非服务到服务的认证。
请求级认证主要通过JWT机制实现。相比于传统Session认证方法的最大区别在于认证信息保存在客户端，由于不再将认证信息存储在服务端，因此非常适用于无状态的微服务场景，并达到了易于扩展的目的。
Istio的JWT认证主要依赖于JWKS，JWKS是一组密钥集合，其中包含用于验证JWT的公钥，在实际应用场景中，运维人员通过为服务部署JWT认证策略实现请求级认证。
下面展示了JWT认证策略的核心部分配置：
// issuer：代表发布JWT的发行者
issuer: https://example.com
// jwksUri：JWKS获取的地址，本地或远程均可，用于验证JWT的签名
jwksUri: https://example.com/.well-known/jwks.json
// triggerRules：triggerRules为使用JWT验证请求的规则触发列表，如果满足匹配规则就进行JWT验证
triggerRules:
- excludedPaths:
// 对于任何带有/status/前缀的请求路径，除了/status/version以外，都需要JWT认证
- exact: /status/version
includedPaths:
- prefix: /status/
当JWT认证策略部署完成后，外部对某服务有新的请求时，请求级认证会根据策略内容验证请求携带的令牌（Token），若与策略内容匹配则返回认证失败，反之认证成功。
二、基于Istio的访问控制
2.1、Istio授权
Istio授权流程可以归纳总结为以下内容：
Administrator使用yaml文件指定Istio授权策略，并将其部署至Istiod核心组件中，Istiod通过API Server组件监测授权策略变更，若有更改，则获取新的策略，Istiod将授权策略下发至服务的Sidecar代理，每个Sidecar代理均包含一个授权引擎，在引擎运行时对请求进行授权。
如图所示：
举一个Istio授权策略的例子：
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: httpbin-policy
namespace: foo
spec:
selector:
matchLabels:
app: httpbin
action: ALLOW
rules:
- from:
- source:
principals: ["cluster.local/ns/default/sa/sleep"]
to:
- operation:
methods: ["GET"]
paths: ["/info*"]
when:
- key: request.auth.claims[iss]
values: ["https://foo.com"]
这个授权策略的含义是：筛选出foo这个namespace中含有app:httpbin这个标签的pod，对发送到这些pod的请求进行匹配，如果匹配成功，则放行当前请求。
匹配规则如下：发起请求的pod的Service Account需要是cluster.local/ns/default/sa/sleep，请求使用HTTP协议，请求的具体方法类型是GET，请求的URL为/info*，并且请求中需要包含由https://foo.com签发的有效的JWT Token。
从这个例子中可以看出一个授权策略主要包含以下几个部分：
name：授权策略的名称，仅用于标识授权策略本身，不会影响规则的匹配和执行；
namespace：当前策略对象所在的namespace，可以使用这个字段配置不同作用范围的授权策略；
selector：使用label来选择当前授权策略作用于哪些pod上。注意，这里设置的是服务端的pod，因为最终这些规则会转换为Envoy规则由服务端的Envoy Porxy来具体执行；
action：可以为ALLOW（默认值）或者DENY；
rules：匹配规则，如果匹配成功，就会执行对应的action；
2.2、授权策略的匹配算法
针对某一个请求，会按照一定的匹配算法来执行相应的授权策略：
1、如果有任何一条 DENY 授权策略匹配当前请求，则拒绝当前请求；
2、针对当前 pod，如果没有任何 ALLOW 授权策略，则放行当前请求；
3、如果有任何一条 ALLOW 授权策略匹配当前请求，则放行当前请求；
4、拒绝当前请求；
也就意味着，如果同时有 ALLOW 和 DENY 策略作用于同一个 pod 上，则 DENY 策略会优先执行，其它的 ALLOW 规则就会被忽略。