在Istio中，提供了两种身份验证模式，这两种方式是传输身份验证和原始身份验证。

• 传输身份验证，也称为服务到服务身份验证：验证建立直接连接的客户端。Istio提供双向TLS(mutual TLS)作为用于传输身份验证的完整堆栈解决方案。在Istion中可以轻松启用此功能，而无需更改服务代码。此解决方案：
• 为每个服务提供一个强大的标识，以表示其角色，以实现跨集群和云的互操作性。
• 保证服务到服务和最终用户到服务通信的安全。
• 提供密钥管理系统，以自动进行密钥和证书的生成、分发和轮换。
• 原始身份验证，也称为终端用户身份验证：将发出请求的原始客户端验证为最终用户或设备。Istio通过JSON Web令牌（JWT）验证启用请求级身份验证，并为开发人员提供使用OpenID Connect提供者（ORY Hydra，Keycloak，Auth0， Firebase Auth， Google Auth）和自定义身份验证的简化经验 。

在这两种情况下，Istio都会通过自定义的Kubernetes API在Istio config store存储身份验证策略。Pilot可以使每个代理服务器保持最新状态，并在适当时提供密钥。

1 双向TLS身份验证

Istio通过客户端和服务器端的Envoy代理建立服务到服务的通信通道。为使客户端通过双向TLS身份验证调用服务器端：

• Istio将来自客户端的出站流量重新路由到客户端的本地Sidecar Envoy。
• 客户端Envoy与服务器端Envoy开始双向TLS握手。在握手期间，客户端Envoy还会进行安全的命名检查，以验证服务器证书中提供的服务帐户是否有权运行目标服务。
• 客户端Envoy和服务器端Envoy建立双向TLS连接，Istio将流量从客户端Envoy转发到服务器端Envoy。
• 授权后，服务器端Envoy通过本地TCP连接将流量转发到服务器服务。

Istio双向TLS具有许可模式，该模式允许服务同时接受纯文本和双向TLS流量。此功能极大地改善了双向TLS的体验。与非Istio服务器通信的许多非Istio客户端给想要将服务器迁移到启用了TLS的Istio的操作员带来了问题。通常，操作员无法同时为所有客户端安装Istio sidecar，甚至没有权限在某些客户端上安装。即使在服务器上安装了Istio Sidecar之后，操作员也无法在不中断现有通信的情况下启用双向TLS。

启用许可模式后，服务器将接受纯文本和双向TLS流量。该模式为注册过程提供了极大的灵活性。服务器安装的Istio Sidecar会立即获取相互TLS流量，而不会破坏现有的纯文本流量。因此，运营商可以逐步安装和配置客户端的Istio边车，以发送相互的TLS流量。一旦完成客户端的配置，操作员就可以将服务器配置为仅TLS双向模式。

2 认证架构

在Istio网格中，可以使用身份验证策略为接收请求的服务指定身份验证要求。在网格运算符中，使用.yaml 文件来指定策略。部署后，策略将被保存在Istio配置存储，。Pilot作为Istio的控制器负责监视配置存储。在任何策略更改后，Pilot都会将新策略转换为适当的配置，以告诉Envoy Sidecar代理如何执行所需的身份验证机制。Pilot可以获取公共密钥，并将其附加到配置中以进行JWT验证。另外，Pilot提供了Istio系统管理的密钥和证书的路径，并将它们安装到应用程序容器中以实现相互TLS。Istio将配置异步的发送到目标端点。代理收到配置后，新的身份验证要求将立即在该容器上生效。

客户端服务（发送请求的服务）负责遵循必要的身份验证机制。对于原始身份验证（JWT），应用程序负责获取JWT凭证并将其附加到请求。对于双向TLS，Istio提供了目标规则。运算符使用目标规则，来指示客户端代理使用TLS（带有服务器端预期的证书）进行初始连接。

认证架构

Istio将身份验证与身份验证的类型以及证书中的其他声明（如果适用）一起输出到下一层： 访问授权（authorization）。此外，运算符可以指定在Istio中作为“主体”的身份（通过传输身份验证或原始身份验证）。

3 认证策略

本节提供有关Istio身份验证策略如何工作的更多详细信息。与其它Istio配置一样，可以在.yaml文件中指定身份验证策略 。如果使用的平台是Kubernetes，则可以使用kubectl部署策略。

在下面的示例中，身份验证策略指定reviews服务的传输身份验证必须使用双向TLS：

#——-设置reviews服务的身份认证策略—

apiVersion: “authentication.istio.io/v1alpha1”

kind: “Policy”

metadata:

name: “reviews”

spec:

targets:

– name: reviews

peers:

– mtls: {}

表 认证策略字段

1.1.3.1     策略应用范围

Istio可以将身份验证策略存储在名称空间范围或网格范围的存储中。

• 网格范围的策略通过指定kind字段的值为”MeshPolicy”，以及设置策略名称为”default”。例如：

apiVersion: “authentication.istio.io/v1alpha1”

kind: “MeshPolicy”

metadata:

name: “default”

spec:

peers:

– mtls: {}

• 命名空间范围的策略通过指定kind 字段的值为”Policy”，以及指定一个命名空间。如果未指定，则使用默认名称空间，此示例中的命名空间为ns1。

apiVersion: “authentication.istio.io/v1alpha1”

kind: “Policy”

metadata:

name: “default”

namespace: “ns1”

spec:

peers:

– mtls: {}

命名空间范围存储的策略只会影响本名称空间中的服务。网格范围存储的策略会影响网格中的所有服务。为了防止冲突和滥用，只能在网格范围定义一个策略。该策略必须命名为default，并具有 空值的targets:。在Kubernetes中，通过自定义资源（CRD）实现Istio配置。这些CRD对应于命名空间范围和集群范围，CRDs通过Kubernetes RBAC自动继承访问保护。

1.1.3.2     目标选择器

身份验证策略的目标指定该策略适用的一个或多个服务。以下示例指定该策略适用于：

• product-page服务的任何端口。
• reviews服务的9000端口。

targets:

– name: product-page

– name: reviews

ports:

– number: 9000

如果未提供targets，则Istio会将策略与策略所在存储范围内的所有服务进行匹配。因此，通过targets可以指定策略的应用范围：

• 网格范围的策略：在网格范围定义，并且没有目标选择器，这种策略只能设置一个。
• 命名空间范围的策略：在命名空间范围定义的策略，策略名称为default，并且没有目标选择器。每个命名空间最多可以定义一个命名空间范围的策略。
• 特定服务的策略：在命名空间定义的策略，带有非空的目标选择器。名称空间可以定义多个特定服务的策略。

对于每种服务，Istio都会应用最窄的匹配策略。优先顺序为： 特定服务的策略>命名空间范围的策略>网格范围的策略。如果存在一个以上特定服务的策略与服务匹配，则Istio会随机选择其中之一，在配置其策略时必须避免此类冲突。

为了对网格范围和命名空间范围的策略强制唯一性，Istio每个网格仅接受一个身份验证策略，每个命名空间仅接受一个身份验证策略。Istio还要求网状范围和命名空间范围的策略的名称为default。如果服务没有匹配的策略，则会禁用传输身份验证和原始身份验证。

表 目标选择器字段

1.1.3.3     传输认证

Peers用于定义支持传输身份验证的验证方法和相关参数。从Istio 0.7版本开始，只支持双向TLS这种唯一的传输身份验证方法。

以下示例显示了peers使用双向TLS的传输身份验证。

peers:

– mtls: {}

相互TLS设置具有一个可选mode参数，该参数定义对等传输身份验证的严格性。默认的双向TLS模式为STRICT。因此，mode: STRICT等效于以下所有：

• mtls: {}
• mtls:
• mtls: null

如果不指定双向TLS模式，则对等方无法使用传输身份验证，并且Istio拒绝绑定到Sidecar的双向TLS连接。在应用程序层，服务仍可以处理它们自己的相互TLS会话。

1.1.3.4     原始身份验证

origins定义了源身份验证支持的验证方法和相关参数。Istio仅支持JWT原始身份验证。可以指定允许的JWT颁发者，并为特定路径启用或禁用JWT身份验证。如果为请求路径禁用了所有JWT，则身份验证也会通过，就像没有定义任何身份验证一样。与对等身份验证类似，只有且只满足一种列出的方法必须才能通过身份验证。

以下示例中，策略指定了用于原始身份验证，该部分接受Google发出的JWT。路径的JWT身份验证/health已禁用。

origins:

– jwt:

issuer: “https://accounts.google.com”

jwksUri: “https://www.googleapis.com/oauth2/v3/certs”

trigger_rules:

– excluded_paths:

– exact: /health

1.1.3.5     主体绑定

主体绑定键值对定义策略的主体。默认情况下，Istio使用peers配置的身份验证。如果peers未配置身份验证，则Istio会将身份验证保留为未设置状态。策略编写者可以使用USE_ORIGIN值覆盖此行为。此值将Istio配置为使用源身份验证作为主体身份验证。将来，将支持条件绑定，例如：USE_PEER当peer为X时，否则为 USE_ORIGIN。

以下示例显示principalBinding的值 USE_ORIGIN：

principalBinding: USE_ORIGIN

4 更新身份验证策略

可以随时更改身份验证策略，Istio几乎实时地将更改推送到端点。但是，Istio无法保证所有端点都同时收到新策略。以下是在更新身份验证策略时避免中断的建议：

• 要启用或禁用双向TLS：使用带有mode: PERMISSIVE临时策略。这将接收服务配置为能够接受两种类型的流量：纯文本和TLS。因此，没有请求将会被丢弃。一旦所有客户端切换到预期的协议，无论是否具有相互TLS，都可以用最终策略将PERMISSIVE策略替换掉。

peers:

– mtls:

mode: PERMISSIVE

• 对于JWT身份验证迁移：更改策略之前，请求应包含新的JWT。服务器端完全切换到新策略后，可以删除旧的JWT（如果有的话）。为了使这些更改生效，需要更改客户端应用程序。

5 身份认证示例

5.1    全局启用Istio双向TLS

通过执行下面的命令启用网格范围的双向TLS身份验证策略。

$ kubectl apply -f {path/to}/meshpolicy.yaml

meshpolicy.yaml策略文件的内容如下，策略的类型为MeshPolicy，策略的名称为default。

apiVersion: “authentication.istio.io/v1alpha1”

kind: “MeshPolicy”

metadata:

name: “default”

spec:

peers:

– mtls: {}

配置客户端时，需要设置目标规则使用双向TLS。对于每一个适用的服务（或名称空间），可以使用多个目标规则。通过执行下面的命令创建目标规则：

$ kubectl apply -f {path/to}/demo-destinationrule.yaml

在istio-system命名空间下，创建一个名称为default的目标规则，流量策略mode: ISTIO_MUTUAL。

apiVersion: “networking.istio.io/v1alpha3”

kind: “DestinationRule”

metadata:

name: “default”

namespace: “istio-system”

spec:

host: “*.local”

trafficPolicy:

tls:

mode: ISTIO_MUTUAL

作者简介：

季向远，北京神舟航天软件技术有限公司。本文版权归原作者所有。