Skip to content

Latest commit

 

History

History
146 lines (85 loc) · 15.4 KB

可信容器平台中基于策略的管理.md

File metadata and controls

146 lines (85 loc) · 15.4 KB

可信容器平台中基于策略的管理

通过硬件可信根、工作负载分派和编排以及工作负载加密来创建可信容器平台

标签: IBM Cloud Pak for Multicloud Management,容器,边缘计算

原文链接

Brandon Lum, Harmeet Singh, Haidong Xia, Tim Knoll, Michael Bartock, Yu Cao

发布: 2020-08-11


视频演示!

在本文的后面部分中,我们将演示如何证明计算节点并管理其信任状态以及如何创建加密工作负载

虚拟化和容器化极大地改善了工作负载的效率、适应性和可伸缩性。但是,工作负载可能托管在数据中心或多租户云中共享物理平台池的环境中。工作负载是否在可信平台上运行一直是困扰企业的安全问题,可以根据平台的完整性、其位置和元数据以及其植根于可信根中的能力来判断是否存在这个安全问题。另一个安全问题是工作负载镜像及其密钥是否受到保护,这在处理受监管或敏感的工作负载和数据时尤为重要。

任何数据中心或边缘计算安全策略的基础都应该是保证执行、访问数据和工作负载的平台的安全。物理平台是任何分层安全方法的第一层,它负责提供初始保护,确保可以信任更高层的安全控件。

本文提出了一种强大的创新型技术解决方案,该解决方案采用基于策略的管理,可以自动缓解容器的许多安全问题。

您可以定义策略以实现以下目标:

  • 确保集群中的工作负载仅在可信物理平台上运行。
  • 将不可信平台报告给管理警报仪表板。
  • 在上载之前加密工作负载镜像。
  • 仅解密和启动在具有相应元数据要求(例如位置、资产标签等)的可信平台上运行的镜像。

在本文中,我们将首先讲述了可信容器平台的构建块的详细信息以及所使用的技术,包括 Intel® Security Libraries for Data Center (ISecL-DC)、Red Hat OpenShift、IBM Cloud Pak for MultiCloud Management 和 IBM Encrypted OCI Container Images。然后,我们将介绍该可信容器平台的架构。 最后,我们将演示用于构建可信容器平台的组件的特性,包括支持所列策略的实现方式。

此项目是由 NIST、IBM、Red Hat 和 Intel 合作完成。本文旨在分享可信容器平台的早期开发,并演示一个使用了开源软件组件和现成商用技术的原型。本文是系列文章中的第一篇,我们将分享团队的研究成果。

可信容器平台的元素

支持高可信度的云应该能够保护容器工作负载并更精准地控制容器工作负载的使用。这种云应该能够将工作负载绑定到物理实体,并随后将其绑定到高阶的逻辑实体。为此,我们应使用以下功能或技术:

  • 硬件可信根
  • 工作负载分派和编排
  • 工作负载加密

所有这些功能都是通过开源软件组件和现成商用技术提供的。

硬件可信根

基于硬件的安全技术可以通过建立和维护平台信任来减轻威胁,这样可以保证基础平台配置(包括硬件、固件和软件)的完整性。通过提供这种保证,安全管理员可以在一定程度上洞察和控制允许访问敏感工作负载和数据的位置。建立平台信任的平台安全技术可以提供关于检测到的完整性故障的通知,甚至可以自行纠正故障。

Intel Security Libraries for Data Center (ISecL-DC) 组件由一组构建块组成,这些构建块可以发现、证明和使用硬件安全功能(例如 Intel® Trusted Execution Technology (Intel® TXT)、Intel® Boot Guard 和 Intel® Software Guard Extensions (Intel® SGX)),以帮助实现关键的云安全性和机密计算用例。ISecL-DC 中的构建块提供了一组兼容的 API,可以轻松地与云管理软件以及安全监视和实施工具相集成。ISecL-DC 提供了一个中间件,可以轻松地将平台安全功能与云编排和服务集成在一起。

工作负载分派和编排

在各种用例中,可以使用保留在认证服务中的平台信息和经过验证的固件和配置度量来执行策略。编排调度就是一个例子。云编排程序(例如 Kubernetes 和 OpenStack)能够使用键值属性在数据库中标记服务器节点。证明服务可以将信任属性和信息属性发布到编排程序数据库中,以供在制定工作负载调度决策时使用。另外,编排系统应该可以查看机器的证明状态。

可以使用两个这样的组件来提供此功能:

  • Red Hat OpenShift 是经 CNCF 认证的 Kubernetes 发行版,它提供了具有企业级恢复能力的开放式混合云平台。Red Hat OpenShift 可在任何云上的整个容器堆栈(操作系统、Kubernetes 和集群服务以及应用程序)中提供自动化的安装、升级和生命周期管理。该平台提供了以开发人员和操作人员为中心的工具,能够支持应用程序开发、部署、扩展和长期创新的生命周期维护。Red Hat OpenShift 主要是在容器堆栈的每一层以及整个应用程序生命周期内提供安全性。Red Hat OpenShift 是在 Red Hat Enterprise Linux (RHEL) CoreOS(经过容器优化的操作系统)上运行。IBM Cloud Pak 组件(只能在 OpenShift 集群上运行)将使用 Red Hat OpenShift 内置的安全功能,并可以快速构建云原生业务应用程序。

  • IBM Cloud Pak for Multicloud ManagementRed Hat Advanced Cluster Management for Kubernetes 中的多云管理技术可以增强混合云环境的安全生命周期。对于混合云上托管的工作负载,企业必须满足软件工程、安全工程、恢复能力、安全性和法规遵从性方面的内部标准。提供企业云平台的团队以及在相似的云平台上运行其业务应用程序的应用程序业务部门,可以使用此管理功能来了解各种安全和配置方面并快速实施补救措施,帮助满足此类企业标准。IBM Cloud Pak for Multicloud Management 和 Red Hat Advanced Cluster Management 是两种技术产品,它们提供了可在该原型中互换使用的相似多云管理功能。在我们的系列文章中,我们使用的是 IBM Cloud Pak for Multicloud Management。

工作负载加密

将工作负载放在云中或边缘上的使用通常要被迫接受这些事实:他们的工作负载由服务提供商提供保护,但他们不知道使用的是哪种安全机制。如果用户能够加密其工作负载镜像,则可以实现静态的加密隔离,从而帮助保护使用者数据和知识产权。当运行时节点服务收到启动请求时,它可以检测图像是否已加密,并发出相应的请求来检索解密密钥。该请求可以通过认证服务进行传递,以便可以对平台执行内部信任评估。该密钥请求连同用于证明平台的证据将一起转发给密钥代理。然后,密钥代理可以验证被证明的平台报告,释放该密钥并将其返还给 Cloud Service Provider 和节点运行时服务。此时,节点运行时可以解密镜像并继续进行正常的工作流程编排。磁盘加密内核子系统可以为平台上的工作负载提供静态加密。

加密容器镜像是 IBM 研究院在容器构建工具和运行时中引入的一项功能,例如 skopeobuildahcontainerd 和 OpenShift(通过 cri-o), 它们都支持加密和解密容器镜像。这基于 OCI 容器标准, 可确保容器镜像在离开工作流后立即受到保护,直到容器镜像在能够访问解密密钥的可信计算节点上运行为止。如果注册表遭到破坏,这可确保容器镜像的机密性保持不变,并且可以通过密码将信任与镜像相关联。

可信容器平台架构

我们来看看如何将这些技术结合在一起,形成一个可信容器平台示例。

下面先概述了可信容器平台的架构,然后讲解了如何将技术映射到组件。

  • 可信容器平台组件概览

    • ISecL-DC 服务器(位于架构图左侧)包含密钥代理服务、认证服务以及用于证明硬件可信根和主机度量值的实用程序
    • 该平台包含一个托管集群(位于架构图中间)和一个管理集群(位于架构图右侧)。
    • 托管集群是要用于运行可信工作负载的集群。假设有多个由 IBM Cloud Pak for Multicloud Management 控制的受管集群。
    • 管理集群包含一个用于管理 IBM Cloud Pak for Multicloud Management 和 DevOps 相关工具的控制平面。
    • 在我们的设置中,有两个 Red Hat OpenShift 集群:管理集群和托管集群。在带有 VSAN(涵盖三台裸机服务器)的 VMWare 上启用了管理集群。在基于内核的虚拟机 (KVM) 上启用了托管集群,但此集群通过将工作程序节点放到 KVM 虚拟机访客和裸机服务器上来进行混合安装。
  • 裸机节点的证明

    • 每个裸机节点都有一个可信平台模块 (TPM),并运行一个引导加载程序,直到加载了操作系统堆栈为止,而该堆栈的硬件可信根可以使用 Intel TXT 进行度量。
    • 这些度量值将由节点上的 ISecL-DC 信任代理来收集。
    • 节点信任状态将通过 ISecL-DC 证明服务进行验证,然后由证明中心更新到各个 Red Hat OpenShift 集群中。
  • 密钥管理

    • 密钥代理(位于架构图的 ISecL-DC 服务组内)将管理所有集群的密钥,确保这些密钥只能由经过认证的可信节点进行访问。密钥代理被设计为需要信任证明才能发布密钥。
  • 加密/解密工具

    • Red Hat OpenShift 包含一个管道,该管道使用 skopeo 工具来加密容器镜像。
    • 可以使用 cri-o 工具来解密该镜像,OpenShift 容器运行时会自动将该工具部署到每个工作程序节点上。
    • 加密/解密工具 skopeo 和 cri-o 具有可与 ISecL-DC 服务进行通信的插件,因此可以安全地交换加密/解密密钥。
  • 策略实施

    • 每个受管集群都包含一个 IBM Cloud Pak for Multicloud Management Klusterlet,这可确保每个托管集群都遵守已实施的策略。

    • 这些策略是在 IBM Cloud Pak for Multicloud Management Hub 中创建的,并且将传播到所有要实施这些策略的受管集群中。

    • 我们已实施了 3 个策略:

      • 确保集群中的所有节点都是可信节点
      • 确保用户容器工作负载已加密
      • 确保已建立 DevOps 管道以便使用加密策略来构建应用程序

可信容器平台的流程

现在,我们已经掌握了可形成构建块的技术,我们来看看如何使用以上技术来实施本文开头提出的策略。

确保容器平台中的节点都是可信节点

为了确保运行时环境安全可信赖,我们可以保证集群仅运行可信节点,这些节点植根于硬件可信根(在我们的示例中为 Intel TXT)和可信平台模块 (TPM)。节点平台认证服务提供了知道集群中的哪个节点处于可信或不可信状态的功能,因此集群可以根据需要利用此类信息来调度可信节点上的工作负载,并在节点变得不可信时提供缓解措施。

ISecL-DC 平台证明和集群集成服务包括以下三个组件:

  1. 在每个节点上部署的信任代理
  2. 验证服务
  3. 集成中心

使用硬件(Intel TXT 或 Intel BootGuard)作为度量的核心可信根,以建立每个组件的度量链,信任代理可以响应 TPM 报价的验证服务以报告主机清单。验证服务使用可信度量数据库来验证度量结果,并断言该节点是否为可信节点。集成服务可以检索包括节点资产标签在内的节点信任状态,并将其作为标签推送到编排系统。

此过程有助于确保集群中的计算节点是可信节点并且资产标签(例如地理位置)是已知的,如果由于某种原因而破坏了节点的完整性,那么将关闭该节点并从安全环境中将其移除。因此,集群中所有正在运行的节点必须一直被证明为可信节点。节点的信任状态已定义为策略,可使用 IBM Cloud Pak for Multicloud Management 进行实施。如果检测到某个节点由于无法证明而失去其信任状态,则会在 IBM Cloud Pak for Multicloud Management 中创建一个事件,并从集群中移除该节点。

演示:证明计算节点并管理其信任状态

在下面的视频中,我们演示了如何证明计算节点,并展示了如何通过 IBM Cloud Pak for Multicloud Management 和 Red Hat OpenShift 来管理其信任状态。

确保容器工作负载已加密且安全

可保证容器工作负载安全的流程分为两部分。我们首先需要确保有一个可处理容器工作负载的安全流程。即我们需要确保有一个 DevSecOps 流程,在此流程中可以验证容器工作负载是否安全。我们使用来自 Red Hat OpenShift 的安全管道,这可以作为一个入口来确保正确管理漏洞,还可以作为该流程的附加组件,以便使用 skopeo 和 buildah 加密功能来加密工作负载。在加密过程中,密钥代理(一个 ISecL-DC 组件)负责根据提出的策略来创建节点。在此例中,示例策略可能要求容器工作负载仅在经过证明的可信节点上运行,更具体的说,要求使用特定的资产标签“region:EU”,此标签将绑定到 ISecL-DC 功能中的硬件 TPM。在完成此操作后,加密镜像将托管在容器注册表中。

接下来,要将所有内容联系在一起,需要确保所标记的工作负载仅在安全环境中运行。当 OpenShift 容器运行时从注册表下载容器镜像时,它检测到容器镜像已加密,并与 ISecL-DC 密钥代理联系以获取解密密钥。此时,ISecL-DC 将证明该节点,确保该节点是可信节点并具有在 DevSecOps 管道的策略中配置的必需资产标签。仅当满足以上条件时,才会发布密钥,并且容器镜像将被解密并运行。当工作负载意外或恶意地在不可信节点上运行时,这可以作为额外的保护层。

演示:创建加密工作负载

在下面的视频中,我们演示了如何通过 DevOps 管道来创建加密工作负载,并展示了它只能在可信节点上运行。

结束语及后续步骤

在本文中,我们列出了在创建可信容器平台以支持受监管或敏感工作负载时需要满足的一些要求。我们重点介绍了用于构造此类原型平台的一些技术,并展示了如何结合使用这些技术来提供这类平台。

我们准备建立开源社区,通过集思广益来发展可信容器平台。您可以通过访问我们的 GitHub 来做出贡献。

加入我们

在下一篇文章中,我们将详细介绍该架构以及建立可信容器平台(如本文中所示)所需的步骤。

本文翻译自: Policy-based governance in a trusted container platform(2020-07-16)