Pilot 生成安全命名信息，该信息定义了哪些服务帐户可以运行某个服务。接着Pilot 将安全命名信息传递给 Envoy。
3 如何告诉Istio发挥保护能力？如上一章节所言，Istio基于控制面组件，引入了一流的服务账户系统，结合强大的PKI，实现了对服务网格的安全守护。同时，Istio也开放了接口，让我们可以进行精细化的配置，全方位满足我们对服务的安全需求。
服务安全，总是离不开两个具体过程：认证（Authentication）和鉴权（Authorization）。Istio通过Policy和MeshPolicy文件，实现对认证相关功能的定义；通过RbacConfig、ServiceRole和ServiceRoleBinding文件，实现对鉴权相关功能的启用和定义。
让我们举个几个通俗的例子来区分认证和鉴权：
进火车站需要提供身份证和火车票，身份证可以证明你就是你，这是认证；火车票可以证明你有权上那趟火车，这是授权。
又例如，你要访问自己淘宝的购物车，需要先登录，这是认证。你要访问朋友的购物车，就需要他的允许，这是授权。
再例如，有经验的朋友能发现浏览器经常会面对两个错误码：401和403。通常而言，401就是未登录的意思，需要认证；403就是禁止访问的意思，需要授权。
3.1 认证Istio 提供两种类型的身份认证：
l 传输身份认证，也称为服务到服务身份认证：对直连客户端进行验证。Istio 提供双向TLS作为传输身份认证的全栈解决方案。我们可以轻松启用此功能，而无需更改服务代码。这个解决方案：
l 为每个服务提供强大的身份认定，以实现跨群集和跨云的互操作性。
l 保护服务到服务通信和最终用户到服务通信。
l 提供密钥管理系统，以自动执行密钥和证书生成，分发和轮换。
l 来源身份认证，也称为终端用户身份认证：对来自终端用户或设备的原始客户端请求进行验证。Istio 通过 JSON Web Token（JWT）、Auth0、Firebase Auth、Google Auth 和自定义身份认证来简化开发者的工作，使之轻松实现请求级别的身份认证。
在这两种情况下，Istio 都通过自定义 Kubernetes API 将身份认证策略存储在 Istio 配置存储（Istio config store）中。Pilot会在适当的时候进行同步，为每个Proxy更新其最新状态以及密钥。此外，Istio 支持在许可模式下进行身份认证，以帮助我们理解策略变更前后，服务的安全状态是如何变化的。
3.1.1 认证架构我们可以使用身份认证策略，为 Istio 网格中接收请求的服务指定身份认证要求。我们使用 .yaml 文件来配置策略，策略将保存在 Istio 配置存储中。在任何策略变更后，Pilot 会将新策略转换为适当的配置，下发给Envoy，告知其如何执行所需的身份认证机制。Pilot 可以获取公钥并将其附加到 JWT 进行配置验证。或者，Pilot 提供 Istio 系统管理的密钥和证书的路径，并将它们安装到负载 Pod 中，以进行双向 TLS。
本文多次提到双向TLS认证，让我们理解一下其在Istio里的实现。Istio 通过客户端和服务端各自配备的Envoy进行通信，也就是说，客户端和服务端的流量，是被各自的Envoy接管了的。对于客户端调用服务端，遵循的步骤是：
Istio 将出站流量从客户端重新路由到客户端的本地 Envoy。
客户端 Envoy 与服务端 Envoy 开始双向 TLS 握手。在握手期间，客户端 Envoy 还执行安全命名检查，以验证服务证书中提供的服务帐户是否有权运行目标服务。
客户端 Envoy 和服务端 Envoy 建立了一个双向的 TLS 连接，Istio 将流量从客户端 Envoy 转发到服务端 Envoy。
授权后，服务端 Envoy 通过本地 TCP 连接将流量转发到服务端的服务。
3.1.2 认证策略配置