教程：保护 GKE Enterprise

---

GKE Enterprise 为构建和递送安全服务提供了一致的平台，其安全功能都内置于各个级别，并且可完美搭配，针对安全问题提供深度防御。本教程将使用 Google Cloud 上的 Anthos Sample Deployment，向您介绍 GKE Enterprise 的一些强大安全功能。Anthos Sample Deployment 会部署一个真正的 GKE Enterprise 实操环境，其中包含一个 GKE 集群、服务网格和具有多个微服务的 Bank of GKE Enterprise 应用。

注意：如果您刚接触 GKE Enterprise 和 Anthos Sample Deployment，请在试用本教程之前，先转到探索 GKE Enterprise 以安装部署并通过我们的示例应用了解 GKE Enterprise 功能和概念。

目标

在本教程中，我们将通过以下任务向您介绍 GKE Enterprise 的一些安全功能：

• 使用 Config Sync 进行端到端加密通信，在服务网格中强制执行双向 TLS (mTLS)。

• 设置安全保护措施，确保不会意外部署具有特权容器的 pod，方法是使用 Policy Controller。

费用

除非您已购买订阅，否则部署 Bank of Anthos 应用会产生 GKE Enterprise on Google Cloud 的随用随付费用，如价格页面中所述。

您还需要负责运行 Bank of Anthos 应用时产生的其他 Google Cloud 费用，例如 Compute Engine 虚拟机和负载均衡器的费用。

我们建议在完成本教程或者浏览部署后清理以避免产生更多费用。

准备工作

本教程是对探索 Anthos 教程的后续教程。在开始学习本教程之前，请按照该页面上的说明设置项目并安装 Anthos Sample Deployment。

设置 Cloud Shell 环境

在本教程中，您将使用 Cloud Shell 命令行和编辑器来更改集群配置。

为了初始化本教程的 Shell 环境，Anthos Sample Deployment 提供了一个执行以下操作的脚本：

• 安装任何缺失的命令行工具，以交互方式处理部署并验证部署更改：

  • kubectl
  • kubectx
  • istioctl
  • nomos

• 为 anthos-sample-cluster1 设置 Kubernetes 上下文

• 克隆 Config Sync 用于将配置更改同步到集群的仓库。您提交并推送到上游仓库的更改会被 Config Sync 同步到您的基础设施中。这是将更改应用于基础设施时的推荐最佳做法。

如需设置环境，请执行以下操作：

1. 确保您拥有活跃的 Cloud Shell 会话。在教程项目中，您可以通过在 Google Cloud 控制台中点击激活 Cloud Shell 来启动 Cloud Shell。

2. 创建工作所用的目录：

   mkdir tutorial
   cd tutorial
   

3. 下载初始化脚本：

   curl -sLO https://github.com/GoogleCloudPlatform/anthos-sample-deployment/releases/latest/download/init-anthos-sample-deployment.env
   

4. 将初始化脚本提供到 Cloud Shell 环境中：

   source init-anthos-sample-deployment.env
   

   输出：

   /google/google-cloud-sdk/bin/gcloud
   /google/google-cloud-sdk/bin/kubectl
   Your active configuration is: [cloudshell-13605]
   export PROJECT as anthos-launch-demo-1
   export KUBECONFIG as ~/.kube/anthos-launch-demo-1.anthos-trial-gcp.config
   Fetching cluster endpoint and auth data.
   kubeconfig entry generated for anthos-sample-cluster1.
   Copying gs://config-management-release/released/latest/linux_amd64/nomos...
   \ [1 files][ 40.9 MiB/ 40.9 MiB]
   Operation completed over 1 objects/40.9 MiB.
   Installed nomos into ~/bin.
   Cloned ACM config repo: ./anthos-sample-deployment-config-repo
   

5. 将目录更改为配置代码库，并将其用作本教程其余部分的工作目录：

   cd anthos-sample-deployment-config-repo
   

在服务网格中强制执行 mTLS

为应对全球扩张，CIO 必须强制对传输中的所有用户数据进行加密，以保护敏感信息，遵守区域数据隐私和加密法律。

您的所有流量目前是安全的吗？

1. 前往已部署 Anthos Sample Deployment 的项目中的 Cloud Service Mesh 页面：

   前往 Cloud Service Mesh 页面

2. 点击服务列表中的 transactionhistory。如 Explore GKE Enterprise 中所示，服务详情页面显示了此服务可用的所有遥测数据。

3. 在 transactionhistory 页面上的transactionhistory菜单中，选择transactionhistory。您可以在此处查看服务的入站和出站连接。解锁的锁形图标表示此端口上观察到的一些未使用双向 TLS (mTLS) 的流量。

mTLS 是一种安全协议，可确保双向流量在两个服务之间安全且可信任。每个服务仅接受来自经过身份验证的服务的加密流量。如您所见，Cloud Service Mesh 明确指出网格中的流量未加密。在 Cloud Service Mesh 中使用不同的颜色，表示未加密的流量同时具有明文和 mTLS（橙色）或仅具有明文（红色）。

使用 GKE Enterprise，只需几步即可符合标准。您不必在源代码处进行更改，并重新构建和重新部署应用即可解决这种情况，但您可以通过以下方式配置新加密政策：Config Sync 自动从中央 Git 仓库部署新配置。

在此部分中，您需要执行以下操作：

1. 调整 Git 代码库中的政策配置，以强制这些服务通过 mTLS 使用加密通信。

2. 依赖 Config Sync 自动从仓库中选取政策变更并调整 Cloud Service Mesh 政策。

3. 验证集群上进行的政策更改已配置为与代码库同步。

确认 Config Sync 设置

1. nomos 命令是一种命令行工具，可让您与 Config Management Operator 进行交互，并从本地机器或 Cloud Shell 执行其他实用的 Config Sync 任务。如需验证集群上是否已正确安装和配置 Config Sync，请运行 nomos status：

   nomos status
   

   输出：

   Connecting to clusters...
   Current   Context                  Sync Status  Last Synced Token   Sync Branch   Resource Status
   -------   -------                  -----------  -----------------   -----------   ---------------
   *         anthos-sample-cluster1   SYNCED       abef0b01            master        Healthy
   

   输出会确认 Config Sync 已配置为将集群同步到配置仓库的主分支。第一列的星号表示当前上下文设置为 anthos-sample-cluster1。如果没有看到此标记，请将当前上下文切换为 anthos-sample-cluster1：

   kubectl config use-context anthos-sample-cluster1
   

   输出：

   Switched to context "anthos-sample-cluster1".
   

2. 确保您位于 master 分支：

   git checkout master
   

   输出：

   Already on 'master'
   Your branch is up to date with 'origin/master'.
   

3. 验证您的上游配置代码库：

   git remote -v
   

   输出：

   origin  https://source.developers.google.com/.../anthos-sample-deployment-config-repo (fetch)
   origin  https://source.developers.google.com/.../anthos-sample-deployment-config-repo (push)
   

4. 确保您仍位于 anthos-sample-deployment-config-repo 目录中，然后运行以下命令来检查您的 git 设置。此辅助函数由初始化脚本提供到您的环境，然后运行 git config 命令来检查您的 git 配置的现有 user.email 和 user.name 值。如果未配置这些值，该函数将根据当前活跃的 Google Cloud 账号在代码库级层设置默认值。

   init_git
   

   输出（示例）：

   Configured local git user.email to [e-mail]
   Configured local git user.name to user
   

您现在可以将原则更改提交到代码库了。当您将这些提交推送到上游仓库（来源）时，Config Sync 可确保这些更改会应用于您已将其配置为进行管理的集群。

更新政策以加密所有服务流量

Cloud Service Mesh 的配置是使用 YAML 文件以声明方式指定的。如要加密所有服务流量，您需要修改指定服务可以接受流量类型的 YAML和指定服务发送到特定目标流量类型的 YAML。

1. 您需要查看的第一个 YAML 文件是 namespaces/istio-system/peer-authentication.yaml，它是一个网格级身份验证政策，用于指定网格中的所有服务默认接受的流量类型。

   cat namespaces/istio-system/peer-authentication.yaml
   

   输出：

   apiVersion: "security.istio.io/v1beta1"
   kind: "PeerAuthentication"
   metadata:
     name: "default"
     namespace: "istio-system"
   spec:
     mtls:
       mode: PERMISSIVE
   

   如您所见，PeerAuthentication mTLS 模式为 PERMISSIVE，表示服务接受明文 HTTP 形式和 mTLS 形式的流量。

2. 通过将 mTLS 模式设置为 STRICT，修改 namespaces/istio-system/peer-authentication.yaml 以仅允许在服务之间进行加密通信：

   cat <<EOF> namespaces/istio-system/peer-authentication.yaml
   apiVersion: "security.istio.io/v1beta1"
   kind: "PeerAuthentication"
   metadata:
     name: "default"
     namespace: "istio-system"
   spec:
     mtls:
       mode: STRICT
   EOF
   

3. 接下来，查看 namespaces/istio-system/destination-rule.yaml 中的目标规则。这会指定将流量发送到指定目标的规则，包括流量是否经过加密。请注意，TLSmode 为 DISABLE 表示流量将以明文形式发送到所有匹配的主机。

   cat namespaces/istio-system/destination-rule.yaml
   

   输出：

   apiVersion: networking.istio.io/v1alpha3
   kind: DestinationRule
   metadata:
     annotations:
       meshsecurityinsights.googleapis.com/generated: "1561996419000000000"
     name: default
     namespace: istio-system
   spec:
     host: '*.local'
     trafficPolicy:
       tls:
         mode: DISABLE
   

4. 通过使用 TLSmode ISTIO_MUTUAL，修改 namespaces/istio-system/destination-rule.yaml 以让 Istio 设置一项流量政策以针对集群中的所有匹配主机启用 TLS。

   cat <<EOF> namespaces/istio-system/destination-rule.yaml
   apiVersion: networking.istio.io/v1alpha3
   kind: DestinationRule
   metadata:
     annotations:
       meshsecurityinsights.googleapis.com/generated: "1561996419000000000"
     name: default
     namespace: istio-system
   spec:
     host: '*.local'
     trafficPolicy:
       tls:
         mode: ISTIO_MUTUAL
   EOF
   

将更改推送到代码库

您很快就可以推送配置更改；但我们建议您在最终提交更新之前执行一些检查。

1. 运行 nomos vet 以确保您的配置有效：

   nomos vet
   

   没有输出表示不存在验证错误。

2. 推送更改后，Config Sync 会选取这些更改并将其应用到您的系统。为了避免意外结果，我们建议检查配置的当前活跃状态自上次修改后是否发生了更改。使用 kubectl 检查 destinationrule 是否反映了已为集群停用 mTLS：

   kubectl get destinationrule default -n istio-system -o yaml
   

   输出：

   apiVersion: networking.istio.io/v1alpha3
   kind: DestinationRule
   ...
   spec:
     host: '*.local'
     trafficPolicy:
       tls:
         mode: DISABLE
   

3. 现在提交这些更改并将其推送到上游代码库。以下命令使用名为 watchmtls 的辅助函数，其由 init 脚本提供给您环境中。此辅助函数会运行 nomos status 和您之前尝试的 kubectl 命令的组合。它会观察集群的变化，直到您按 Ctrl+C 退出。监控显示，直到您看到更改已应用到集群并同步集群为止。

   git commit -am "enable mtls"
   git push origin master && watchmtls
   

   所做更改也会反映到 GKE Enterprise 中的 Cloud Service Mesh 页面上。

   前往 Cloud Service Mesh 页面

   您应该会看到红色 解锁 锁形图标已变化。锁形图标显示为橙色（混合流量）而非绿色（完全加密的流量），因为我们默认在一小时内使用 mTLS 和明文组合进行查看。如果您在一小时后再次检查，您应该会看到一个绿色的锁形图标，表明您已成功加密所有服务流量。

使用 Policy Controller 设置保护措施

您的安全团队担心使用特权容器（具有 root 访问权限的容器）运行 pod 时可能会出现潜在的 root 攻击。虽然当前配置不会部署任何特权容器，但您希望尽可能多地防范对性能甚至是客户数据造成损害的威胁向量。

尽管团队尽职尽责，但您可能会发现，在未来通过持续交付过程进行的配置更新中，您可能会有在无意中遇到 Root 攻击的风险。您决定设置一个安全保护措施以防范这一风险

应用保护措施

保护措施是自动执行的管理控制，旨在实施政策来保护您的环境。Policy Controller 支持定义和执行原生 Kubernetes 对象未涵盖的自定义规则。Policy Controller 会检查、审核并实施与您所在组织的唯一安全、法规遵从和治理等要求相对应的保护措施。

使用 Policy Controller

Policy Controller 构建在开源政策引擎 Gatekeeper 之上，用于在每次创建、更新或删除集群中的资源时实施相应的政策。这些政策是使用政策控制器模板库或其他 Gatekeeper 限制条件模板中的限制条件定义的。

Anthos Sample Deployment on Google Cloud 已安装政策控制器，并且启用了政策控制器模板库。通过利用来自模板库的特权容器的现有限制条件来实施保护措施时，您可以充分利用 Anthos Sample Deployment on Google Cloud。

为特权容器应用政策限制条件

为了解决安全团队的顾虑，您可以应用 K8sPSPPrivilegedContainer 限制条件。该限制条件会拒绝 Pod 与特权容器一起运行。

1. 使用 Cloud Shell 终端，根据库限制条件中的文本创建新的 constraint.yaml 文件，如下所示：

   cat <<EOF> ~/tutorial/anthos-sample-deployment-config-repo/cluster/constraint.yaml
   apiVersion: constraints.gatekeeper.sh/v1beta1
   kind: K8sPSPPrivilegedContainer
   metadata:
     name: psp-privileged-container
   spec:
     match:
       kinds:
         - apiGroups: [""]
           kinds: ["Pod"]
       excludedNamespaces: ["kube-system"]
   EOF
   

2. 在应用更新的配置之前，请使用 nomos vet 验证该配置是否有效。

   nomos vet
   

   只要没有任何错误，该命令就会以静默方式返回。

3. 提交并推送更改以应用政策。您可以将 nomos status 与 watch 命令结合使用，以确认更改已应用到您的集群。完成后按 Ctrl+C 退出 watch 命令。

   git add .
   git commit -m "add policy constraint for privileged containers"
   git push && watch nomos status
   

   输出：

   Connecting to clusters...
   Current   Context                  Sync Status  Last Synced Token   Sync Branch   Resource Status
   -------   -------                  -----------  -----------------   -----------   ---------------
   *         anthos-sample-cluster1   SYNCED       f2898e92            master        Healthy
   

测试您的政策

应用政策后，您可以尝试使用特权容器运行 Pod 进行测试。

1. 在 Cloud Shell 终端中，使用以下命令在教程目录 nginx-privileged.yaml 中创建新文件，其中包含此示例规范中的内容：

   cat <<EOF> ~/tutorial/nginx-privileged.yaml
   apiVersion: v1
   kind: Pod
   metadata:
     name: nginx-privileged-disallowed
     labels:
       app: nginx-privileged
   spec:
     containers:
     - name: nginx
       image: nginx
       securityContext:
         privileged: true
   EOF
   

2. 尝试使用 kubectl apply 启动 Pod。

   kubectl apply -f ~/tutorial/nginx-privileged.yaml
   

   输出：

   Error from server ([denied by psp-privileged-container] Privileged container is not allowed: nginx, securityContext: {"privileged": true}): error when creating "~/nginx-privileged.yaml": admission webhook "validation.gatekeeper.sh" denied the request: [denied by psp-privileged-container] Privileged container is not allowed: nginx, security
   Context: {"privileged": true}
   

   该错误显示监控 Kubernetes 环境的 Gatekeeper 准入控制器已实施新政策。由于 Pod 的规范中存在特权容器，因此 Pod 无法执行。

通过 Policy Controller，可以应用版本控制政策来设置保护措施，这是一个强大的概念，因为它可以对您的集群进行标准化、统一和集中化治理，并通过主动监控部署后环境来实施政策。

您可以在 Gatekeeper 代码库中找到许多其他类型的政策以用作您环境的保护措施。

进一步探索部署

虽然本教程为您介绍了如何使用部分 GKE Enterprise 安全功能，但在我们的部署中，GKE Enterprise 仍有更多值得研究和处理的事宜。在按照下一部分中的清理说明操作之前，您随时可以试学其他教程，也可以继续探索 Google Cloud 上的 Anthos Sample Deployment。

清理

学完 Bank of Anthos 应用后，您可以清理在 Google Cloud 上创建的资源，以免这些资源占用配额，日后产生费用。

• 选项 1. 您可以删除该项目。 但是，如要保留项目，您可以使用选项 2 删除部署。

• 选项 2.如果要保留当前项目，您可以使用 terraform destroy 删除示例应用和集群。

删除项目（选项 1）

为了避免产生费用，最简单的方法是删除您为本教程创建的项目。

注意：删除项目会产生以下影响：

• 项目中的所有内容都会被删除。如果您将现有项目用于本文档中的任务，则删除该项目后，还将删除您已在该项目中完成的任何其他工作。
• 自定义项目 ID 丢失。创建此项目时，您可能创建了要在将来使用的自定义项目 ID。要保留使用该项目 ID 的网址（例如 appspot.com 网址），请删除项目内的所选资源，而不是删除整个项目。

如果您打算探索多个架构、教程或快速入门，则重复使用项目可以帮助您避免超出项目配额限制。

1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

删除部署（选项 2）

此方法会删除 Bank of Anthos 应用和集群，但不会删除项目。在 Cloud Shell 上运行以下命令：

1. 切换到托管安装脚本的目录：

   cd bank-of-anthos/iac/tf-anthos-gke
   

2. 删除示例和集群：

   terraform destroy
   

3. 出现提示时，输入项目 ID。

如果您打算重新部署，请验证是否符合准备工作部分中所述的所有要求。

后续步骤

我们的 GKE Enterprise 文档中还有更多信息可供探索。

试学更多教程

• 如需了解如何借助 Anthos Sample Deployment 管理服务，请参阅使用 GKE Enterprise 管理服务。

• 探索有关 Google Cloud 的参考架构、图表和最佳实践。查看我们的 Cloud Architecture Center。

详细了解 GKE Enterprise

• 在我们的技术概览中详细了解 GKE Enterprise。

• 如需了解如何在实际生产环境中设置 GKE Enterprise，请参阅我们的设置指南。

• 如需了解如何借助 Cloud Service Mesh 发挥更多作用，请参阅 Cloud Service Mesh 文档。

• 如需详细了解 Policy Controller，请参阅 Policy Controller 指南

• 如需详细了解声明式配置和政策管理，请参阅 Config Sync 文档和 Policy Controller 文档