第5章 istio可插拔的服务安全

第5章 可插拔的服务安全
istio提供的安全功能可以解决类似如下的问题：
◎ 项目要发布了，做安全稽查时却发现不满足某项安全标准， 导致项目延期、苦不堪言;
◎ 因为要处理某项安全要求，所以不得不在干干净净的业务代码里引入各种安全库，并添加各种安全处理，导致部分代码面目全非;
◎ 好不容易给服务提供了双向TLS认证，在运行一段时间后服务访问却出问题了，调查很久后才发现原来是证书过期了。

5.1 Istio服务安全的原理
Istio的安全功能以一种安全基础设施方式提供的，不用修改业务代码就能提供服务访问安全。
istio的安全原理如下图

主要涉及四个重要的组件：
◎ citadel用于秘钥和证书管理
◎ Envoy作为数据面组件代理服务间的安全通信，包括认证、通道加密等;
◎ Pilot作为配置管理服务，在安全场景下将安全相关的配置分发给Envoy; 
◎ Mixer可以通过配置Adapter来做授权和访问审计。

部署和配置阶段
Citadel监听Kube-apiserver，为每个Service都生成密钥和证书，并保存为Kubernetes Secrets;
当创建Pod时，Kubernetes将包含密钥和证书的Secret挂载到对应的Pod中;
Citadel会维护证书的生命周期，并根据配置定期重建 Kubernetes Secrets以自动更新证书;
Pilot生成配置信息，定义哪个Service Account可以运行哪个服务，并将这个配置下发给Envoy。

envoy在转发业务流量时的操作
◎ 客户端的Envoy拦截到服务的Outbound流量;
◎ 客户端的Envoy和服务端的Envoy进行双向TLS握手;
◎ 在双向TLS建立后，请求到达服务端Envoy，服务端Envoy将请求转发给本地服务。

5.1.1 认证
认证是基础，互相认证后，交换数据。

istio的两种认证方式：
1) 传输认证:Istio中基于双向TLS来实现传输认证，包括双向认证、通道安全和证书自动 维护。
2）来源认证： Istio中一般支持使用 JWT(JSON Web Token)方式验证请求级别的验证。
JWT常常用于保护服务端的资源，客户端将JWT通 过HTTP Header发送给服务端，服务端计算、验证签名以判断该JWT是否可信。

TLS协议：建立一个加密的双向网络通道在两台主机间传输数据

TLS主要提供的功能如下：
◎ 提供通信双方的身份认证，可以是在Istio中推荐的双向认证，也可以是在更多场景下只对服务端进行的单向认证;
◎ 提供数据完整性校验。
◎ 使用对称加密算法来加密传输的数据，从而实现通道安全;

单向认证
适用于人机场景，如人访问web应用。
只有服务端维护证书，在应答客户端请求时将服务端的证书发给客户端，只有客户端校验服务端的证书;双方协商一个对称密钥进行数据交换。步骤如下:
(1)客户端发起请求; 
(2)服务端回复。服务端发送证书给客户端，在证书中包含服务端的公钥;
(3)客户端验证服务端的证书，检查证书时间、证书的数字签名等; 
(4)客户端生成对称加密的密钥，使用服务端的证书中的公钥对其进行加密并发给服务端; 
(5)服务端使用自己的私钥解出加密密钥; 
(6)客户端和服务端使用协商的对称密钥来交换数据。

双向认证：
主要被用于服务对服务的访问场景下。
客户端和服务端都必须持有标识身份的证书，在双方通信时要求客户端校验服务 端，同时客户端也要提供证书供服务端校验。
比起单向认证，双向认证更加安全，除了可以避免客户端访问到一个假冒的服务端，服务端也会确认来访的客户端的合法身份。
步骤如下:
(1)客户端发起请求;
(2)服务端应答，包括选择的协议版本等。服务端发送证书给客户端，在证书中包含服务端的公 钥;
(3)客户端验证服务端的证书，检查证书时间，验证证书的数字签名等; 
(4)服务端要求客户端提供证书;
(5)客户端发送自己的证书到服务端; 
(6)服务端校验客户端的证书，获取客户端的公钥; 
(7)客户端生成对称加密的密钥，使用服务端的证书中的公钥对其进行加密并发给服务端; 
(8)服务端使用自己的私钥解出加密密钥; 
(9)客户端和服务端使用协商的对称密钥来交换数据。

Istio认证配置生效的流程
管理员通过Kube-apiserver配置认证策略，在策略中描述对命名空间是ref的所有服务启用认证服务，对命名空间weather内的frontend服务启用认证服务。 Pilot会将对应的配置下发到Envoy，并在Envoy上执行。
如图

对于服务调用方和被调用方分别有不同的配置。
◎ 服务被调用方:使用认证策略配置服务端的认证，Pilot 将认证策略转换成 Envoy可识别的格式并 下发给Envoy，Envoy再根据收到的配置做身份验证。
◎ 服务调用方:如果用户采用了双向TLS认证，则通过DestinationRule进行配置，Pilot将配置信息下 发到对应的 Envoy，Envoy再根据配置进行双向 TLS通信;如果用户采用 JWT 进行来源身份验证，则需 要应用程序获取 JWT 凭证并将其包含在请求中。

5.1.2 授权
在Istio 中使用基于角色的访问权限控制RBAC模型进行授权控制。
1.RBAC模型
如图

把权限分配给角色，相应角色的用户就具备了对应功能的权限。
使用 Role 作为权限的分组，也比较有利于复用，避免了给多个用户重复分配相同的权限。

2.Istio的RBAC
Istio可以为网格中的服务提供命名空间级别、服务级别和方法级别的授权管理。
Istio的整个授权配置的工作流程，包括配置规则、下 发规则和执行规则。
如图

◎ 管理员配置授权规则，将授权配置信息存储在Kube-apiserver中;
◎ Pilot从Kube-apierver处获取授权配置策略，和下发其他规则一样将配置发送给对应服务的Envoy; 
◎ Envoy在运行时基于授权策略来判断是否允许访问。

5.1.3 密钥证书管理
Istio 通过组件 Citadel来实现密钥证书管理。
为了验证身份，通过数字证书来证明公钥属于一个特定的实体。
Istio 的双向 TLS 场景下，服务端维护一个在 CA 上获取的服务端证书，在客户端请求时将该证书 回复给客户端。客户端使用CA的公钥进行验证，若验证通过，就可以拿到服务端的公钥，从而执行后面 的步骤。

因为Istio基于Citadel提供了自动生成、分发、轮换与撤销密钥和证书的功能，才避免了用户自己维护的麻烦事。
每个集群都有一个Citadel服务，Citadel服务主要做4个操作:

◎ 给每个Service Account都生成SPIFFE密钥证书对;
◎ 根据Service Account给对应的Pod分发密钥和证书对;
◎ 定期替换密钥证书;
◎ 根据需要撤销密钥证书。

5.2 istio服务认证配置
5.2.1 认证策略配置示例

含义：该配置为forecast开启双向认证，forecast服务使用双向认证来接收调用方的访问，只处理TLS通道上加密的请求

5.2.2 认证策略的定义
认证策略定义中的字段：
1)targets:
表示这个策略作用的目标对象，如果为空，则对策略作用范围内的所有服务都生效。
字段是一个数组类型，所以认证策略可以作用在多个服务的描述上，
数组 元素是一个TargetSelector类型的结构，name字段表示目标服务的名称，ports数组表示策略可以在服务的 端口粒度进行控制。
如下配置认证策略作用在两个服务 frontend 和 forecast 上，其中对于 forecast 服务只作用于3002端 口:
如图

2)peers:
认证方式有两种:传输认证和访问来源认证,peers用来描述传输认证的配置。
在 Istio这个字段一般被赋值mtls，如果不使用传输认证，则可以不用赋值。
mTLS 支持两种模式:STRICT 和 PERMISSIVE。
前者要求服务端和客户端都必须提供证书，即通过mTLS方式连接;
而后者可以省略客户端的证书，即服务端可以接收TLS和明文通信。
PERMISSIVE 模式在处理旧系统迁移时比较有用。如果对一个服务设置了默认的mTLS 认证，则来自老系统没有注入 Sidecar 的客户端请求可能会访问不通，因为它们没有带客户端证书。如下所示为设置 PERMISSIVE 可以在迁移过程中接收没有客户端证书的连接:
如图：

3)origins:
与传输认证对应的是Istio支持的另一种认证方式:访问来源认证，目前只支持JWT方式的来源身份认证。
JWT的来源认证有多项配置。
◎ issuer:JWT颁发者的标识，通常是URL或者Email地址。
◎ audiences:JWT的受众名单，包含这些Aud的JTW将被接收。 
◎ jwksUri:JWT验证的公钥URL。
◎ jwtHeaders:传送JWT的请求的Header。
◎ jwtParams:传送JWT的URL参数。
◎ triggerRules:用来判断是否使用 JTW来验证请求，只有在条件匹配时才会进行JWT验证。
如果触发规则非空但是没有条件匹配，则会跳过JWT验证;
如果这个字段为空，则总会执行JWT验证。

4)principalBinding:
描述使用传输身份认证还是来源身份认证和请求主体关联，对应USE_PEER和USE_ORIGIN。默认取值USE_PEER，表示传输身份认证。

5.2.3 TLS访问配置
认证策略配置后，服务端将使用证书校验客户端的访问，对应的服务调用方需要实现一定的认证机制才能完成认证。
客户端也有两种使用方式：
◎ 如果服务端要求来源认证，且当前只支持JWT，要求在客户端应用的访问请求中带上需要的JWT信息，则这只能由应用自己解决，Istio本身没有提供透明的手段。
◎ 如果服务端要求 mTLS传输认证，则可以使用服务规则 DestinationRule来配置。DestinationRule流量策略字段TrafficPolicy中包含一个TLSSettings的结构来描述TLS认证相关配置。

通过如下配置就可以使得对advertisement服务的访问使用双向TLS认证:

TLSSettings规则主要配置如下信息。
(1)mode:最重要的一个必选字段，用来表示是否使用TLS，以及使用哪种模式。在Istio中支持以 下4种模式。
◎ Disable:对指定服务的连接不使用TL。
◎ SIMPLE:发起与服务端的TLS连接。
◎ MUTUAL:使用双向认证对服务端发起安全连接，并且提供客户端证书。即需要应用程序提供客户端证书，在配置中指定证书文件路径。
◎ ISTIO_MUTUAL:使用双向认证对服务端发起安全连接，证书由Istio自动生成。即不用指定证书 路径等。
  
(2)clientCertificate:客户端证书路径，为 MUTUAL 模式时必须指定，为 ISTIO_MUTUAL模式时 无须指定。
(3)privateKey:客户端私钥路径，为 MUTUAL 模式时必须指定，为 ISTIO_MUTUAL模式时无须 指定。
(4)caCertificates:验证服务端证书的 CA 文件路径，若未指定则忽略校验服务端证书。为 ISTIO_MUTUAL模式时无须指定。
(5)subjectAltNames:验证在服务端证书中标识的列表文件，为 ISTIO_MUTUAL模式时无须指 定。
(6)sni:在 TLS 握手阶段提供给服务端的 SNI 字符串，为 ISTIO_MUTUAL 模式时无须指定。

clientCertificate、privateKey、caCertificates、subjectAltNames、sni字段都是用于双向认证的配置。
当模式是ISTIO_MUTUAL时，这些内容都会由Istio的证书管理功能自动生成，都不用手动配置;
而 MUTVAL 模式需要手动配置，麻烦的是，如果证书文件有变化，则需要手动更新。
所以推荐采用ISTIO_MUTUAL模式！

本节的配置要和认证策略的配置结合使用，只有对指定的服务配置了认证策略，同时对这些服务的 访问使用了对应的TLS配置，双方的访问才能正常进行。如下几种场景都会导致通信不正常。
◎ 给forecast服务配置了双向认证策略，但是在DestinationRule中未配置TLS，或者网格外的服务对 forecast服务的访问没有Envoy代理，则访问不通。
◎ 未给forecast服务配置双向认证策略，或者服务forecast属于网格外的服务，但是在DestinationRule 中配置了TLS，则访问不通。
若通过 DestinationRule为 advertisement服务启用了 ISTIO_MUTUL的 TLS模式，并且通过认证策略 Policy配置为 advertisement服务的访问启用了双向认证，开发者完全不用修改任何代码 和服务自身的配置，即可实现对advertisement服务的安全访问。

如下图：

5.2.4 认证策略的典型应用
1.认证策略的作用范围
整个网格范围的统一认证策略

说明：一种特殊的MeshPolicy，为Mesh级别的配置，并且策略的名字固定为“default”。
网格范围的认证策略对所有服务都生效。 除了能固定策略名，这种全局的配置只能定义一次，并且不能指定targets字段。

指定命名空间下的服务认证策略
说明：
可以通过 target 来指定作用于当前命名空间下的哪个服务。如果未指定 target，则表示作用于命名空间下的所有服 务，并且在同一命名空间下这种策略只能存在一个
实例如下图

Istio提供的认证策略包含三个范围。
◎ 全网格范围:作用于网格中的所有服务，通过认证策略MeshPolicy定义。
◎ 命名空间范围:作用于指定命名空间下的所有服务，通过认证策略 Policy 定义，不指定targets。
◎ Service范围:作用于命名空间下的特定Service，通过认证策略Policy定义，作用范围通过targets字
段来描述

对于一个服务只能有一种认证策略。如果以上三种策略都匹配，则采用本地优先原则。

若利用以上原则为某命名空间下除某个服务外的其他服务启用双向认证，则除了列举所有要认证的
服务，一个更便捷且好理解的做法是配置如下两个Policy:

2.组合TLS认证和来源认证
认证策略可以同时配置TLS认证和来源认证，方法是同时设置peer和origins两个字段。

5.3 istio服务授权配置

5.3.1 授权启用配置
1.ClusterRbacConfig配置示例
如下所示为只对 weather这个命名空间启用授权，对其他命名空间下的服务都不启用授权:

2.ClusterRbacConfig配置定义
语义上，ClusterRbacConfig是一个全局配置，所以这个配置只能创建一次，配置名也固定 是“default”
主要包含三个属性，其中mode字段表示授权配置的模式。
◎ OFF:为网格中的所有服务都禁用授权。
◎ ON:为网格中的所有服务都启用授权。
◎ ON_WITH_INCLUSION:只为inclusion列表中的namespaces和services启用Istio授权，对其他服务
全部禁用授权。
◎ ON_WITH_EXCLUSION:只为exclusion列表中的namespaces和services禁用Istio授权，对其他服务
全部启用授权。
另外两个字段 inclusion 和 exclusion 分别配置在 ON_WITH_INCLUSION 和ON_WITH_EXCLUSION
模式下启用和禁用授权的namespaces和services列表。

5.3.2 授权策略配置
1.授权策略配置示例
ServiceRole 定义了一个advertisement-reader角色，这个角色对advertisement服务的GET方法有权限;
同时通过ServiceRoleBinding定义了一个角色绑定配置，将advertisement-reader这个角色绑定到命名空间是terminal的服务上:

2.ServiceRole定义
用来配置一个角色，并给该角色定义一组权限。
AccessRule通过如下字段来描述。
(1)services:是 AccessRule 上最重要的一个必选字段，表示作用的服务集合。
services 可以是一个开放的表达式，可以匹配前 缀、后缀等。可以进行如下配置:

(2)paths:配置对应服务的接口列表，对于HTTP是Path列表，对于gRPC就是方法列表。
paths是一个可选字段，支持前缀后缀匹配，当未指定时，表示匹配所有 Path。可以进行如下配置:

(3)methods:在描述权限时，除了可以指定服务的接口，还可以指定接口的方法methods，对应 HTTP的GET、POST等方法。

(4)constraints:是一个 开放的键值对集合，讲解这几个扩展字 段。
◎destination.labels:目标服务上的标签。这也是Istio和Kubernetes结合的一种常用机制，例如比较常 用的基于版本标签做灰度发布，通过指定destination.labels[version]是["v1"]或者["v2"]来描述对服务的特定 版本的权限。
◎ request.headers:请求的 HTTP Header，通过 Header 上的取值来描述规则，例如 request.headers[login-group]的取值["editor"]表示特定Header的请求。
◎ destination.ip:目标服务实例的 IP 地址，可以是单个 IP，也可以是 CIDR 描述的地址，例如 ["10.154.118.69"，"10.154.0.0/16"]这种格式。
◎ destination.port:目标服务端口，可以是个数组，例如["3002"，"3003"]。
◎ destination.namespace:目标服务的命名空间。
◎ destination.user:在目标服务的负载上取到的标识。
这样，ServiceRole就支持从 namespace、services、paths、methods、constrainsts这几个不同的粒度描
述权限。

3.ServiceRoleBinding的规则定义
绑定两个对象:一个是定义的角色roleRef，另一个是 角色分配的目标对象subjects。
(1) roleRef:是一个必选字段，表示要绑定的角色。当前版本的 roleRef 只支持ServiceRole这一种 角色定义，要求ServiceRole和ServiceRoleBinding必须属于同一个命名空间。
(2)subjects:是一个必选字段，表示角色分配的目标。subjects是个列表，通过user和properties两个可选字段来定义subjects。
user表示对象的用户名或者ID，user:"*"表示授权给所有用户和服务，无论是认证的还是未认证的;
properties是一个Map，当前支持如下属性:
◎ source.ip:表示源服务实例的 IP地址，可以是单个 IP，也可以是 CIDR描述的地址，例如 ["10.154.118.69"，"10.154.0.0/16"]。
◎ source.namespace:源服务的命名空间。
◎ source.principal:源服务的标识，例如"cluster.local/ns/weather/sa/frontend"，是从证书上提取的源负 载的标识，表示只是授权给认证的frontend服务;而配置为"*"表示授权给所有认证用户和服务。
◎ request.headers:请求的 HTTP Header，通过 Header 上的取值来描述规则，例如 request.headers[login-group]取值["editor"]。在ServiceRole中同样有这个扩展字段，最终都是服务访问的过 滤条件。
◎ request.auth.principal:请求中的认证主体。
◎ request.auth.audiences:认证信息的目标受众。
◎ request.auth.presenter:授权的凭证提供者。
◎ request.auth.claims:来源JWT声明。

5.3.3 授权策略的典型应用
1.特定命名空间的授权
只允许一个命名空间下的服务访问另外一个命名空间下的服务，即某命名空间下的服务都使用一个授权访问策略。
如下所示为对 weather命名空间下的所有服务都定义一种角色，并且 只允许client命名空间下的服务访问:

2.特定服务的授权 
如下所示为配置通过GET方式访问advertisement服务

3.特定服务接口的授权
对一些敏感、重要的接口可能需要分配特定的授权策略。
通过添加 paths 字段， paths 可以通过数组定义多个，为有某种共同特点的一组接口定义一个角色:

4.特定版本的授权
基于ServiceRole的扩展属性constraints通过目标服务的label标签定义对服务的特定版本定义角色并进 行授权:

5.特定源IP的授权
老系统对网格内服务进行访问时，这些系统无 法提供自身的认证信息，但可以通过授权中对来源的特征进行适当限制来达到一定授权管理目标，并借 助ServiceRoleBinding的properties扩展对访问来源进行限制。如下所示为限制只有来自特定IP范围的请求 才可以访问advertisement服务:

https服务发布  https://help.aliyun.com/document_detail/164654.html?spm=5176.smartservice_service_chat.0.0.6f6e709a6TfAQ2