保障Kubernetes软件供应链的安全
发布时间：2022-04-15 15:30:33 所属栏目：云计算 来源：互联网
导读：现代软件开发实践使得软件供应链的安全比以往任何时候都更加重要。我们的代码依赖于开源库，而开源库依赖于其他库(一系列我们没有开发、没有编译、几乎不知道或根本不知道它来自何处的代码)。 其中一些代码几乎无处不在。在整个行业造成严重破坏的Log4Shell
|
现代软件开发实践使得软件供应链的安全比以往任何时候都更加重要。我们的代码依赖于开源库，而开源库依赖于其他库(一系列我们没有开发、没有编译、几乎不知道或根本不知道它来自何处的代码)。 其中一些代码几乎无处不在。在整个行业造成严重破坏的Log4Shell漏洞是由常见Java日志记录组件log4j中的一个旧bug引起的。我们正在建设一个不是站在巨人的肩膀上的行业，而是站在少数应用程序和组件维护者的肩膀上的行业，这些应用程序和组件维护者让我们的全球基础设施在业余时间工作，并出于他们内心的善良。 我们可以采取哪些步骤来确保软件供应链的安全?在提供管理软件材料清单的工具方面已经做了大量的工作：扫描库的代码，使用静态和动态分析，向代码中添加数字签名和散列，并将其全部纳入托管存储库。但有一个方面还不清楚：我们如何验证这项工作以及我们正在使用的代码?毕竟，古老的安全格言之一仍然是“信任但要验证”。 当我们使用像Kubernetes这样的技术时，事情会变得更加复杂，Kubernetes的设计是基于微服务架构和容器的混合匹配理念。虽然我们的代码可以在独立的容器中运行，但它在嵌套的抽象用户区中运行，每个dockerfile收集一系列依赖项，其中许多依赖项没有完整的文档记录。我们如何才能相信我们使用的容器中的物料清单? 推荐白皮书： 介绍：一个工件验证工作流微软的云本机开源团队一直在研究一个新的规范，该规范将有助于解决这一问题。Approval是一个验证框架，它支持Kubernetes应用程序中的各种工件。它使用一组受信任的安全元数据和已签名的物料清单来确保您部署的所有内容都是您希望部署的内容。 图像和其他组件利用公证人V2签名和验证工具以及ORAS(OCI注册表作为存储)工件规范。ORAS是OpenContainerInitiative注册表定义的一部分，它扩展到存储任何东西，而不仅仅是容器。它作为一种整理软件材料清单的方式工作得很好。有趣的是，Bindle分布式应用程序安装程序定义和ORAS清单之间存在共性，这使得从SBOM到经过验证的分布式应用程序安装程序变得简单。两者一起提供了一个供应链图，该图可以被解析并用作Kubernetes集群内验证方案的一部分。 将这些概念捆绑在一起，添加一个工作流引擎，将策略应用于软件物料清单，验证代码及其依赖关系中的许多不同供应链。它的核心是一个协调器，负责跨容器映像管理策略工作流。它是可扩展的，因此它可以跨公共和私有注册中心工作，使用与Kubernetes中使用的插件模型类似的熟悉插件模型。 构建您的第一个策略 Approval团队在他们的GitHub存储库中有一些演示代码，展示了如何在Kubernetes中将Approval与Gatekeeper一起使用。使用Helm图表进行安装，并附带一些示例配置模板。您可以使用这些来测试这些操作，例如，阻止所有没有签名的图像。Gatekeeper将拒绝任何未签名的容器映像，阻止它们运行。 策略文件是用YAML编写的，因此您可以在Visual Studio代码或其他工具中编辑它们，并利用代码格式化工具。它们构建成一个简单的规则引擎，通过验证逐步生成工件。它们是否来自核准登记处?您是否多次检查一个工件以获得不同的签名?您自己的私有注册表中的工件是否比公共注册表中的工件更可信?当您运行多个检查时，您的所有验证引擎都同意吗?事实证明，运行时验证的规则很容易定义，但对于运行在CI/CD系统中的运行时验证来说，这种情况不太可能发生，因为在CI/CD系统中，您需要确定许多不同工件的状态以及来自许多不同信任根的签名。 Approval目前是一个有趣的初始建议，它提供了一套工具，可以管理软件BOM表中的所有元素。虽然它不能防止零天影响长时间隐藏的bug，但它可以快速确定哪些代码受到影响，创建规则以防止其被使用和运行。 随着供应链风险成为人们关注的焦点，行业必须仔细研究这样的提案，并在公共场所开展工作。很高兴看到微软已经承诺与云计算计算基金会共享批准，在那里它应该得到它需要的更广泛的Kubernetes开发社区的审查。 （编辑：江门站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐