Bank of GKE Enterprise 安全应用示例是一个基于容器的 Web 应用，可让您模拟网上银行。该示例为您提供了一个参考云技术堆栈，其中包含安全基础、支持 Bank of GKE Enterprise 以及 Bank of GKE Enterprise 应用代码所需的 Google Cloud 服务。
使用资源部署中所述的流水线（基础流水线、基础架构流水线和应用流水线）以及 Config Management 部署 Bank of GKE Enterprise 安全应用示例。
示例架构基于强化集群的安全性指南、GKE 更安全的集群代码库、GKE Enterprise 多云端研讨会代码库、GKE Enterprise 安全蓝图和 Bank of GKE Enterprise 应用中定义的设计模式。如需查看 Bank of GKE Enterprise 安全应用示例的完整代码，请访问 terraform-example-foundation-app GitHub 代码库。
Bank of GKE Enterprise 安全应用平台架构
下图展示了如何在安全基础上构建 Bank of GKE Enterprise 安全应用示例以进行部署。在本示例中，Bank of GKE Enterprise 部署在三个基础环境中：development、production 和 non-production。该应用使用中心辐射型中详述的中心辐射型 VPC 网络拓扑进行联网。该应用使用 Google Cloud 项目作为逻辑安全边界。
Bank of GKE Enterprise 应用向已为该基础定义的项目添加多个项目。其他项目用于部署支持 Bank of GKE Enterprise 所必需的资源、配置和应用，如下表所示。
| 文件夹 | 项目 | 说明 |
|---|---|---|
common
|
infra-cicd
|
包含基础架构流水线中描述的基础架构流水线。此项目还包含用于 GKE 集群配置的 Config Management 政策代码库。 |
app-cicd
|
包含基础架构流水线中描述的应用流水线。 | |
development, non-production,production
|
boa-gke
|
包含 Bank of GKE 集群和多集群 Ingress GKE 集群。也用作 GKE Enterprise 的 Environ 宿主项目。 |
boa-sql
|
包含 Bank of GKE Enterprise 应用使用的 Cloud SQL for PostgreSQL 数据库。 | |
secret
|
包含特定于 Bank of GKE Enterprise 应用的 Secret Manager 和 Secret KMS 实例。 | |
monitoring
|
用于存储环境日志以及监控 Bank of GKE Enterprise 应用的环境实例。 |
如下图所示，在每个环境中总共创建了三个 Google Kubernetes Engine (GKE) 集群来部署 Bank of GKE Enterprise。两个集群（gke-boa-region1-01 和 gke-boa-region2）在两个不同的区域中充当相同的 GKE 专用集群，以提供多区域弹性。第三个集群 (gke-mci-region1-01) 充当多集群 Ingress 的配置集群。
Bank of GKE Enterprise 应用组件
通过 Bank of GKE Enterprise 应用示例，用户可以创建登录账号、登录其账号、查看交易记录、进行存款以及将资金转移到其他用户的账号。该应用由下表中所述的六项服务组成。这些服务作为容器运行，通过 REST API 和 gRPC API 相互连接。
| 服务 | 语言 | 说明 |
|---|---|---|
frontend |
Python | 公开 HTTP 服务器以为网站提供服务。包含登录页面、注册页面和首页。 |
ledger-writer |
Java | 接受并验证传入的交易，然后再将其写入账目。 |
balance-reader |
Java | 提供从 ledger-db 读取的用户余额的高效可读缓存。 |
transaction-history |
Java | 提供从 ledger-db 读取的历史交易的高效可读缓存。 |
user-service |
Python | 管理用户账号和身份验证。该服务会签署 JWT 以用于其他服务进行身份验证。 |
contacts |
Python | 存储与用户关联的其他账号列表。这些账号列在应用的发送付款和存款表单中。 |
该应用在 Google 的代管式混合多云应用平台 GKE Enterprise 上运行。此平台可让您构建并交付应用，以及管理应用的生命周期。下表详细介绍了 Bank of GKE Enterprise 应用部署中使用的 GKE Enterprise 组件。
| Anthos 组件 | 使用 |
|---|---|
| GKE 集群 | 容器管理 |
| GKE Enterprise 配置管理 | 政策管理和执行 |
| Anthos Service Mesh | 服务管理 |
| Cloud Operations | 可观测性和平台管理 |
| Binary Authorization | 容器映像证明 |
| 多集群 Ingress | GKE 集群的多集群 Ingress 控制器 |
分布式服务和 Anthos Service Mesh
在 Bank of GKE Enterprise 应用中，Anthos Service Mesh 通过为工作负载之间的所有通信提供加密、双向身份验证和授权来增强安全性。对于此部署，Anthos Service Mesh 使用自己的代管式专用证书授权机构 (Mesh CA) 颁发 TLS 证书以验证类似应用身份，并帮助确保只有授权的客户端才能访问服务。使用双向 TLS (mTLS) 进行身份验证也有助于确保所有 TCP 通信在传输过程中都经过加密。对于进入网格的服务入站流量，Bank of GKE Enterprise 使用 Istio 入站流量网关 (istio-ingressgateway)。
Bank of GKE Enterprise 应用作为分布式服务运行，这意味着它将作为 Kubernetes Service 在两个或更多 Kubernetes 集群上运行。Kubernetes Service 在每个集群上的同一命名空间中运行，并充当单项逻辑服务。即使一个或多个 GKE 集群已关停，只要运行状况良好的集群能够传送负载，分布式服务仍会继续运行。为了跨集群创建分布式服务，Anthos Service Mesh 在每个集群上运行的服务之间提供 L4/L7 连接，并允许它们充当单项逻辑服务。
Bank of GKE 集群保护
受保护的应用使用专用 GKE 集群来改善安全状况：集群节点和控制层面都没有公共端点。受保护应用中的集群受 VPC 防火墙规则和分层防火墙政策的保护。在受保护应用的部署中，每个环境使用一个 Cloud NAT 实例为 Pod 提供一种访问具有公共 IP 的资源的机制。GKE Sandbox 为集群提供进一步保护，帮助保护节点的主机内核。此外，集群使用安全强化型 GKE 节点来限制攻击者模拟节点的能力，并且节点会运行 Container-Optimized OS 来限制其攻击面。
Bank of GKE Enterprise 应用的 Web 前端使用多集群 Ingress 向互联网公开。多集群 Ingress 使用 Cloud Load Balancing 为 Bank of GKE Enterprise 应用创建负载均衡器，还创建和管理网络端点组 (NEG)。
负载均衡器在两个集群中都有 istio-ingressgateway 服务作为后端，NEG 会动态跟踪两个 istio-ingressgateway 服务的服务端点，以确保负载均衡器具有运行状况良好的后端。Cloud Load Balancing 使用 Google 的网络基础架构为 Bank of GKE Enterprise 前端提供一个任播 IP 地址，以便实现对 Bank of GKE Enterprise 应用的低延迟访问并帮助保护应用前端免受 DDoS 攻击。使用 Google Cloud Armor 后，Bank of GKE Enterprise 应用的网页界面可进一步抵御攻击。
Cloud Domains 用于注册运行受保护应用示例所在的公共网域 (boaongcp.cloud)。Cloud DNS 用于提供低延迟和高可用性 DNS 区域服务。
Bank of GKE Enterprise 命名空间
Bank of GKE Enterprise 应用使用的 GKE 集群分隔到四个命名空间中以分隔服务。命名空间之间的流量通过网络政策进行限制。命名空间如下所示：
istio-system，其中包含入站流量网关。frontend，其中包含 Bank of GKE Enterprise 前端服务。accounts，其中包含 Bank of GKE Enterprise 用户服务。transactions，其中包含 Bank of GKE Enterprise 交易服务。
参与服务网格的所有命名空间都将注入 istio.io/rev=REVISION
标签。此标签允许资源控制器自动将辅助信息文件 Envoy 代理注入已加标签的命名空间中的每个 Pod。
Bank of GKE Enterprise 身份和访问权限控制
构成 Bank of GKE Enterprise 应用的服务在使用 Workload Identity 的 Pod 中运行，Workload Identity 功能为每个 Pod 提供仅具有服务于运行所需的最小权限的唯一身份。Workload Identity 通过在 Kubernetes 服务账号和 Google 服务账号之间创建安全映射，使 Kubernetes 服务账号充当 Google 服务账号。以 Kubernetes 服务账号身份运行的 Pod 在访问 Google Cloud API 时会自动以 Google 服务账号身份进行身份验证，因为 Workload Identity 允许 Identity and Access Management (IAM) 信任 Kubernetes 服务账号凭据。
对每个 GKE 控制层面的访问权限通过堡垒主机（每个环境中有一个主机）启用。每个堡垒主机都受 Identity-Aware Proxy 保护。对 GKE 集群的访问权限由基于 Google GKE 群组的 Kubernetes 基于角色的访问权限控制 (RBAC) 控制。借助群组，您可以使用由身份管理员控制的中央身份管理系统来控制身份。管理员可以修改群组成员资格，而不是在需要更改权限时更新 RBAC 配置。
Bank of GKE Enterprise 数据库结构
Bank of GKE Enterprise 应用使用两个 PostgreSQL 数据库。一个数据库 (ledger-db) 用于交易，另一个数据库 (accounts-db) 用于用户账号。数据库是使用 Google 的代管式数据库服务 Cloud SQL for PostgreSQL 部署的。这些数据库配置了用于灾难恢复的跨区域副本，并使用客户管理的加密密钥进行加密。使用 Cloud SQL 代理可通过服务账号身份验证将 Bank of GKE Enterprise 微服务连接到 Cloud SQL for PostgreSQL。
Bank of GKE Enterprise 安全应用的部署角色
Bank of GKE Enterprise 安全应用的完整应用堆栈（从基础到软件应用）通过一系列自动化系统进行部署，如资源部署中所述。 这些系统旨在由不同的群组运行，如关于 exmaple.com 的访问模式的图表中的模型所示。下表列出了群组、其角色、使用的部署机制及其负责部署的资源。
| 操作人员团队 | 角色 | 部署系统 | 部署的资源 |
|---|---|---|---|
| 平台团队 | 负责集中创建和管理与安全基础相关的资源。 | 基础流水线 | 通过基础流水线部署的组件 |
| 基础架构服务团队 | 负责部署代管式服务并配置部署应用的应用平台。 | 基础架构流水线、Config Management | |
| 应用团队 | 负责开发应用代码。 | 应用流水线 | Bank of Anthos 软件组件 |
通过使用自动流水线部署受保护的应用堆栈，您可以在部署过程中构建安全性、可审核性、可跟踪性、可重复性、可控性和合规性。使用具有不同权限的不同系统并将不同人员安排到不同操作组可以分离职责。这样就可以遵循最小权限原则。
配置管理
受保护的应用使用 Config Management 管理 GKE 工作负载政策和资源。Config Management 使用 Git 代码库，该代码库作为配置中存储的已声明政策的唯一可靠来源。使用存储配置的 Git 存储库中的分支策略将配置应用于环境（development、production 和 non-production）。
Config Management 使用声明式方法来管理政策和资源。它会持续检查集群状态并应用配置中声明的状态，以强制执行政策。
Config Management 与 Policy Controller 搭配使用。Policy Controller 是 Kubernetes 动态准入控制器，这种控制器会根据与安全、法规和业务规则相关的政策检查、审核和实施集群的合规性。Policy Controller 使用称为限制条件的政策来实施集群的合规性。Policy Controller 是从 Gatekeeper 开源项目构建的。
日志记录和监控
与 GKE 集成的日志记录和监控功能为 Bank of GKE Enterprise 应用提供 Cloud Logging 和 Cloud Monitoring 服务。Cloud Monitoring 为 GKE 提供预定义的监控信息中心。借助 Cloud Logging，您可以将系统日志和应用日志收集到中心化日志存储桶中。
受保护应用的每个环境文件夹中都有一个项目，用于存储日志和监控工作区。安全基础具有单独的日志记录项目，可导出整个 Google Cloud 组织中的汇总 Cloud Audit Logs 日志。本部分介绍的日志记录机制特定于受保护的应用。
Security Command Center 可让您深入了解受保护应用的整体安全状况。Security Command Center 向受保护的应用提供 Container Threat Detection。此服务会持续监控容器映像的状态，评估所有更改和远程访问尝试，以便近乎实时地检测运行时攻击。Security Command Center 中介绍了 Security Command Center 和 Container Threat Detection 的配置。
安全应用使用 Web Security Scanner 检测 Bank of GKE Enterprise 应用中的漏洞。它通过抓取应用（按照从基准网址 (boaongcp.cloud) 开始的所有链接）来执行此操作。然后，它会尝试执行尽可能多的用户输入和事件处理脚本。
将 BeyondProd 安全原则映射到受保护的应用
15 年前，当 Google 推出容器和容器编排技术时，便开创了基于容器的架构，以提高资源利用率、构建可用性高的应用并简化 Google 开发者的工作。这种基于容器的架构需要不同的安全模式。此安全模式称为 BeyondProd 且包含几个关键安全原则（与 Bank of GKE Enterprise 应用架构对应），如下表所示。
| 安全性原则 | 映射到安全应用架构 |
|---|---|
| 在边缘保护网络 | Cloud Load Balancing |
| Google Cloud Armor | |
| 使用专用 GKE 集群的 VPC | |
| 防火墙政策 | |
| 服务之间没有固有的相互信任 | Anthos Service Mesh |
| Workload Identity | |
| 网络政策 | |
| 运行具有已知出处的代码的受信任机器 | Binary Authorization |
| 安全强化型 GKE 节点 | |
| 用于跨服务强制执行一致政策的关卡 | 配置管理 |
| Policy Controller | |
| 简单、自动化、标准化的更改发布 | 基础流水线 |
| 基础架构流水线 | |
| 应用流水线 | |
| 配置管理 | |
| 在共享操作系统的工作负载之间进行隔离 | GKE Sandbox |
| Container-Optimized OS |
用于部署 Bank of GKE Enterprise 架构组件的流水线
正如创建和部署安全应用开始时所述，Bank of GKE Enterprise 应用结合使用基础流水线、基础架构流水线、手动流程和 Config Management 进行部署。下表显示使用哪些方法部署哪些组件。
下表介绍通过基础流水线部署的组件。
| 架构组件 | 用途 |
|---|---|
| 项目 | 为 Google Cloud 资源和服务提供逻辑边界。 该边界用于细分 GKE Enterprise 部署。 |
| Virtual Private Cloud 网络 | 通过定义 Bank of GKE 集群的 IP 地址范围的区域子网向 Compute Engine 和 GKE 资源提供网络服务。 |
| VPC 防火墙规则 | 定义允许和拒绝规则，这些规则应用于网络流量以控制对 Bank of GKE 集群的访问。 |
| IAM 角色 | 定义 Bank of GKE Enterprise 在项目中使用的权限。 |
| Cloud API | 启用 API 以支持 Bank of GKE Enterprise 部署。 |
| Cloud DNS | 将 Bank of GKE Enterprise 域名发布到全局 DNS。 |
下表介绍通过基础架构流水线部署的组件。
| 架构组件 | 用途 |
|---|---|
| GKE | 提供容器化 Bank of GKE Enterprise 应用的微服务。 |
| Cloud SQL for PostgreSQL | 为 Bank of GKE Enterprise 应用提供数据后端托管。 |
| Cloud Key Management | 提供密钥加密密钥，在 Cloud SQL for PostgreSQL、GKE 和 Secret Manager 中用于根据客户管理的加密密钥 (CMEK) 进行加密。 |
| Secret Manager | 为用于基于 JWT 的用户身份验证的 RSA 密钥对提供机密存储。 |
| Compute Engine | 提供堡垒主机用于访问 GKE 控制平面（API 服务器）以引导 Config Management 和 Anthos Service Mesh。 |
| 静态外部 IP 地址 | 提供多集群 Ingress 绑定到负载均衡器的预留 IP 地址。 |
| Google Cloud Armor | 提供 Web 应用防火墙和 DDoS 攻击防护。 |
下表介绍通过堡垒主机手动引导过程部署的组件。
| 架构组件 | 目的 |
|---|---|
| 配置管理 | 为 Bank of GKE Enterprise 应用提供配置管理。Config Management 1.1 版及更高版本包含政策控制器作为其组件之一。 |
| Anthos Service Mesh | 提供服务网格功能，用于保护 Bank of GKE Enterprise 应用的微服务之间的通信（使用 mTLS）。 |
下表介绍通过 Config Management 部署的组件。
| 架构组件 | 用途 | 配置区域 |
|---|---|---|
| VirtualService | 提供用于启用基于名称的路由和 Canary 版发布的配置。 | Istio 自定义资源 |
| DestinationRule | 定义政策、负载均衡、mTLS 和断路器。 | |
| AuthorizationPolicy | 定义对服务网格中工作负载的访问权限控制。 | |
| 服务 | 定义用于访问 Pod 逻辑集的虚拟 IP 地址/DNS 名称。 | Kubernetes 工作负载定义 |
| 部署 | 为 Pod 和副本集提供声明式模板。 | |
| RBAC（角色和绑定） | 定义 Kubernetes 服务账号在集群级层或命名空间级层拥有的授权。 | Kubernetes 身份和授权 |
| Workload Identity | 定义用于访问 Google Cloud 资源的 Google Cloud 服务账号。 | |
| Kubernetes 服务账号 | 定义 Kubernetes Service 使用的身份。 | |
| 命名空间 | 定义物理集群中的逻辑集群。 | |
| 政策控制器 | 定义用于对 Kubernetes 集群实施合规性的限制条件。 | Kubernetes 安全强化 |
Bank of GKE Enterprise 资源 IP 地址范围
Bank of GKE Enterprise 安全应用示例需要在 development、non-production 和 production 环境中分配多个 IP 地址范围。Bank of GKE Enterprise 使用的每个 GKE 集群都需要为节点、Pod、Service 和控制平面分配单独的 IP 地址范围。Cloud SQL 实例和堡垒主机也需要单独的 IP 地址范围。如果您需要设计自己的 IP 地址分配方案，则应确保遵循 GKE 指南和建议。
下表显示了在不同环境中用于部署 Bank of GKE Enterprise 安全应用示例的 spoke VPC 子网和 IP 地址范围：
development环境non-production环境production环境
下表介绍开发环境的 Bank of GKE Enterprise 资源 IP 地址范围：
| 资源/子网 | 主要 IP 范围 | Pod IP 地址范围 | Service IP 地址范围 | GKE 控制平面 IP 范围 |
|---|---|---|---|---|
多集群 Ingress GKE 集群 subnet-usw1-01 |
10.0.64.0/29
|
100.64.64.0/22
|
100.64.68.0/26
|
100.64.70.0/28
|
应用 GKE 集群区域 1
subnet-usw1-02
|
10.0.65.0/29
|
100.64.72.0/22
|
100.64.76.0/26
|
100.64.78.0/28
|
堡垒主机
subnet-usw1-03
|
10.0.66.0/29
|
|||
development 应用 GKE 集群区域 2
subnet-use4-01
|
10.1.64.0/29
|
100.65.64.0/22
|
100.65.68.0/26
|
100.65.70.0/28
|
| Cloud SQL |
10.16.64.0/24
|
下表介绍非生产环境的 Bank of GKE Enterprise 资源 IP 地址范围：
| 资源/子网 | 主要 IP 范围 | Pod IP 地址范围 | Service IP 地址范围 | GKE 控制平面 IP 范围 |
|---|---|---|---|---|
多集群 Ingress GKE 集群 subnet-usw1-01 |
10.0.128.0/29
|
100.64.128.0/22
|
100.64.132.0/26
|
100.64.134.0/28
|
non-production 应用 GKE 集群区域 1
subnet-usw1-02
|
10.0.129.0/29
|
100.64.136.0/22
|
100.64.140.0/26
|
100.64.142.0/28
|
non-production bastion host / subnet-usw1-03
|
10.0.130.0/29
|
|||
non-production 应用 GKE 集群区域 2
subnet-use4-01
|
10.1.128.0/29
|
100.65.128.0/22
|
100.65.132.0/26
|
100.65.134.0/28
|
non-production Cloud SQL |
10.16.128.0/24
|
下表介绍生产环境的 Bank of GKE Enterprise 资源 IP 地址范围：
| 资源/子网 | 主要 IP 范围 | Pod IP 地址范围 | Service IP 地址范围 | GKE 控制平面 IP 范围 |
|---|---|---|---|---|
production Multi Cluster Ingress GKE cluster / subnet-usw1-01
|
10.0.192.0/29
|
100.64.192.0/22
|
100.64.196.0/26
|
100.64.198.0/28
|
production 应用 GKE 集群区域 1
subnet-usw1-02
|
10.0.193.0/29
|
100.64.200.0/22
|
100.64.204.0/26
|
100.64.206.0/28
|
堡垒主机
subnet-usw1-03
|
10.0.194.0/29
|
|||
应用 GKE 集群区域 2
subnet-use4-01
|
10.1.192.0/29
|
100.65.192.0/22
|
100.65.196.0/26
|
100.65.198.0/28
|
| Cloud SQL 实例 |
10.16.192.0/24
|
后续步骤
- 阅读摘要（本系列的下一个文档）。