本文档介绍 Connect 内置的安全措施。
有效的混合型多云端平台可以实现对跨环境的服务的集中式管理、观察和访问。无论您使用什么 Kubernetes 提供商的产品，GKE Enterprise 都可以跨这些功能提供统一的全面体验。Connect 是一种轻量级代理，能够以经济实惠的规模跨提供商提供以下优势：
- 多集群管理和集群可见性
- 应用服务部署和生命周期管理
本文档讨论了以下内容：
- Connect 的设计如何将安全放在首位
- Connect Agent 部署的最佳做法
- 如何改善您的 Kubernetes 部署安全状况
Connect 的架构
Connect 使最终用户和 Google Cloud 服务可以访问不在公共互联网上的 Kubernetes API 服务器。Connect Agent 在 Kubernetes 集群中运行（每个集群一个代理 (Agent)），并连接到 Connect 代理服务器 (Proxy)。需要与 Kubernetes 集群交互的 Google Cloud 服务会连接到代理服务器 (Proxy)，后者将请求转发到代理 (Agent)。然后，代理 (Agent) 会将请求转发到 Kubernetes API 服务器，如下图所示。
部署代理 (Agent) 后，它会与 Google Cloud 建立永久性传输层安全协议 (TLS) 1.2+ 连接以等待请求。管理员启用 Google Cloud 服务后，这些服务可以为您的 Kubernetes 集群生成请求。这些请求也可能来自用户与 Google Cloud 控制台、Connect 网关或其他 Google 服务的直接交互。
Google Cloud 服务会将请求发送到代理服务器 (Proxy)。然后，代理服务器 (Proxy) 会将请求转发到负责集群的已部署代理 (Agent)，代理 (Agent) 最后将请求转发到 Kubernetes API 服务器。Kubernetes API 服务器会应用 Kubernetes 身份验证、授权和审核日志记录政策，并返回响应。响应会通过代理 (Agent) 和代理服务器 (Proxy) 传递回 Google Cloud 服务。在流程的每个步骤中，组件都会针对每个连接和每个请求执行身份验证和授权。
Kubernetes API 服务器会对所有请求（包括通过 Connect 的请求）应用相同的身份验证、授权和审核日志记录政策。此流程可以确保您始终控制着对您集群的访问。
Connect 和深度防御
深度防御是 Google Cloud 在其基础架构和安全实践中所实施的基本功能。为了保护宝贵的数据、信息和用户，我们采取了分层的方法来全面保护我们的组织和客户。这与我们设计 Connect 的原则相同。
除了 Google 自己的深度防御策略和设计之外，您还应评估此处提供的内容以及您的安全状况和标准。本部分介绍了可以用来补充 Kubernetes 安全强化最佳做法的其他措施。
组件到组件的安全性
Connect 请求的每个组件都会对其同层级进行身份验证，并且仅与针对数据经过身份验证和授权的同层级共享数据，如下图所示。
Connect 请求的每个组件都会使用以下各项互相进行身份验证：
- 传输层安全协议 (TLS)
- 应用层传输安全 (ALTS)
- OAuth
Connect 请求的每个组件都会使用以下各项互相进行授权：
- 身份和访问权限管理 (IAM)
- 许可名单
Kubernetes 集群和 Google Cloud 之间的每个连接均已加密，并且每个连接的至少一个对等方会使用基于证书的身份验证。此过程有助于确保所有令牌凭据在传输过程中都经过加密，并且只有经过身份验证和授权的对等方才能收到。
Google Cloud 的用户身份验证
使用 Google Cloud 控制台时，用户需要完成标准 Google 登录流程。Google Cloud 会提供用户的浏览器进行身份验证的传输层安全协议 (TLS) 证书，用户会登录到 Google Cloud 或 Google Workspace 账号以便向 Google Cloud 进行身份验证。
通过 Google Cloud 控制台或其他 API 访问项目受 IAM 权限控制。
Google Cloud 服务到服务身份验证
Google Cloud 使用 ALTS 进行内部服务到服务身份验证。ALTS 允许 Google Cloud 服务（例如代理服务器 (Proxy)）创建经过身份验证且受到完整性保护的连接。
Google Cloud 服务必须获得内部授权才能使用代理 (Proxy) 连接到远程连接实例，因为代理 (Proxy) 使用服务身份许可名单来限制访问。
对 Google Cloud 进行身份验证
代理 (Agent) 会使用传输层安全协议 (TLS) 对每个连接进行身份验证和加密。代理 (Agent) 通过使用内置于二进制文件中的一组根证书对 Google Cloud 传输层安全协议 (TLS) 证书进行身份验证，以避免无意中信任添加到代理 (Agent) 容器中的证书。代理 (Agent) 仅针对经过正确身份验证的端点执行 API 调用。此过程有助于确保 Google Cloud 发送服务账号证书和 Kubernetes API 请求，并且确保任何响应仅发送到 Google Cloud。
如需查看代理 (Agent) 在正常运行期间通信的网域列表，请参阅确保网络连接。
您可以将代理 (Agent) 配置为通过 HTTP 代理 (Proxy) 连接到 Google Cloud。在此配置中，代理 (Agent) 会针对 HTTP 代理 (Proxy) 使用 HTTP/1.1
CONNECT，并建立到 Google Cloud 的传输层安全协议 (TLS) 连接。HTTP 代理 (Proxy) 只能看到代理 (Agent) 和 Google Cloud 之间的加密流量。代理 (Agent) 和 Google Cloud 之间的连接的端到端完整性和安全性不会受到影响。
对代理 (Agent) 进行身份验证
代理 (Agent) 通过使用您创建的 Google Cloud 服务账号向 Google Cloud 进行身份验证。集群管理员在部署代理 (Agent) 时，会为此服务账号提供私钥，并负责该私钥的隐私设置。代理 (Agent) 连接到 Google Cloud 时，会使用此服务账号进行身份验证，并要求为其配置的项目接收请求。
Google Cloud 会对服务账号凭据进行身份验证，并检查 Google Cloud 服务账号是否具有项目的 gkehub.endpoints.connect IAM 权限。此权限通常是通过 gkehub.connect 角色授予的。如果没有此权限，则代理 (Agent) 的请求会被拒绝，并且它无法接收来自 Google Cloud 的请求。
Kubernetes API 服务器
代理 (Agent) 会使用 Kubernetes 客户端库创建到 Kubernetes API 服务器的 TLS 连接。Kubernetes 运行时环境会为代理 (Agent) 的容器提供传输层安全协议 (TLS) 证书授权机构 (CA) 证书，代理 (Agent) 会使用该证书对 API 服务器进行身份验证。
API 服务器会对每个请求分别进行身份验证，如下一部分所述。
请求安全性
通过 Connect 从 Google Cloud 发送的每个请求均包含用于标识请求发送者的凭据：生成请求的 Google Cloud 服务以及为其发送请求的最终用户（如果适用）。这些凭据允许 Kubernetes API 服务器为每个请求提供授权和审核控制。
服务到代理 (Agent) 身份验证
发送到代理 (Agent) 的每个请求都包含一个短期令牌，用于标识发送请求的 Google Cloud 服务，如下图所示。
令牌由与 Google Cloud 服务专门关联的 Google Cloud 服务账号签署。代理 (Agent) 会提取服务账号的公钥以验证令牌。此令牌不会转发到 API 服务器。
代理 (Agent) 使用嵌入在二进制文件中的 CA 根来验证 Google Cloud 证书。此过程有助于确保代理 (Agent) 收到来自 Google Cloud 的真实且未经更改的请求。
最终用户身份验证
代表用户访问集群的 Google Cloud 服务要求用户的凭据向 API 服务器进行身份验证，如下图所示。
此政策有助于确保通过 Connect 访问时向用户应用同一组权限。某些 Google Cloud 服务代表用户向 API 服务器进行身份验证。例如，用户可以访问 Google Cloud 控制台以查看已注册舰队的集群中的工作负载。用户在访问这些服务时，会提供 Kubernetes API 服务器可识别的凭据：Kubernetes API 服务器支持的任何令牌。
Google Cloud 控制台将这些凭据存储为用户个人资料的一部分。这些凭据已经过静态加密，只能通过用户的 Google Cloud 或 Google Workspace 凭据访问，并且仅用于通过 Connect 建立的连接。您无法再次下载这些凭据。在以下情况下，系统会删除凭据：用户退出集群、在 Google Cloud 中删除集群注册信息、删除项目或删除用户账号。如需了解详情，请参阅 Google Cloud 上的数据删除。
当用户与 Google Cloud 控制台交互时，系统会为 Kubernetes API 服务器生成请求。服务通过 Connect 发送用户的凭据和请求。然后，代理 (Agent) 会将请求和凭据提交到 Kubernetes API 服务器。
Kubernetes API 服务器会对用户的凭据进行身份验证、对用户的身份执行授权、为操作生成审核事件（如果已进行相关配置），并返回结果。由于用户提供的凭据用于对请求进行身份验证，因此 Kubernetes API 服务器会为 Connect 请求应用与其他请求相同的授权和审核政策。
服务到 Kubernetes 身份验证
在用户的上下文之外访问 Kubernetes API 服务器的 Google Cloud 服务会使用 Kubernetes 模拟向 Kubernetes API 服务器进行身份验证。此方法允许 Kubernetes API 服务器提供按服务进行的授权检查和审核日志记录，如下图所示。
Google Cloud 的服务可以在用户的上下文之外使用 Connect。例如，多集群入站流量服务可以跨集群自动同步入站流量资源。这些服务没有 Kubernetes API 服务器可以对其进行身份验证的凭据：大多数 API 服务器未配置为对 Google Cloud 服务的凭据进行身份验证。但是，API 服务器可以通过模拟向其他服务授予有限的身份验证权限，并且代理 (Agent) 可以对通过 Connect 发送请求的 Google Cloud 服务进行身份验证。同时，这些服务允许通过代理 (Agent) 的请求作为 Google Cloud 服务账号进行身份验证。
当 Google Cloud 服务以自己的身份（而不是在用户的上下文中）发送请求时，代理 (Agent) 会将自己的 Kubernetes 凭据和 Kubernetes 模拟标头（用于标识 Google Cloud 服务）添加到请求中。模拟标头声明了代理 (Agent) 对其进行身份验证的 Google Cloud 服务账号的用户名。
Kubernetes API 服务器会对代理 (Agent) 的凭据进行身份验证，并检查代理 (Agent) 是否可以模拟 Google Cloud 服务账号。模拟功能通常由基于角色的访问权限控制 (RBAC) 规则控制，并且可以限定为特定身份，例如 Google Cloud 服务账号。
如果代理 (Agent) 有权模拟所请求的身份，则 API 服务器会对 Google Cloud 服务账号执行授权检查，并处理请求。请求的审核日志包括代理 (Agent) 的身份和模拟的 Google Cloud 服务账号。
集群中的安全性
代理 (Agent) 最终会将 Kubernetes API 请求发送到 Kubernetes API 服务器，如下图所示。
Kubernetes API 服务器会对这些请求进行身份验证、授权以及记录审核日志，就像对待它所处理的所有其他请求一样。
作为这些请求的代理 (Proxy)，代理 (Agent) 可以访问敏感数据，例如凭据、请求和响应。Kubernetes 和 Kubernetes 生态系统提供了一组工具来阻止其他操作者获取该访问权限，以及帮助确保代理 (Agent) 仅访问预期数据。
Kubernetes 身份验证
Kubernetes API 服务器会对每个传入请求的发送者进行身份验证，以确定在授权阶段应用什么权限。如前面所述，请求包含用户的凭据，或者包含代理 (Agent) 的 Kubernetes 凭据和模拟标头。
集群管理员可以控制 Kubernetes API 服务器识别的身份验证机制。管理员或许可以撤消用户的凭据，也可以撤消或减少代理 (Agent) 凭据的权限。
Kubernetes 授权
Kubernetes API 服务器会检查是否允许经过身份验证的身份对请求的资源执行请求的操作。
集群管理员可以使用任何 Kubernetes 授权机制来配置授权规则。Connect 不会代表集群执行任何授权检查。
代理 (Agent) 安全性
代理 (Agent) 可以访问自己的（Kubernetes 和 Google Cloud）凭据，以及通过它的凭据、请求和响应。因此，代理 (Agent) 在连接的集群中受到信任。
代理 (Agent) 设计有以下安全基础：
- 代理 (Agent) 是用 Go 编写的；Go 提供了垃圾回收内存管理，并且可以阻止许多不安全的内存操作。
- 代理 (Agent) 部署在 distroless 容器映像中。代理 (Agent) 的映像不包含 shell、libc 或与代理 (Agent) 的执行路径无关的其他代码。
- 代理 (Agent) 的映像是由 Google 的共享构建基础架构基于签入的代码构建的。只有此构建系统才能将代理 (Agent) 映像部署到 Container Registry。Google Cloud 开发者无法自行部署新映像。此过程有助于确保对代理 (Agent) 的源代码所做的所有修改都能基于不可否认性追溯到开发者和审核者。
代理 (Agent) 会在您注册集群时部署的 Kubernetes 集群中作为标准部署运行。因此，可用于监控和保护部署、ReplicaSets 和 pod 的所有选项和最佳做法都可用于代理 (Agent)。
这些机制旨在确保攻击者难以危害代理 (Agent) 容器。但是，对代理 (Agent) 节点的特权访问仍然可能危害代理 (Agent) 的环境，因此管理员必须遵循标准的 Kubernetes 安全准则来保护集群基础架构。
借助 VPC Service Controls 实现数据安全
VPC Service Controls 为 Google Cloud 服务提供一层额外的、独立于 Identity and Access Management (IAM) 的安全防御。IAM 实现了精细基于身份的访问权限控制，而 VPC Service Controls 可实现更广泛的基于上下文的边界安全性，包括控制跨边界数据出站流量。例如，您可以指定只有某些项目可以访问您的 BigQuery 数据。您可以参阅 VPC Service Controls 概览，详细了解 VPC Service Controls 如何保护您的数据。
在您确保可以从指定的服务边界内访问使用 Connect 的必要服务后，便可以将 VPC Service Controls 与 Connect 结合使用，以进一步增强数据安全。如需了解详情，请参阅 Connect 前提条件。