机密计算利用可信执行环境(TEE)来保护使用中的内存,这有助于确保对静态数据、传输中的数据以及使用中的数据进行加密。 机密容器(CoCo)则将 TEE 与 Kubernetes 部署相结合。在 pod 级别部署 TEE 可以实现工作负载的严格隔离,不仅与集群上的其他工作负载隔离,还与集群管理员隔离。
机密容器的挑战在于如何开始操作。要将 pod 部署到机密容器中,只需更改 pod 清单中的某一行,即可进行部署。但是,要开始操作,您需要成功地一起部署多个组件,理想情况下需要跨多个集群实现协作。红帽最近在红帽 OpenShift 沙盒容器 Operator v1.9 及更高版本中发布了对 Microsoft Azure 上机密容器的支持,并支持通过红帽版 Trustee 进行远程鉴证。
在这篇博客中,我将介绍如何通过有效验证模式实现以下三个目标:
- 借助 OpenShift 沙盒容器 Operator 和 Azure 上的红帽版 Trustee,简化机密容器(CoCo)的入门流程
- 为 CoCo 提供一致的声明式基础,以实现最佳实践部署
- 演示如何使用 CoCo 部署应用
有效验证模式概述
有效验证模式是适用于不同的多云和混合云用例的动态代码架构。每种模式都经过测试,并在成熟后纳入红帽的持续集成(CI)系统中。这可确保我们针对最新版本的 operator、OpenShift 版本以及多个公共云环境进行测试。
每个红帽有效验证模式存储库都以 Kubernetes 资源(Helm 图表、Kustomize 和原始对象)的形式展示一个业务用例,这些资源以声明方式全面描述了从服务到支持基础架构的混合云堆栈。 有效验证模式有助于实现可重复执行的复杂部署,非常适合通过 GitOps 运维实践大规模运维这些部署。
为什么要使用有效验证模式?
部署复杂的业务解决方案涉及多个步骤。如果每一步都随意完成,可能会引发潜在错误或导致效率低下。有效验证模式通过提供预先验证的自动化部署流程解决了这一问题:
- 使用 GitOps 模型以代码形式交付用例
- 充当经过修改以满足特定需求的概念验证(PoC),您还可以将其升级为真正的部署
- 可轻松重复执行,非常适合大规模运维
- 有效验证模式支持协作。任何人都可以提出改进建议、做出贡献或使用这些模式,因为所有 Git 存储库都在上游
- 每个有效验证模式均可进行修改以满足特定需求。如果您想替换某个组件(例如,使用 Ceph 存储而不是 S3 存储),只需在配置中通过注释去掉相应部分,并引入另一个存储库即可
- 模式经过测试。一旦成为有效验证模式,相应用例就会纳入红帽的 CI 系统中,并在模式有效期间持续跨产品版本进行测试
有效验证模式是一种“开箱即用”的解决方案。无论您从模式框架的哪个部分开始着手操作,核心组件和一组可配置组件都可直接使用。在本文中,我使用一种有效验证模式,创建了一种便捷的方式来开始使用机密容器。
如何部署模式
有效验证模式网站提供了大量有关如何使用这些模式的文档。最佳实践要求具备以下内容:
- 模式的 Git 存储库,例如模式的分叉。有效验证模式使用 GitOps,因此您必须控制所使用的存储库
- 安装了 oc、Git 和 Podman 的开发人员笔记本电脑
- 一个空白的 OpenShift 集群,其中模式 operator“管理”该集群
以下是这些要求之间的交互方式:
完成此设置后,有效验证模式将“拥有”集群上的内容,为您提供唯一的操作位置来开始操作。
使用机密容器的有效验证模式
红帽 OpenShift 沙盒容器基于 Kata 容器构建,提供运行机密容器的额外功能。机密容器则是部署在安全的硬件隔离区内的容器,有助于保护数据和代码免受特权用户(如云管理员或集群管理员)的访问。CNCF 机密容器项目是 OpenShift CoCo 解决方案的基础。
机密计算利用基于硬件的专用解决方案,帮助保护正在使用的数据。借助硬件,您可以创建专属于您的隔离环境,在执行工作负载期间保护工作负载数据(使用中的数据)免遭未经授权的访问或更改。
CoCo 利用多种硬件平台和支持技术来实现云原生机密计算。CoCo 的目标是在 pod 级别实现机密计算的标准化,并简化其在 Kubernetes 环境中的使用。这样一来,Kubernetes 用户可以使用熟悉的工作流和工具部署 CoCo 工作负载,而无需深入了解底层机密计算技术。
有关更多信息,请参阅探索 OpenShift 机密容器解决方案。
机密容器架构
红帽机密容器解决方案基于两个关键的 operator:
- 红帽 OpenShift 机密容器:红帽 OpenShift 沙盒容器 Operator 中新增的一项功能,负责部署构建模块,以连接工作负载(pod)以及在硬件提供的 TEE 内运行的机密虚拟机(CVM)。
- 远程鉴证:红帽版 Trustee 负责在红帽 OpenShift 集群中部署和管理密钥代理服务(KBS)。
有关更多信息,请参阅机密容器 Trustee 简介:鉴证服务解决方案概述和用例。
CoCo 通常具有两个环境:受信任区域和不受信任区域。在这些区域中,分别部署了 Trustee 和沙盒容器 operator:
那么,挑战是什么?要了解如何实现这一部署,需要了解您的云或本地基础架构的具体细节。务必要考虑几个重要问题,例如:您位于哪个区域?您的目标芯片组(Intel、AMD、IBM Power、s390)和虚拟机监控程序是什么?
有关部署 CoCo 的更多信息,请参阅红帽 OpenShift 机密容器解决方案的部署注意事项。
机密容器有效验证模式简介
机密容器有效验证模式的目标是让用户轻松上手操作,并了解如何部署机密容器。它使用有效验证模式架构来实现以下事项:
- 部署运行 CoCo 所需的 operator
- 配置包括证书在内的外围设备背景组件(如果需要,可使用 Let's Encrypt。)
- 使用红帽高级集群管理器等工具,将部署 CoCo 到集群的用户从云中抽离出来
- 部署一组示例应用,以演示机密容器的各种功能,包括如何操作 CoCo
目前,该模式部署在 Microsoft Azure 上的单个集群中,其所有组件都源自一个有效验证模式(将来会添加更多部署)。
它是如何运作的?
我们利用有效验证模式 operator 来部署 Argo CD,然后由 Argo CD 部署所需的其他 operator。
问题在于,必须将对等 pod 配置映射(包括 init-data 和 kata-policy)配置为指向 Trustee 密钥代理服务(KBS)。此信息是动态的,需要用户使用 Azure CLI 或访问 Azure 门户进行操作。从安全性和可见性的角度看,init-data 和 kata-policy 也存在隐患,因为它们在被推送到配置映射之前进行了 base64 序列化,这使得用户难以验证其安全态势。
通过使用有效验证模式 operator 注入的元数据,可以解决这些问题,让我们能够在应用中轻松访问集群上的信息。高级集群管理器策略用于收集云控制器管理器所定义的信息,并将这些信息注入沙盒容器 operator 的相应配置映射和机密中。
Hashicorp Vault 在具有有效验证模式机密配置的集群内用作 KMS,允许用户从开发人员工作站环境一致地引导 Vault。我们使用此工具为 Trustee 提供机密,这些机密通过外部机密 operator 进行同步。
结合使用这些功能后,只需一个命令即可进行安装,如下所示:
要求
目前,我们支持的平台仅限 Azure,采用 simple 模式拓扑作为单个 OpenShift 集群。
用户可以引入 Azure 红帽 OpenShift 集群,或在 Azure 上部署自助式 OpenShift 集群。该模式包含有关如何使用 openshift-install 构建集群的文档。集群和 Azure 帐户需要能够访问并使用区域中的 Azure CVM。目前,该模式假定机密容器使用 DCasv5 类虚拟机,但该配置支持自定义。
对于 Azure,唯一需要的额外配置是为工作节点子网部署 NAT 网关。该部署将自动完成。
对于开发人员工作站,需要一台安装了 oc 和 Podman 的 POSIX 工作站(运行 Mac OS 或 Linux)。
分步说明
只需完成三个步骤。
1.创建分叉
首先,在您的企业组织内创建有效验证模式 GitHub 存储库的分叉。请注意,由于 Argo CD 具有最终一致性,直接使用有效验证模式存储库并不安全。
git clone https://github.com/(YOUR ORG}/coco-pattern.git2.生成随机密钥
接下来,生成基线密钥。该模式包含用于生成随机密钥的脚本:
sh scripts/gen-secrets.sh3.安装
使用 oc login 登录集群,然后运行模式安装:
./pattern.sh make install这样就完成了!只需等待系统上线,即可探索已部署的应用。
探索已部署的应用
该模式会在 OpenShift Web 控制台包含 9 个方框的菜单中,部署一个名为 Simple ArgoCD 的 Argo CD 实例。系统中部署了许多应用,需要考虑的两个关键应用是 hello-openshift 和 kbs-access。
hello-openshift 应用会将 Web 应用部署三次:
- 作为标准 pod 部署
- 作为 kata pod 部署,其中代理配置已被有意覆盖,以允许用户执行到 pod
- 作为已启用 CoCo 强化功能的“安全”应用部署
kbs-access 应用是一个简单的演示,使用 init 容器从 Trustee 检索机密信息。KBS 访问允许您通过其 Web API 访问机密,以便您可以查看机密中的更改在系统中的传播情况。这种用于检索机密的 init 容器方法不仅可以提升现有应用的安全性,还十分便捷,因为您无需在开发代码的每个地方都使用 Trustee,即可获取机密。
部署 CoCo 模式时的安全注意事项
机密容器与安全防护息息相关,因此务必要考虑机密容器验证模式的安全态势。使用此模式有两个主要注意事项:
- 如今的模式使用简单的参考值。我们建议您阅读有关 RATS 鉴证流的文章,并根据您的安全防护需求和系统风险状况制定合适的策略。
- 分开部署 Trustee。与第一点相关,Trustee 的鉴证服务基于“在不同的可信安全区域中运行”这一原则构建。理想情况下,该安全区域是一个不同的环境,例如本地或其他云提供商环境。
下图显示了使用机密容器有效验证模式在分隔的环境中部署 Trustee 的架构:
CoCo 模式的未来功能
CoCo 有效验证模式足以帮助您轻松上手。它的核心目标是让您在单个集群和环境中取得一定的成功,以便您顺利开始测试。我们当前的首要任务是通过更多实用示例来扩展此模式,助您继续探索机密容器的应用之旅。
我们希望支持多集群中心辐射式部署,让用户能够使用红帽高级集群管理将 Trustee 部署在中心集群,而辐射集群则用于运行机密工作负载。
我们还打算提供使用 Tustee 进行机密管理的实用示例。目前为止我们的示例都很简单。我们未来的开发重点是允许用户在 TEE 内进行托管存储加密,并对无法感知到 Trustee 的应用进行机密初始化,以及配置 VPN。
此外,我们还希望支持在其他环境中部署 CoCo 和 Trustee,以便将信任扩展到本地资源或多个云服务提供商的资源上。
总结
机密容器有效验证模式提供了一种简单的机制来开始使用 CoCo。这种出色的机制支持您在单个存储库中开始实验,并通过分叉来部署您自己的独立应用,同时使用 Argo CD 充分利用标准化的 app-of-apps(应用的应用)GitOps 方法。如您所见,只需执行 git clone 和make install 即可轻松上手。
关于作者
Dr. Chris Butler is a Chief Architect in the APAC Field CTO Office at Red Hat, the world’s leading provider of open source solutions. Chris, and his peers, engage with clients and partners who are stretching the boundaries of Red Hat's products. Chris is currently focused on the strategy and technology to enable regulated & multi-tenant environments, often for ‘digital sovereignty’. He has been doing this with Governments and Enterprise clients across Asia Pacific.
From a technology perspective Chris is focused on: Compliance as code with OSCAL Compass; Confidential Computing to enforce segregation between tenants and providers; enabling platforms to provide AI accelerators as a service.
Prior to joining Red Hat Chris has worked at AUCloud and IBM Research. At AUCloud Chris led a team who managed AUCloud’s productization strategy and technical architecture. Chris is responsible for the design of AUCloud's IaaS & PaaS platforms across all security classifications.
Chris spent 10 years within IBM in management and technical leadership roles finishing as a Senior Technical Staff Member. Chris is an experienced technical leader, having held positions responsible for: functional strategy within the IBM Research division (Financial Services); developing the IBM Global Technology Outlook; and as development manager of IBM Cloud Services.