当您将工作负载作为VM、容器或在无服务器环境中运行时，该工作负载很容易受到任何具有管理程序、根或内核访问权限的人员或软件的干扰。
Enarx是一个新的开源项目，旨在简化将工作负载部署到公共云中、本地或其他地方的各种可信执行环境（TEE）的过程，并确保您的应用程序工作负载尽可能安全。
当您在云中运行工作负载时，没有任何技术障碍可以阻止云提供商或其员工查看您的工作负载、查看数据，甚至更改运行过程。
这是因为当您将工作负载作为VM、容器或无服务器运行时，实现这些工作负载的方式意味着具有足够访问权限的人员或软件实体可能会干扰该机器上运行的任何进程。
还有其他问题需要考虑。你不仅需要信任公共云提供商及其员工，还需要信任他们系统上运行的所有软件，因为如果它是恶意的或被破坏的，那么其他人或实体可能会查看或干扰你的工作负载。
您必须信任操作系统、固件库、系统管理程序、应用程序堆栈、第三方库、中间件、驱动程序：每个系统上的一切都不需要是恶意的或被破坏的。
当然，公共云提供商通常没有什么动机干扰我们的工作负载——当然，除了执法部门的要求——他们有很多动机正确运行工作负载。
他们努力工作，试图使您的工作负载运行的系统尽可能安全。但他们的重点不是保护您的工作负载不受其影响，而是保护他们的服务器不受您的工作负荷影响，并保护您的负载不受其他租户的工作负荷的影响。
这并不是说他们不采取措施保护你，但考虑到大多数现有威胁，可以理解的是，首要任务是保护你免受恶意工作负载和租户的攻击。
企业和组织需要做出的决定是，他们是否愿意承担在公共云中运行客户详细信息、财务信息、法律程序、工资单信息、医疗数据、防火墙设置、身份验证数据库或无数其他敏感工作负载的业务风险。
还有什么选择？如果你不想信任云服务提供商，那么在自己的场所运行工作负载可能会更安全，但即使这样也绝对不是完美的。
有人在内部运行您的服务器——有操作人员、系统管理员、数据库专家——如果您在您的场所运行服务器，他们中的许多人都有可能访问相同的数据和流程。
你的初级系统管理员能够看到——并可能改变——首席执行官的薪酬和补偿方案，或者泄露收购细节，你对此有多高兴？
信任
那么，问题究竟是什么呢？思考计算机系统的一种经典方式是将其视为一组层，称为堆栈。堆栈由各种硬件、固件和软件层组成，这些层几乎总是由不同的实体提供。
下图给出了云虚拟化体系结构的示例堆栈，其中应用程序（您的工作负载）在各种不同的层上运行。在本例中，颜色代表每层的不同提供者，代表五个不同的实体——数字可能更高。
为了让您（工作负载所有者）确保您的应用程序尽可能安全，您需要确保没有任何层是恶意的或被破坏的，即使这是真的，您仍然需要信任实际运行主机系统的云服务提供商。
下一个图表显示了一个更现代的示例，其中工作负载（“应用程序”）在容器中运行。
很明显，如果你是一个恶意行为者，不仅有更多的层需要保护或利用，而且还有更多的提供者：在这种情况下有七个。
当然，有许多技术可以解决不同层的安全问题，其中最重要的是从值得信赖和信誉良好的组织中获取不同层，但最终，恶意行为者可以利用的攻击面很大。
TEEs to the Rescue?
可信执行环境（TEE）是解决其中一些问题的一种相当新的技术方法。它允许您在一组内存页中运行应用程序，这些内存页由主机CPU加密，即使主机系统的所有者也无法查看或修改TEE实例中正在运行的进程。
最著名的是AMD的安全加密虚拟化（SEV）和英特尔的软件保护扩展（SGX），尽管其他硅供应商也在讨论其架构的替代方案。AMD和英特尔采取的方法非常不同，我们将在下面回到这一点。
如上所述，TEE的使用允许您以这样一种方式设计应用程序，即主机无法查看正在运行您的工作负载的TEE实例。这是对当前状态的改进，如果实施得当，基本上消除了必须信任云服务提供商甚至内部员工的问题，但仍存在一些问题。
然而，在我们解决这些问题之前，前一段中有一个令人担忧的词：短语“当正确实施时”中的“正确”一词。问题是，在TEE中设置和运行工作量远非一个简单的命题。
想象一下，如果有人可以伪造TEE，让你相信你的敏感工作负载正在TEE中运行，而它实际上是在没有TEE保护的标准且受损的主机系统上执行的。
可以说，你的处境比TEE之前更糟，因为至少在那时你知道要小心敏感的工作负载：现在，你有了安全的错觉，并被欺骗暴露了需要保护的应用程序。
当然，硅供应商已经注意到了TEE实例的欺骗问题，因此他们提供了一些机制，通过这些机制，CPU（正在设置TEE实例）可以告诉希望运行工作负载的一方它是真实的，并以加密方式证明它：这被称为证明。
执行完整的证明并检查其正确性不是一个简单的过程，将其设计成应用程序可能会很复杂，但让我们假设您已经实现了这一步骤，并准备好继续操作。
给定一个经过适当验证的TEE，我们现在可以在加密上确信我们正在一个真正的TEE实例中运行我们的应用程序，但这并不能解决我们所有的问题。
至少还有两个问题需要解决。首先，尽管我们现在已经将应用程序与堆栈中的一些层隔离开来，但仍有一些层是我们所依赖的，因此也是我们所信任的。
具体是什么取决于TEE类型和部署模型，现在，除了最简单的应用程序之外，没有任何应用程序具有零依赖性，但例如，如果您正在使用VM运行TEE实例，那么您通常会将整个操作系统作为依赖项在VM中运行：同样，我们有内核、用户空间等——这是需要管理的一大信任！
Enarx是一个旨在解决上述问题的项目：使用TEE实例，但其方式允许您减少信任关系的数量，同时保持更高级别的安全性和易用性。
https://github.com/enarx
Enarx：简化信任关系
Enarx是一个用于在TEE实例中运行应用程序的框架，我们在项目中称之为“Keeps”，无需单独实现证明，无需信任大量依赖项，也无需重写应用程序。它被设计为对用户（您）透明地跨硅架构工作，这样您的应用程序就可以像在英特尔硅上运行一样轻松地在AMD硅上运行，而无需重新编译代码。随着其他TEE类型的出现，我们也计划支持它们。
鉴于这是一个Red Hat项目，它现在是并将继续是开源软件。鉴于这是一个与安全相关的项目，我们的目标是使其尽可能小且易于审核。
Enarx的关键组件包括：
认证组件；
Enarx API和核心；
Enarx运行时环境；
管理组件。
我们将在一篇技术性更强的文章中详细研究这些，但让我们看看Enarx试图实现什么。如果我们考虑上面提到的其中一个堆栈，Enarx的目标是：消除对CPU/固件（由硅供应商，如英特尔或AMD提供）之上任何层的信任，这意味着在执行过程中需要信任的应用程序之下的下一层是中间件层（见下图）。需要明确的是，TEE和任何其他安全能力一样，不能保证是完美的。你可以使用它们来减少你的攻击面和需要信任的层数。
Enarx也有一个位于中间件层的组件——Enarx运行时环境——我们计划将其小型化，以便易于审核。它是开源的，这意味着任何人都可以仔细查看并决定是否信任它。我们的目标是与开源社区合作，鼓励他们进行审计，让那些无法自己进行分析的人对Enarx代码有高度的信任。
其他部分允许以对用户透明的方式对应用程序进行认证、打包和加载。首先，您要求Enarx组件检查您计划部署到的主机是否正在启动真正的TEE实例。一旦确认并验证了TEE，管理组件就会对应用程序的相关部分以及任何所需数据进行加密，并将其发送到主机，以便在Enarx Keep中执行。
我们对Enarx的愿景不仅仅局限于内部部署和公共云，还包括任何启用TEE的系统。我们希望启用电信类型的边缘用例、移动用例、物联网用例等。现在还为时过早，但如果你感兴趣，我们敦促你访问项目网站，了解更多信息，并希望做出贡献。
Enarx旨在简化将工作负载部署到云中、您的场所或其他地方的各种不同TEE的过程，并让您相信您的应用程序工作负载尽可能安全。随着项目的发展，我们将公布更多细节。
https://next.redhat.com/2019/08/16/trust-no-one-run-everywhere-introducing-enarx/