Istio的安全性

Istio安全性涉及的组件

• 用于密钥和证书管理的证书颁发机构（CA）
• 配置 API 服务器分发给代理（认证策略、授权策略、安全命名信息）

• Sidecar 和边缘代理作为 Policy Enforcement Points(PEPs) 以保护客户端和服务器之间的通信安全.

• 一组 Envoy 代理扩展，用于管理遥测和审计

控制面处理来自 API server 的配置，并且在数据面中配置 PEPS。PEPS 用 Envoy 实现。下图显示了架构。

Istio身份

身份是任何安全基础架构的基本概念。在工作负载间通信开始时，双方必须交换包含身份信息的凭证以进行双向验证。

Istio 身份模型使用 service identity （服务身份）来确定一个请求源端的身份。

下面的列表展示了在不同平台上可以使用的服务身份：

• Kubernetes: Kubernetes service account
• GKE/GCE: GCP service account
• 本地（非 Kubernetes）：用户帐户、自定义服务帐户、服务名称、Istio 服务帐户或 GCP 服务帐户。自定义服务帐户引用现有服务帐户，就像客户的身份目录管理的身份一样

Istio提供身份认证的流程：（身份认证是通过SDS提供secret discovery service）

1. Istiod 提供 gRPC服务以接受证书签名请求（CSRS）。
2. 当工作负载启动时，Envoy 通过秘密发现服务（SDS）API 向同容器内的 istio-agent 发送证书和密钥请求。
3. 在收到 SDS 请求后，istio-agent 创建私钥和 CSR，然后将 CSR 及其凭据发送到 istiod CA 进行签名。
4. istiod CA 验证 CSR 中携带的凭据，成功验证后签署 CSR 以生成证书。
5. Istio-agent 通过 Envoy SDS API 将私钥和从 Istio CA 收到的证书发送给 Envoy。
6. Istio-agent 会监工作负载证书的有效期。上述 CSR 过程会周期性地重复，以处理证书和密钥轮换。

Istio中的认证策略（PeerAuthentication|RequestAuthentication）

两种认证类型：

Peer authentication：用于服务到服务的认证，以验证进行连接的客户端。提供双向TLS认证。默认是用宽容模式（PERMISSIVE ）

Peer认证支持模式：

• PERMISSIVE：工作负载接受双向 TLS 和纯文本流量。此模式在迁移因为没有 sidecar 而无法使用双向 TLS 的工作负载的过程中非常有用。一旦工作负载完成 sidecar 注入的迁移，应将模式切换为 STRICT。
• STRICT： 工作负载仅接收双向 TLS 流量。
• DISABLE：禁用双向 TLS。 从安全角度来看，除非您提供自己的安全解决方案，否则请勿使用此模式。

Request authentication：用于最终用户认证，以验证附加到请求的凭据。 Istio 使用 JSON Web Token（JWT）验证启用请求级认证，并使用自定义认证实现或任何 OpenID Connect 的认证实现。

Request 认证策略指定验证 JSON Web Token（JWT）所需的值。 这些值包括：

• token 在请求中的位置
• 请求的 issuer
• 公共 JSON Web Key Set（JWKS）

双向TLS认证

Istio 通过客户端和服务器端 PEPS 建立服务到服务的通信通道，PEPS 被实现为Envoy 代理。当一个工作负载使用双向 TLS 认证向另一个工作负载发送请求时，该请求的处理方式如下：

1. Istio 将出站流量从客户端重新路由到客户端的本地 sidecar Envoy。
2. 客户端 Envoy 与服务器端 Envoy 开始双向 TLS 握手。在握手期间，客户端 Envoy 还做了安全命名检查，以验证服务器证书中显示的服务帐户是否被授权运行目标服务。
3. 客户端 Envoy 和服务器端 Envoy 建立了一个双向的 TLS 连接，Istio 将流量从客户端 Envoy 转发到服务器端 Envoy。
4. 授权后，服务器端 Envoy 通过本地 TCP 连接将流量转发到服务器服务。

双向TLS具有一个宽容模式（permissive mode），允许服务同时接受纯文本流量和双向 TLS 流量。

服务里面插入了istio的 sidecar之后，默认情况，会将双向TLS作用于这些服务的工作负载上。

双向TLS认证开启方式：

1. 全局开启，认证策略设置为 STRICT 模式。在整个服务网格范围内，对等认证策略不应该有一个 selector，它必须应用于根命名空间。（根命名空间为安装istiod的命名空间）

2. 单个命名空间或者匹配单个工作负载开启；

3. 为单个服务的每个端口设置双向TLS。（可以排除某个端口，其余端口使用双向TLS（使用   portlevelMtls 参数））

参考：Istio / 认证策略

TLS设置：

• PeerAuthentication 用于配置 Sidecar 接收的 mTLS 流量类型。
• DestinationRule 用于配置 Sidecar 发送的 TLS 流量类型。
• 端口名，或者自动选择协议，决定 sidecar 解析流量的协议。

策略优先级：

特定服务策略比命名空间范围的策略优先级高。

授权（AuthorizationPolicy）

授权策略支持 ALLOW 和 DENY 动作。

拒绝策略优先于允许策略。如果请求同时匹配上允许策略和拒绝策略，请求将被拒绝。Istio 首先评估拒绝策略，以确保允许策略不能绕过拒绝策略。

授权可以作用于：HTTP流量授权、TCP流量、