Istio Service Mesh中的受权与鉴权概念详解

上周给你们分享了一篇必读！Istio Service Mesh中的流量管理概念解析，此次再给你们分享一篇Istio中重要功能和概念——受权（authorization）与鉴权（authentication）的解析。

将单体应用程序分解为微服务可提供各类好处，包括更好的灵活性、可伸缩性以及服务复用的能力。可是，微服务也有特殊的安全需求：

• 为了抵御中间人攻击，须要流量加密。

• 为了提供灵活的服务访问控制，须要双向 TLS 和细粒度的访问策略。

• 要审核谁在何时作了什么，须要审计工具。

Istio Security 尝试提供全面的安全解决方案来解决全部这些问题。

本页概述了如何使用 Istio 的安全功能来保护您的服务，不管您在何处运行它们。特别是 Istio 安全性能够缓解针对您的数据，端点，通讯和平台的内部和外部威胁。

Istio 安全概述

Istio 安全功能提供强大的身份，强大的策略，透明的 TLS 加密以及用于保护您的服务和数据的身份验证，受权和审计（AAA）工具。 Istio 安全的目标是：

• 默认安全 : 应用程序代码和基础结构无需更改

• 深度防护 : 与现有安全系统集成，提供多层防护

• 零信任网络 : 在不受信任的网络上构建安全解决方案

访问咱们的Mutual TLS Migration docs，开始在部署的服务中使用Istio安全功能。 请访问咱们的安全任务，有关使用安全功能的详细说明。

如图所示，Istio 的 Citadel 用加载 Secret 卷的方式在 Kubernetes 容器中完成证书和密钥的分发。若是服务运行在虚拟机或物理机上，则会使用运行在本地的 Node agent，它负责在本地生成私钥和 CSR（证书签发申请），把 CSR 发送给 Citadel 进行签署，并把生成的证书和私钥分发给 Envoy。

顶层架构

Istio 中的安全性涉及多个组件：

• Citadel 用于密钥和证书管理

• Sidecar 和周边代理 实现客户端和服务器之间的安全通讯

• Pilot 将受权策略和安全命名信息分发给代理

• Mixer 管理受权和审计

Istio 安全架构

在下面的部分中，咱们将详细介绍 Istio 安全功能。

Istio 身份

身份是任何安全基础架构的基本概念。在服务到服务通讯开始时，双方必须与其身份信息交换凭证以用于相互认证目的。 在客户端，根据安全命名信息检查服务器的标识，以查看它是不是该服务的受权运行程序。 在服务器端，服务器能够根据受权策略 肯定客户端能够访问哪些信息，审核谁在什么时间访问了什么，根据服务向客户收费他们使用并拒绝任何未能支付帐单的客户访问服务。

在 Istio 身份模型中，Istio 使用一流的服务标识来肯定服务的身份。 这为表示人类用户，单个服务或一组服务提供了极大的灵活性和粒度。 在没有此类身份的平台上，Istio 可使用能够对服务实例进行分组的其余身份，例如服务名称。

不一样平台上的 Istio 服务标识：

• Kubernetes: Kubernetes 服务账户

• GKE/GCE: 可使用 GCP 服务账户

• GCP: GCP 服务账户

• AWS: AWS IAM 用户/角色 账户

• On-premises (non-Kubernetes): 用户账户，自定义服务账户，服务名称，istio 服务账户或 GCP 服务账户。

自定义服务账户引用现有服务账户，就像客户的身份目录管理的身份同样。

Istio 安全与 SPIFFE

SPIFFE 标准提供了一个框架规范，该框架可以跨异构环境引导和向服务发布身份。

Istio 和 SPIFFE 共享相同的身份文件：SVID (SPIFFE可验证身份证件）。 例如，在 Kubernetes 中，X.509 证书的 URI 字段格式为”spiffe:///ns//sa/“。 这使 Istio 服务可以创建和接受与其余 SPIFFE 兼容系统的链接。

Istio 安全性和 SPIRE，它是 SPIFFE 的实现，在 PKI 实现细节上有所不一样。 Istio 提供更全面的安全解决方案，包括身份验证，受权和审计。

PKI

Istio PKI 创建在 Istio Citadel 之上，可为每一个工做负载安全地提供强大的工做负载标识。 Istio 使用 X.509 证书来携带 SPIFFE 格式的身份。 PKI 还能够大规模自动化密钥和证书轮换。

Istio 支持在 Kubernetes pod 和本地计算机上运行的服务。 目前，咱们为每一个方案使用不一样的证书密钥配置机制。

Kubernetes 方案

1. Citadel 监视 Kubernetes apiserver，为每一个现有和新的服务账户建立 SPIFFE 证书和密钥对。Citadel 将证书和密钥对存储为 Kubernetes secret。

2. 建立 pod 时，Kubernetes 会根据其服务账户经过 Kubernetes secret volume将证书和密钥对挂载到 pod。

3. Citadel 监视每一个证书的生命周期，并经过重写 Kubernetes 秘密自动轮换证书。

4. Pilot 生成安全命名信息，该信息定义了哪些 Service Account 能够运行哪些服务。Pilot 而后将安全命名信息传递给sidecar envoy。

本地机器方案

1. Citadel 建立 gRPC 服务以获取证书签名请求（CSR）。

2. 节点代理生成私钥和 CSR，并将 CSR 及其凭据发送给 Citadel 进行签名。

3. Citadel 验证 CSR 承载的凭证，并签署 CSR 以生成证书。

4. 节点代理将从 Citadel 接收的证书和私钥发送给 Envoy。

5. 上述 CSR 过程会按期重复进行证书和密钥轮换。

代理程序代理节点（开发中）

在不久的未来，Istio 将在 Kubernetes 中使用节点代理进行证书和密钥提供，以下图所示。请注意，本地计算机的标识提供流程是相同的，所以咱们仅描述 Kubernetes 方案。

PKI 与 Kubernetes 中的节点代理

流程以下：

1. Citadel 建立一个 gRPC 服务来接受 CSR 请求。

2. Envoy 经过 Envoy secret 发现服务（SDS）API 发送证书和密钥请求。

3. 收到 SDS 请求后，节点代理会建立私钥和 CSR，并将 CSR 及其凭据发送给 Citadel 进行签名。

4. Citadel 验证 CSR 中携带的凭证，并签署 CSR 以生成证书。

5. 节点代理经过 Envoy SDS API 将从 Citadel 接收的证书和私钥发送给 Envoy。

6. 上述 CSR 过程会按期重复进行证书和密钥轮换。

最佳实践

在本节中，咱们提供了一些部署指南并讨论了一个真实的场景。

部署指南

若是有多个服务运维团队（又名 SRE）在中型或大型集群中部署不一样的服务，咱们建议建立一个单独的 Kubernetes 命名空间（namespace）让每一个 SRE 团队隔离本身的访问权限。例如，您能够为 team1 建立 team1-ns 命名空间，为 team2 建立 team2-ns 命名空间，这样两个团队都没法访问彼此的服务。

⚠️若是 Citadel 遭到入侵，则可能会暴露集群中的全部托管密钥和证书。咱们强烈建议在专用命名空间中运行 Citadel（例如， istio-citadel-ns），以便仅限管理员访问群集。

示例

让咱们考虑一个带有三种服务的三层应用程序： photo-frontend， photo-backend 和 datastore。照片 SRE 团队管理 photo-frontend 和 photo-backend 服务，而数据存储 SRE 团队管理 datastore 服务。 photo-frontend服务能够访问 photo-backend， photo-backend服务能够访问 datastore。可是， photo-frontend服务没法访问 datastore。

在这种状况下，集群管理员建立三个命名空间： istio-citadel-ns， photo-ns和 datastore-ns。管理员能够访问全部命名空间，每一个团队只能访问本身的命名空间。照片SRE团队建立了两个服务账户，分别在 photo-ns命名空间中运行 photo-frontend和 photo-backend。数据存储区 SRE 团队建立一个服务账户，以在 datastore-ns命名空间中运行 datastore服务。此外，咱们须要在 Istio Mixer 中强制执行服务访问控制，使得 photo-frontend没法访问数据存储区。

在此设置中，Kubernetes 能够隔离运维人员管理服务的权限。 Istio 管理全部命名空间中的证书和密钥，并对服务实施不一样的访问控制规则。

认证

Istio 提供两种类型的身份验证：

• 传输身份验证，也称为服务间身份验证：验证直接客户端进行链接。Istio 提供双向 TLS 做为传输身份验证的完整堆栈解决方案。 您能够轻松打开此功能，而无需更改服务代码。这个解决方案：

• 为每一个服务提供强大的身份，表示其角色，以实现跨群集和云的互操做性。

• 保护服务到服务通讯和最终用户到服务通讯。

• 提供密钥管理系统，以自动执行密钥和证书生成、分发和轮换。

• 来源身份认证，也称为最终用户身份验证：验证原始客户端将请求做为最终用户或设备。 Istio 经过 JSON Web Token（JWT）验证和 Auth0、 FirebaseAuth 、 GoogleAuth 和自定义身份验证来简化开发人员体验，而且轻松实现请求级别的身份验证。

在这两种状况下，Istio 都经过自定义 Kubernetes API 将身份认证策略存储在 Istio配置存储中。 Pilot 会在适当的时候为每一个代理以及密钥更新为最新状态。此外，Istio 支持在许可模式下进行身份验证，以帮助您了解策略更改在其生效以前如何影响您的安全状态。

双向 TLS 认证

Istio 隧道经过客户端和服务器端进行服务间通讯 Envoy 代理。对于客户端调用服务器，遵循的步骤是：

1. Istio 将出站流量从客户端从新路由到客户端的本地 sidecar Envoy。

2. 客户端 Envoy 与服务器端 Envoy 开始双向 TLS 握手。在握手期间，客户端 Envoy 还执行安全命名检查，以验证服务器证书中提供的服务账户是否有权运行目标服务。

3. 客户端 Envoy 和服务器端 Envoy 创建了一个双向的 TLS 链接，Istio 将流量从客户端 Envoy 转发到服务器端 Envoy。

4. 受权后，服务器端 Envoy 经过本地 TCP 链接将流量转发到服务器服务。

安全命名

安全命名信息包含来自服务器标识的 N 到 N 映射，这些映射在证书中编码到由发现服务或 DNS 引用的服务名称。从身份 A 到服务名称 B 的映射意味着“容许 A 并受权其运行服务 B ”。 Pilot 监视 Kubernetes apiserver，生成安全的命名信息，并将其安全地分发给 sidecar Envoy。如下示例说明了为何安全命名在身份验证中相当重要。

假设运行服务 datastore 的合法服务器仅使用 infra-team 标识。恶意用户拥有 test-team 身份的证书和密钥。恶意用户打算模拟服务以检查从客户端发送的数据。恶意用户使用证书和 test-team 身份的密钥部署伪造服务器。假设恶意用户成功攻击了发现服务或 DNS，以将 datastore 服务名称映射到伪造服务器。

当客户端调用 datastore 服务时，它从服务器的证书中提取 test-team 标识，并检查是否容许 test-team 运行带有安全命名信息的 datastore。客户端检测到 test-team 不容许运行 datastore 服务，而且验证失败。

认证架构

您可使用身份认证策略为在 Istio 网格中接收请求的服务指定身份验证要求。网格操做者使用 .yaml 文件来指定策略。部署后，策略将保存在 Istio 配置存储中。 Pilot、Istio 控制器监视配置存储。一有任何的策略变动，Pilot 会将新策略转换为适当的配置，告知 Envoy sidecar 代理如何执行所需的身份验证机制。 Pilot 能够获取公钥并将其附加到 JWT 验证配置。或者，Pilot 提供 Istio 系统管理的密钥和证书的路径，并将它们挂载到应用程序窗格以进行双向 TLS。您能够在 PKI 部分中找到更多信息。 Istio 异步发送配置到目标端点。代理收到配置后，新的身份验证要求会当即生效。

发送请求的客户端服务负责遵循必要的身份验证机制。对于源身份验证（JWT），应用程序负责获取 JWT 凭据并将其附加到请求。对于双向 TLS，Istio 提供目标规则。运维人员可使用目标规则来指示客户端代理使用TLS与服务器端预期的证书进行初始链接。您能够在PKI和身份部分中找到有关双向 TLS 如何在 Istio 中工做的更多信息。

认证架构

Istio 将两种类型的身份验证以及凭证中的其余声明（若是适用）输出到下一层：受权。此外，运维操做者能够指定将传输或原始身份验证中的哪一个身份做为 委托人使用。

认证策略

本节中提供了更多 Istio 认证策略方面的细节。正如认证架构中所说的，认证策略是对服务收到的请求生效的。要在双向 TLS 中指定客户端认证策略，须要在 DetinationRule 中设置 TLSSettings。TLS 设置参考文档中有更多这方面的信息。和其余的 Istio 配置同样，能够用 .yaml 文件的形式来编写认证策略，而后使用 istioctl 进行部署。

下面例子中的认证策略要求 reviews 服务必须使用双向 TLS：

1. apiVersion: "authentication.istio.io/v1alpha1"

2. kind: "Policy"

3. metadata:

4.  name: "reviews"

5. spec:

6.  targets:

7.  - name: reviews

8.    peers:

9.  - mtls: {}

策略存储范围

Istio 能够在命名空间范围或网络范围存储中存储身份认证策略：

为 kind 字段指定了网格范围策略，其值为 MeshPolicy，名称为 default。例如：

1. apiVersion: "authentication.istio.io/v1alpha1"

2. kind: "MeshPolicy"

3. metadata:

4.  name: "default"

5. spec:

6.  peers:

7.  - mtls: {}

 

为 kind 字段和指定的命名空间指定命名空间范围策略，其值为 Policy。若是未指定，则使用默认命名空间。例如，命名空间 ns1：

1. apiVersion: "authentication.istio.io/v1alpha1"

2. kind: "Policy"

3. metadata:

4.  name: "default"

5.  namespace: "ns1"

6. spec:

7.  peers:

8.  - mtls: {}

命名空间范围存储中的策略只能影响同一命名空间中的服务。 mesh-scope 中的策略能够影响网格中的全部服务。为防止冲突和滥用，只能在网状范围存储中定义一个策略。该策略必须命名为 default而且有一个空的 targets：部分。您能够在咱们的目标选择器部分中找到更多信息。

目标选择器

身份认证策略的目标指定策略适用的服务。如下示例显示了一个 targets：部分，指定该策略适用于：

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

• 端口 9000上的评论服务。

1. targets:

2. - name: product-page

3. - name: reviews

4.   ports:

5.   - number: 9000

若是您未提供 targets：部分，则 Istio 将策略与策略存储范围内的全部服务匹配。所以， targets：部分能够帮助您指定策略的范围：

• 网格范围策略：在网格范围存储中定义的策略，没有目标选择器部分。网格中最多只能有一个网格范围的策略。

• 命名空间范围的策略：在命名空间范围存储中定义的策略，名称为 default 且没有目标选择器部分。每一个命名空间最多只能有一个命名空间范围的策略。

• 特定于服务的策略：在命名空间范围存储中定义的策略，具备非空目标选择器部分。命名空间能够具备零个，一个或多个特定于服务的策略。

对于每项服务，Istio 都应用最窄的匹配策略。顺序是：特定于服务>命名空间范围>网格范围。若是多个特定于服务的策略与服务匹配，则 Istio 随机选择其中一个。运营商在配置其策略时必须避免此类冲突。

为了强制网状范围和命名空间范围的策略的惟一性，Istio 每一个网格只接受一个身份认证策略，每一个命名空间只接受一个身份认证策略。 Istio 还要求网格范围和命名空间范围的策略具备特定名称 default。

传输认证

peers：部分定义了策略中传输身份验证支持的身份验证方法和相关参数。该部分能够列出多个方法，而且只有一个方法必须知足认证才能经过。可是，从 Istio 0.7 版本开始，当前支持的惟一传输身份验证方法是双向 TLS。若是您不须要传输身份验证，请彻底跳过此部分。

如下示例显示了使用双向 TLS 启用传输身份验证的 peers：部分。

1. peers:

2.  - mtls: {}

目前，双向 TLS 设置不须要任何参数。所以， -mtls：{}， -mtls：或 -mtls：null声明被视为相同。未来，双向 TLS 设置能够携带参数以提供不一样的双向 TLS 实现。

来源身份认证

origins: 部分定义了原始身份验证支持的身份验证方法和相关参数。 Istio 仅支持 JWT 原始身份验证。可是，策略能够列出不一样发行者的多个 JWT。与传输身份验证相似，只有一种列出的方法必须知足身份验证才能经过。

如下示例策略为原始身份验证指定了一个 origin: 部分，该部分接受 Google 发布的 JWT：

1. origins:

2. - jwt:

3.    issuer: "https://accounts.google.com"

4.    jwksUri: "https://www.googleapis.com/oauth2/v3/certs"

主认证绑定

主认证关系用键值对的方式存储绑定关系。默认状况下，Istio 使用 peers: 部分中配置的身份验证。若是在 peers： 部分中未配置身份验证，则 Istio 将保留身份验证。策略编写者可使用 USE_ORIGIN 值覆盖此行为。此值将 Istio 配置为使用 origin 的身份验证做为主体身份验证。未来，咱们将支持条件绑定，例如：当传输体为X时为 USE_PEER，不然为 USE_ORIGIN。

如下示例显示了 principalBinding 键，其值为 USE_ORIGIN：

1. principalBinding: USE_ORIGIN

更新认证策略

您能够随时更改身份认证策略，Istio 几乎实时地将更改推送到端点。可是，Istio 没法保证全部端点同时收到新策略。如下是在更新身份认证策略时避免中断的建议：

• 启用或禁用双向 TLS：使用带有 mode：键和 PERMISSIVE值的临时策略。这会将接收服务配置为接受两种类型的流量：纯文本和 TLS。所以，不会丢弃任何请求。一旦全部客户端切换到预期协议，不管是否有双向 TLS，您均可以将 PERMISSIVE 策略替换为最终策略。有关更多信息，请访问双向 TLS 的迁移。

1. peers:

2. - mtls:

3.    mode: PERMISSIVE

• 对于 JWT 身份验证迁移：在更改策略以前，请求应包含新的 JWT。一旦服务器端彻底切换到新策略，旧JWT（若是有的话）能够被删除。须要更改客户端应用程序才能使这些更改生效。

受权和鉴权

Istio 的受权功能 - 也称为基于角色的访问控制（RBAC） - 为 Istio Mesh 中的服务提供命名空间级别，服务级别和方法级别的访问控制。它的特色是：

• 基于角色的语义，简单易用。

• 服务到服务和最终用户对服务的受权。

• 经过自定义属性支持的灵活性，例如条件，角色和角色绑定。

• 高性能，由于 Istio 受权是在 Envoy 本地强制执行的。

受权架构

Istio 受权架构

上图显示了基本的 Istio 受权体系结构。运维人员使用 .yaml文件指定 Istio 受权策略。部署后，Istio 将策略保存在 IstioConfigStore中。

Pilot 监督 Istio 受权策略的变动。若是发现任何更改，它将获取更新的受权策略。 Pilot 将 Istio 受权策略分发给与服务实例位于同一位置的 Envoy 代理。

每一个 Envoy 代理都运行一个受权引擎，该引擎在运行时受权请求。当请求到达代理时，受权引擎根据当前受权策略评估请求上下文，并返回受权结果 ALLOW或 DENY。

启用受权

您可使用 RbacConfig 对象启用 Istio Authorization。 RbacConfig对象是一个网格范围的单例，其固定名称值为 default。您只能在网格中使用一个 RbacConfig实例。与其余 Istio 配置对象同样， RbacConfig被定义为Kubernetes CustomResourceDefinition(CRD)对象。

在 RbacConfig对象中，运算符能够指定 mode值，它能够是：

• OFF：禁用 Istio 受权。

• ON：为网格中的全部服务启用了 Istio 受权。

• ONWITHINCLUSION：仅对 包含字段中指定的服务和命名空间启用 Istio 受权。

• ONWITHEXCLUSION：除了 排除字段中指定的服务和命名空间外，网格中的全部服务都启用了 Istio 受权。

在如下示例中，为 default命名空间启用了 Istio 受权。

1. apiVersion: "rbac.istio.io/v1alpha1"

2. kind: RbacConfig

3. metadata:

4.  name: default

5.  namespace: istio-system

6. spec:

7.  mode: 'ON_WITH_INCLUSION'

8.  inclusion:

9.    namespaces: ["default"]

受权策略

要配置 Istio 受权策略，请指定 ServiceRole和 ServiceRoleBinding。与其余 Istio 配置对象同样，它们被定义为Kubernetes CustomResourceDefinition (CRD)对象。

• ServiceRole定义了一组访问服务的权限。

• ServiceRoleBinding向特定主题授予 ServiceRole，例如用户，组或服务。

ServiceRole 和 ServiceRoleBinding 的组合规定： 容许谁在 哪些条件下 作什么 。特别：

• 谁指的是 ServiceRoleBinding 中的 subject 部分。

• 作什么指的是 ServiceRole 中的 permissions 部分。

• 哪些条件指的是你能够在 ServiceRole 或 ServiceRoleBinding 中使用Istio属性指定的 conditions 部分。

ServiceRole

ServiceRole 规范包括 规则，AKA 权限列表。每条规则都有如下标准字段：

• services：服务名称列表。您能够将值设置为 * 以包括指定命名空间中的全部服务。

• methods：HTTP 方法名称列表，对于 gRPC 请求的权限，HTTP 动词始终是 POST 。您能够将值设置为 * 以包含全部 HTTP 方法。

• paths：HTTP 路径或 gRPC 方法。 gRPC 方法必须采用 /packageName.serviceName/methodName的形式，而且区分大小写。

ServiceRole 规范仅适用于 metadata 部分中指定的命名空间。规则中须要 services 和 methods 字段。 paths 是可选的。若是未指定规则或将其设置为 *，则它适用于任何实例。

下面的示例显示了一个简单的角色： service-admin，它能够彻底访问 default 命名空间中的全部服务。

1. apiVersion: "rbac.istio.io/v1alpha1"

2. kind: ServiceRole

3. metadata:

4.  name: service-admin

5.  namespace: default

6. spec:

7.  rules:

8.  - services: ["*"]

9.    methods: ["*"]

这是另外一个角色： products-viewer，它有读取， GET 和 HEAD，访问 default 命名空间中的 products.default.svc.cluster.local服务。

1. apiVersion: "rbac.istio.io/v1alpha1"

2. kind: ServiceRole

3. metadata:

4.  name: products-viewer

5.  namespace: default

6. spec:

7.  rules:

8.  - services: ["products.default.svc.cluster.local"]

9.    methods: ["GET", "HEAD"]

此外，咱们支持规则中全部字段的前缀匹配和后缀匹配。例如，您能够在 default命名空间中定义具备如下权限的 tester 角色：

• 彻底访问前缀为 test-* 的全部服务，例如： test-bookstore， test-performance， test-api.default.svc.cluster.local。

• 阅读（ GET）使用 */reviews后缀访问全部路径，例如： /books/reviews, /events/booksale/reviews， /reviews in service bookstore.default.svc.cluster.local。

1. apiVersion: "rbac.istio.io/v1alpha1"

2. kind: ServiceRole

3. metadata:

4.  name: tester

5.  namespace: default

6. spec:

7.  rules:

8.  - services: ["test-*"]

9.    methods: ["*"]

10.  - services: ["bookstore.default.svc.cluster.local"]

11.    paths: ["*/reviews"]

12.    methods: ["GET"]

在 ServiceRole中， namespace + services + paths + methods的组合定义了如何访问服务。 在某些状况下，您可能须要为规则指定其余条件。例如，规则可能仅适用于服务的某个版本，或仅适用于具备特定标签的服务， 如 foo。您可使用 constraints 轻松指定这些条件。

例如，下面的 ServiceRole 定义添加了一个约束， request.headers[version]是 v1或 v2扩展了之前的 products-viewer角色。 约束支持的 key值列在约束和属性页面中。在属性是 map的状况下，例如 request.headers， key是map中的一个条目，例如 request.headers[version]。

1. apiVersion: "rbac.istio.io/v1alpha1"

2. kind: ServiceRole

3. metadata:

4.  name: products-viewer-version

5.  namespace: default

6. spec:

7.  rules:

8.  - services: ["products.default.svc.cluster.local"]

9.    methods: ["GET", "HEAD"]

10.    constraints:

11.    - key: request.headers[version]

12.      values: ["v1", "v2"]

ServiceRoleBinding

ServiceRoleBinding 规范包括两部分：

• roleRef指的是同一命名空间中的 ServiceRole 资源。

• subjects 分配给角色的列表。

您可使用 user 或一组 properties 显式指定 subject。 ServiceRoleBinding subject 中的 property 相似于 ServiceRole 规范中的 constraint 。 property 还容许您使用条件指定分配给此角色的一组账户。它包含一个 key及其容许的值。约束支持的 key 值列在约束和属性页面中。

下面的例子显示了一个名为 test-binding-products 的 ServiceRoleBinding，它将两个主题绑定到名为 product-viewer 的 ServiceRole 并具备如下 subject

• 表明服务的服务账户 a， service-account-a。

• 表明 Ingress 服务的服务账户 istio-ingress-service-account 而且 JWT中的 mail 项声明为 a@foo.com。

1. apiVersion: "rbac.istio.io/v1alpha1"

2. kind: ServiceRoleBinding

3. metadata:

4.  name: test-binding-products

5.  namespace: default

6. spec:

7.  subjects:

8.  - user: "service-account-a"

9.  - user: "istio-ingress-service-account"

10.    properties:

11.      request.auth.claims[email]: "a@foo.com"

12.    roleRef:

13.    kind: ServiceRole

14.    name: "products-viewer"

若是您想要公开访问服务，能够将 subject 设置为 user："*" 。此值将 ServiceRole 分配给全部（通过身份验证和未经身份验证的）用户和服务，例如：

1. apiVersion: "rbac.istio.io/v1alpha1"

2. kind: ServiceRoleBinding

3. metadata:

4.  name: binding-products-allusers

5.  namespace: default

6. spec:

7.  subjects:

8.  - user: "*"

9.    roleRef:

10.    kind: ServiceRole

11.    name: "products-viewer"

要将 ServiceRole分配给通过身份验证的用户和服务，请使用 source.principal："*"代替，例如：

1. apiVersion: "rbac.istio.io/v1alpha1"

2. kind: ServiceRoleBinding

3. metadata:

4.  name: binding-products-all-authenticated-users

5.  namespace: default

6. spec:

7.  subjects:

8.  - properties:

9.      source.principal: "*"

10.    roleRef:

11.    kind: ServiceRole

12.    name: "products-viewer"

使用其余受权机制

虽然咱们强烈建议使用 Istio 受权机制，但 Istio 足够灵活，容许您经过 Mixer 组件插入本身的身份验证和受权机制。 要在 Mixer 中使用和配置插件，请访问咱们的策略和遥测适配器文档。

点击【阅读原文】能够直接访问文中的连接。

参与社区

如下是参与ServiceMesher社区的方式，最简单的方式是联系我！

• 加入微信交流群：关注本微信公众号后访问主页右下角有获取联系方式按钮，添加好友时请注明姓名-公司

• 社区网址：http://www.servicemesher.com

• Slack：https://servicemesher.slack.com （须要邀请才能加入）

• GitHub：https://github.com/servicemesher

• Istio中文文档进度追踪：https://github.com/servicemesher/istio-official-translation

• Twitter: https://twitter.com/servicemesher

• 提供文章线索与投稿：https://github.com/servicemesher/trans