GKE Enterprise 为构建和递送安全服务提供了一致的平台,其安全功能都内置于各个级别,并且可完美搭配,针对安全问题提供深度防御。本教程将使用 Google Cloud 上的 Anthos Sample Deployment,向您介绍 GKE Enterprise 的一些强大安全功能。Anthos Sample Deployment 会部署一个真正的 GKE Enterprise 实操环境,其中包含一个 GKE 集群、服务网格和具有多个微服务的 Bank of 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 提供了一个执行以下操作的脚本:
安装任何缺失的命令行工具,以交互方式处理部署并验证部署更改:
为
anthos-sample-cluster1
设置 Kubernetes 上下文克隆 Config Sync 用于将配置更改同步到集群的仓库。您提交并推送到上游仓库的更改会被 Config Sync 同步到您的基础设施中。这是将更改应用于基础设施时的推荐最佳做法。
如需设置环境,请执行以下操作:
确保您拥有活跃的 Cloud Shell 会话。在教程项目中,您可以通过在 Google Cloud 控制台中点击激活 Cloud Shell 来启动 Cloud Shell。
创建工作所用的目录:
mkdir tutorial cd tutorial
下载初始化脚本:
curl -sLO https://github.com/GoogleCloudPlatform/anthos-sample-deployment/releases/latest/download/init-anthos-sample-deployment.env
将初始化脚本提供到 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
将目录更改为配置代码库,并将其用作本教程其余部分的工作目录:
cd anthos-sample-deployment-config-repo
在服务网格中强制执行 mTLS
为应对全球扩张,CIO 必须强制对传输中的所有用户数据进行加密,以保护敏感信息,遵守区域数据隐私和加密法律。
您的所有流量目前是安全的吗?
前往已部署 Anthos Sample Deployment 的项目中的 Cloud Service Mesh 页面:
点击服务列表中的 transactionhistory。如 Explore GKE Enterprise 中所示,服务详情页面显示了此服务可用的所有遥测数据。
在 transactionhistory 页面上的导航菜单中,选择关联的服务。您可以在此处查看服务的入站和出站连接。解锁的锁形图标表示此端口上观察到的一些未使用双向 TLS (mTLS) 的流量。
mTLS 是一种安全协议,可确保双向流量在两个服务之间安全且可信任。每个服务仅接受来自经过身份验证的服务的加密流量。如您所见,Cloud Service Mesh 明确指出网格中的流量未加密。在 Cloud Service Mesh 中使用不同的颜色,表示未加密的流量同时具有明文和 mTLS(橙色)或仅具有明文(红色)。
使用 GKE Enterprise,只需几步即可符合标准。您不必在源代码处进行更改,并重新构建和重新部署应用即可解决这种情况,但您可以通过以下方式配置新加密政策:Config Sync 自动从中央 Git 仓库部署新配置。
在此部分中,您需要执行以下操作:
调整 Git 代码库中的政策配置,以强制这些服务通过 mTLS 使用加密通信。
依赖 Config Sync 自动从仓库中选取政策变更并调整 Cloud Service Mesh 政策。
验证集群上进行的政策更改已配置为与代码库同步。
确认 Config Sync 设置
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".
确保您位于
master
分支:git checkout master
输出:
Already on 'master' Your branch is up to date with 'origin/master'.
验证您的上游配置代码库:
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)
确保您仍位于
anthos-sample-deployment-config-repo
目录中,然后运行以下命令来检查您的 git 设置。此辅助函数由初始化脚本提供到您的环境,然后运行git config
命令来检查您的 git 配置的现有user.email
和user.name
值。如果未配置这些值,该函数将根据当前活跃的 Google Cloud 账号在代码库级层设置默认值。init_git
输出(示例):
Configured local git user.email to user@example.com Configured local git user.name to user
您现在可以将原则更改提交到代码库了。当您将这些提交推送到上游仓库(来源)时,Config Sync 可确保这些更改会应用于您已将其配置为进行管理的集群。
更新政策以加密所有服务流量
Cloud Service Mesh 的配置是使用 YAML 文件以声明方式指定的。如要加密所有服务流量,您需要修改指定服务可以接受流量类型的 YAML和指定服务发送到特定目标流量类型的 YAML。
您需要查看的第一个 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 形式的流量。通过将 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
接下来,查看
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
通过使用 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
将更改推送到代码库
您很快就可以推送配置更改;但我们建议您在最终提交更新之前执行一些检查。
运行
nomos vet
以确保您的配置有效:nomos vet
没有输出表示不存在验证错误。
推送更改后,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
现在提交这些更改并将其推送到上游代码库。以下命令使用名为
watchmtls
的辅助函数,其由init
脚本提供给您环境中。此辅助函数会运行nomos status
和您之前尝试的kubectl
命令的组合。它会观察集群的变化,直到您按Ctrl+C
退出。监控显示,直到您看到更改已应用到集群并同步集群为止。git commit -am "enable mtls" git push origin master && watchmtls
所做更改也会反映到 GKE Enterprise 中的 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 与特权容器一起运行。
使用 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
在应用更新的配置之前,请使用
nomos vet
验证该配置是否有效。nomos vet
只要没有任何错误,该命令就会以静默方式返回。
提交并推送更改以应用政策。您可以将
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 进行测试。
在 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
尝试使用
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)
为了避免产生费用,最简单的方法是删除您为本教程创建的项目。
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
删除部署(选项 2)
此方法会删除 Bank of Anthos 应用和集群,但不会删除项目。在 Cloud Shell 上运行以下命令:
切换到托管安装脚本的目录:
cd bank-of-anthos/iac/tf-anthos-gke
删除示例和集群:
terraform destroy
出现提示时,输入项目 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 文档