金融业容器云密钥管理技术研究报告 2024

金融业容器云密钥管理技术研究报告I版权声明本报告版权属于北京金融科技产业联盟，并受法律保护。转违反上述声明者，将被追究相关法律责任。编制委员会编委会成员：聂丽琴编写组成员：沈震宇吴猛廖敏飞吴孟晴解敏黄威琪金艳焦靖伟蒋闻天温玉冰编审：黄本涛周豫齐参编单位：北京金融科技产业联盟秘书处中国工商银行股份有限公司中国建设银行股份有限公司平安银行股份有限公司北京信安世纪科技股份有限公司建信金融科技有限责任公司浪潮电子信息产业股份有限公司随着容器云的快速发展，Kubernetes已经成为云原生应用的事实标准，并得到了广泛应用。容器云内遍布大量敏感数据使得数据安全性成为关键关注点。本文针对镜像安全交付和密钥使用等问题，提出了两个创新方案以应对这些挑战。首先，在镜像安全交付方面，通过测试当前已有方案，识别到容器镜像加密过程中的性能瓶颈，提出了对应的优化方案，使得解密性能有着近40%的提升。通过该优化方案，能够显著提升镜像在多接收者条件下的启动速度，提高数据安全性并改善系统性能。其次，在强化密钥使用安全性上，设计了新的密钥分发方尝试通过信任链延伸、复用内部安全机制等方式，解决密钥存储的安全性问题，对此开发了SecretClientPlugin测试程序，并以常见的接口访问密钥为示例进行测试。该方案有着密钥不落本报告深入探讨了金融行业容器云中广泛存在的密钥管理问题，提出了创新的镜像安全交付和密钥分发方案，旨在提升重要数据的安全性，以解决镜像和密钥的分发安全问题。一方面，对现有加密镜像处理性能进行了提升；另一方面，设计了全新的密钥分发方案，保证了密钥使用的安全性和抗泄露性。以上创新方案的实施，将使得密钥管理技术在金融容器云中更加高效、灵活，并显著提升数据安全性。报告通过详细的测试验证了方案的有效性和实用性，为强化金融行业容器云中的重要数据防护提供了实证基础与参考。关键词：容器云、镜像加密、密钥管理、数据安全、云计算V 1 3（一）研究背景 3（二）研究目标 4 7 7 8 11（一）加速镜像分发解密 11 12 15（一）优化镜像解密速度 15（二）设计新的密钥使用方案 20 26 26（二）数据层密钥分发 27 28 30 451一、引言多项政策法规颁布促进信息安全防护。“十四五”期间，国家将大力发展科技创新，其必要性在一定程度上高于经济建设。国产密码作为科技创新和自主创新的核心，在建设数字化世界时应立足于信息安全人才建设，创新领域的信息保护和国产化信息完善高效的金融市场、建立更加高效的银企关系、激活劳动力市场，以满足和适应我国自身追赶、崛起和应对经济全球化竞争的需要。随着密码技术的飞速发展，金融和重要领域密码应用的深入推进和国际化拓展，以及新技术新应用新业态的不断涌现，商用密码迎来了大有可为的发展机遇期[1]。美国自1996年以来，颁布了《2001年关键基础设施保护法》《2002年关键基础设施信息法》《加强联邦网络和关键基础设施安全》等十余部立法、总统令和计划，大力推进联邦信息技术基础设施现代化，改善关键基础设施的网络安全态势和能力。欧盟在最新的《欧盟安全联盟战略》中将增强关键信息基础设施的保护水平和恢复能力作为未来五年网络安全领域的核心工作[2]。2021年7月30日，《关键信息基础设施安全保护条例》（以下简称《条例》）正式公布，标志着我国网络安全保护进入了以关键信息基础设施安全保护为重点的新阶段[3]。作为网络安全法的重要配套立法，《条例》积极应对国内外网络安全保护的主要问题和发展趋势，为下一步加强关键信息基础设施安全保护工作2提供了重要法治保障。随着相关法律和规范的发布实施，以《中华人民共和国网络安全法》和《条例》为基础，组建了一个较为完善的关键信息基础设施保护的法律体系。金融、电力、能源、通信、交通等领域的关键信息基础设施都是我们经济社会运行的神经中枢。国家工业信息安全发展研究中心数据显示，2020年，人工智能研判的工业信息安全重大风险近800条，涉及制造业、交通、市政等多个行业，高危漏洞占比居高不下。关基是重要行业和领域关键业务的承载和支撑基础，他的破坏一定会通过关联行业和领域逐层传递，对整个经济和社会运行，还有国家安全本身，就是连锁、连片的影响。《条例》第五十条明确了关键信息基础设施中的密码使用和管理，应当遵守相关法律、行政法规的规定。使用密码技术能够抵御外部黑客攻击，防止内部人员窃取。当下的数据泄露事件频网络为中心的安全”，升级到“侧重以数据为中心的安全”。通过密码技术能够实现对核心数据的机密性和完整性保护，将明文变为密文，配合健壮的密钥管理体系，可以防止明文存储引起的数据泄密、突破边界防护的外部黑客攻击以及来自内部越权用户的数据窃取，从而在根本上解决敏感数据泄漏带来的业务风险问题。商用密码产业的发展依托信息安全产业为基础，并长期存在依存关系，安全的迫切性和重要性为商用密码行业和企业的发展带来广阔空间。3二、研究背景及目标密码技术支撑软件供应链安全。现代软件开发框架和方法侧重于软件交付的速度和可靠性，以及在软件利益相关方之间共享所有权。然而，随着软件供应链的广泛覆盖面和复杂性的增加，软件供应链安全问题日益受到关注。软件供应链由所有有助于开发和交付软件的代码、人员、系统和进程组成，包括在组织内部和外部。由于软件供应链攻击的不断增加，评估并解决软件供应链的安全性已成为软件开发和交付过程中的重要密码技术与软件供应链安全相结合，以进一步提高软件的安全性和保密性。例如在软件构建流水线上，通过使用加密技术，可以对软件进行加密处理，只有持有相应密钥的工作负载才能够解密和访问软件，从而防止软件的未授权访问和使用。使用签名技术，对软件进行代码签名、镜像签名等，以保证软件的不可篡改。云计算环境中海量数据互访，需关注密钥使用安全。随着云计算技术的普及和应用，当前各种关键操作都有着密钥的参与，例如API访问、HTTPS访问等，用以保障访问安全和数据信任。然而，因为云计算环境的特殊性质，例如分布式、虚拟化、多租户、多层次等，使得密钥的保护和管理变得更加复杂和困难[4]。因此，云计算环境中密钥的使用安全性问题也越来越受4到关注。在云计算环境中，密钥被广泛用于数据加解密、签名验签、认证等关键操作。而这些操作又是保证云计算安全性的基础。但是，密钥使用的安全性往往存在着风险。例如，密钥可能被泄露或盗用，从而导致数据被窃取或篡改。此外，云计算环境中密钥的管理和维护困难，也是导致密钥使用安全风险的一个重要原因。总之，云计算环境中密钥使用的安全问题已经成为亟待解决的问题。我们需要深入研究云计算环境中密钥使用的安全问题，探索更加有效和可靠的解决方案。微软在2020年发布了Kubernetes威胁矩阵[5]，如图1所示。其中概述了Kubernetes中的安全威胁和攻击方式，以及建议的防御措施，并于2021年对其进行了更新。重点放在Secret、ServiceAccount及镜像保护等方面的安全问题上。51.镜像制品机密性防护矩阵中提到在使用容器镜像时存在一定的安全风险，例如镜像中包含有漏洞或者恶意软件。建议使用可信的镜像仓库并定期升级容器镜像，同时加强容器镜像的审查等。现在对容器的攻击出现了新的方式，会对云原生应用的部署速度有很大的影响。相关IT企业在做数字化转型时，都渴望将微服务应用程序迁移到云原生上。但是，当越来越多的核心应用完成云化改造，就导致容器安全问题更加重要，解决起来就会更加棘手。在软件开发中，广泛采用DevOps以加快软件交付速度并提高交付质量。从代码到容器镜像的过程中，镜像制品的构建和交付是至关重要的一步，因为他们是软件的基础组件。因此，构建和6交付过程中的安全问题必须得到重视，以避免遭受恶意攻击和数据泄露等风险[6]。在镜像的安全防护上，前期通过静态检查工具对代码进行审查，后期通过扫描任意状态容器、宿主主机等方式来确认是否包含漏洞。但容器的更新速度通常要比单体应用高出几个数量级。每一个容器和他们运行的平台在每次更新时都需要进行扫描。镜像本身就是一个完整的可运行系统，且为明文状态。无论是DevOps或是传统构建下，针对产品都可以采用代码混淆、加密压缩等方法来防止代码资产泄露。在公开报道中，Docker官方镜像库DockerHub在2019年曾被攻击，泄露了超19万用户信息[7]。通过泄露的用户信息可以很容易地访问用户的私有镜像仓库，从而获取相应的明文镜像制品，使用户数字资产受损。2.集群密钥安全性提升攻击者可能通过各种方式获取Secret中存储的密钥或其他敏感数据，例如使用钓鱼攻击、漏洞利用或者暴力破解等方法。建议采用加密方式保护Secret，并对Secret进行适当的权限管理。提升API访问密钥的安全性。ServiceAccount是Kubernetes中用于管理Pod访问API的一种机制，但攻击者也可以利用ServiceAccount的漏洞或者弱密码进行攻击，从而获取Pod的权此外，微软还提到了其他安全威胁和攻击方式，例如容器逃7加强网络隔离、使用安全容器镜像等。通过本课题的研究，从两方面尝试解决以上问题。一方面，提升镜像制品的安全性并对性能进行优化。另一方面，提出一种新的保护API访问密钥的措施。三、国内外研究现状（一）镜像加密技术镜像加密技术是一种新兴的数据安全技术，由IBM研究院主导[8]。该技术的主要目的是在容器镜像的构建、传输和运行过程中，保护敏感数据的安全性，防止数据泄漏和窃取。IBM研究院遵循OCI（OpenContainerInitiative）规范，设计、开发并维护了ocicrypt[9]、imgcrypt[10]等项目，为OCI镜像提供加密和解密功能。推动开源生态像containerd、podman、Docker、CRI等对该规范的支持工作。实现上，ocicrypt通过在OCI镜像的Manifest文件中添加加密信息，并对Layer进行对称加密。在使用ocicrypt加密OCI镜像时，用户需要提供一个用于镜像加密操作的公钥。ocicrypt会修改镜像的Manifest文件，并添加加密信息。在部署镜像时，只有具有私钥的用户才能解密镜像中的数据。标准的镜像加密流程如图2所示，Bob生成一个对称密钥用于对镜像的Layer进行加密，使用Alice的公钥加密对称密钥，完成对称密钥的数字信封。加密镜像整体结构符合OCI规范，当前常用的镜像制品库都支持OCI镜像的存储和分发。当然，也可以导8出为加密的Tar文件进行离线分发。经前期对ocicrypt项目的深入研究，本文提供了基于硬件的PKCS11的支持方案，使得密钥可以存储在安全硬件中，推动了商用进程。当前镜像加密技术已经完全支持PKCS11接口，并在IBMCloud中商用。（二）KubernetesSecretKubernetesSecret是存储敏感数据（如凭据、密码和令牌等）的对象。类似于ConfigMap，但其专门用于保存敏感数据。主要用于在Pod中安全地传递和存储敏感数据。敏感数据以未加密的方式存储在API服务器的底层数据存储（etcd）中[11]。在Kubernetes中有两种使用Secret的方法。一是将Secret作为卷挂载到Pod中，从而允许Pod中运行的应用程序访问敏感数据。二是将Secret作为环境变量传递给Pod。通过使用Secret，可以确保只有需要的应用程序才能访问他。但是Kubernetes仅对9Secret内存储的敏感数据使用Base64编码。对于API访问密钥等重要信息，在很长一段时间内不会更新或轮转，这对接口的安全性构成了重大威胁。默认情况下，Kubernetes的Secret以未加密的形式存储在API服务器的底层数据存储（etcd）中。这意味着任何具有API访问权限的第三方人员都有能力检索或修改Secret。同样，任何具有etcd访问权限的第三方人员也具备这样的能力。此外，任何具有权限在命名空间中创建Pod的第三方人员都可以利用这一权限来读取该命名空间中的任何Secret，包括通过创建Deployment的方式间接访问。为了确保在使用Secret时的安全性，Kubernetes官方给出了一些建议[11]：一是启用静态加密功能，以保护Secret的机密性。二是使用最小权限原则来访问Secret，并启用或配置基于角色的访问控制（RBAC）规则。三是在可能的情况下，限制Secret对特定容器的访问。四是考虑使用外部密钥存储服务。Kubernetes当前已经为用户提供了更多保护敏感信息的选择，包括对etcd数据的加密保护、通过CR（CustomResources）增强Secret，以及扩展CSI（ContainerStorageInterface）提供密码管理能力。etcd数据的加密保护。为了解决数据存储安全问题，Kubernetes已经实现了对etcd数据的存储保护。这意味着对于存储在etcd中的数据，可以采取一系列安全措施来防止未经授权的访问和篡改。此外，Kubernetes还支持ManagementService）服务的支持下对etcd内的数据进行加密。通过使用KMS服务，可以对敏感数据进行加密，并确保只有具有相应密钥访问权限的用户能够解密数据，提高数据的保密性和完整性。通过CR增强Secret。现在存在许多Operator可用于管理Secret，如HashicorpVaultSecretsOperator和ExternalSecretsOperator。这些Operator是Kubernetes的扩展工具，用于简化和自动化与Secret相关的任务。他们提供了更方便的方式来管理和更新Secret，包括生成和轮换密码、证书和令牌等。使用这些Operator，可以更好地集中管理和保护敏感信息，提高Secret的安全性和可管理性。扩展CSI提供密码管理能力。SecretsStoreCSIDriver是一个基于CSI的驱动程序，用于提供密码管理能力，允许将外部的密钥管理服务与Kubernetes集成，以更安全地存储和检索敏感信息。通过使用CSIDriver，可以将密码管理与存储解耦，从而更好地隔离敏感信息，并提供更丰富的功能，如自动密钥轮换和访问控制。这进一步提高了Secret的管理和安全性，并为企业提供了更多选择以保护其敏感信息。通过上述措施和技术，Kubernetes及安全厂商们为企业提供了更多保护敏感信息的选择。这些工具通过限制密钥的使用范围和访问权限、密钥轮转以及使用密钥管理工具等方法来降低密钥暴露的可能性，但最后都是将API访问密钥存储于环境变量中，仍需要采取措施来减少风险，并确保密钥的安全性。四、痛点及创新方向（一）加速镜像分发解密当前针对镜像的加密操作仅是使用ctr、ner文镜像使用命令行操作加密。例如使用containerd中ctr命令执行镜像加密操作，命令如图3所示。加密镜像制作起来较为繁杂，需要先构建明文镜像，再使用接收者的公钥在命令行下构建。在应用发布方，可以在构建服务器上使用脚本简化命令的输入，但随着接收者的增加，以及维护的脚本数量增加，会影响整体的构建操作和应用发布。很多场景下加密镜像同时需要配置多个接收者，例如多租户环境、镜像共享、多环境部署等。当需要使用多个接收者公钥制作加密镜像时，在密钥管理、密钥分发及使用等情况下将出现问题。随着接收者数量的增加，默认的轮询尝试解密方式就会大大影响解密效率，从而影响第一次的启动耗时。多接收者分发操作如图4所示。每个Layer生成新的对称密钥，对称密钥再由用户公钥加密为密文存储于Manifest文件中，每个接收者都拥有自身的私钥用于解密数字信封。在一个加密镜像中，为了分发方便，可以在Manifest文件中存储多个接收方公钥加密的对称密钥。当一个产品需要分发至上百个接收实体（可以是用户、终端、工作负载等）时，图4中非blobhash的一部分就会增多。当接收方启动镜像时，会进行解密操作。多接收者信息都经加密后，封装为JWE、PKCS7等格式（JWE、PKCS7是支持多接收者的密钥封装方法）。解密时，由指定算法进行解密操作，因为无法选择指定的对称密钥进行解密，所以需要循环解密。非对称解密成功则说明是当前接收者，否则尝试下一个，当结束时也没有合适的话，报错并退出。（二）设计Secret替代方案Secret作为控制层的官方组件，可以通过环境变量或文件挂载的形式向容器内提供密钥、密文等敏感信息。但其存储时仅对敏感数据进行Base64编码，没有引入任何安全防护措施，很容易就会被设备管理者及容器使用者泄露。在敏感信息的管控方面，Secret仍然存在着一定的局限性。etcd保护范围过大。在Kubernetes1.13及以上版本，增加了对Secret的静态加密保护，后期也增加了对KMS等外部密钥管理服务的支持。但从控制层面依旧可以查询到Secret中存储的密钥、token等敏感数据。跨层传输安全性差。在控制层，密钥通过yaml文件或者命令行的形式创建，但是当容器需要使用对应的Secret资源时，通常情况下需要将该资源挂载到容器当中。常见的有两种方式存储于容器内（包括环境变量和容器内文件但在容器内都是可见明文。我们创建了一个测试容器，对此进行了展示：首先，将Secret挂载于容器之中，黄字部分为对Secret内已配置的密钥引用到容器的环境变量中，yaml配置如图5所示。然后，检查容器的环境变量，可以看到之前创建的Secret，以明文形式出现在系统环境变量中，如图6所示。围绕容器云环境，提升其密钥使用和相关业务应用的安全性，需要关注3个方面：一是通过在流水线中引入加密镜像构建能力，提升对重要数字资产的保护能力。二是通过优化镜像解密能力，提高交付效率。三是通过探索Secret替代方案，减少密钥管理的风险。这些措施将有助于保护Kubernetes中的敏感信息，并提升整体的密钥安全性和业务执行效率。五、创新方案及关键点（一）优化镜像解密速度在实际应用中，多个环境中的集群需要使用同一个加密镜像，或者开发者将加密镜像分发给所有的用户。为保证一个镜像可以在多个集群多个节点上运行，制作加密镜像时需要使用所有接收者的信息。单一镜像对应多接收者就会使得镜像在加密和解密时耗时严重。加密镜像常规构建流程如图7所示。对此，我们提出了一个优化方案，旨在通过引入新的加密数据结构和快速匹配密钥机制来提高镜像的启动效率。在符合OCI规范的前提下，通过扩展manifest的annotation和layer的annotation，增加两个自定义项，达到优化的目的。该方案针对解密过程中多接收者轮询解密尝试的性能瓶颈，很好地支持了多种密钥类型和封装格式。1.通用加密数据结构为了支持多种密钥封装格式和类型，我们引入了通用的加密数据结构。定义了一个支持多种密钥类型的加密数据结构，使得能支持各种密钥格式，且使得密文最小。通过该数据结构，我们可以灵活地使用各种密钥类型，如RSA、ECC等，也可以扩展自定义。这样，我们能够根据实际需求选择适合的密钥封装格式，同时保持对多样性的支持能力。在Layer的annotation中新增mon的键，其对应的值数据结构如图8所示。KeyHash为接收者公钥的摘要，输出为OCI标准格式，形如：sha256:291aede3bd8171faa1c6eab1b6e242e4061cf7d47ad73fcafdb9ca567038ddee。Ciphertext为对应公钥对数据密钥的封装，以Base64形式存储。2.快速匹配密钥为了减少解密和验证所需的时间，我们设计了一个快速匹配密钥的算法。该算法利用高效的数据结构和索引技术，实现在镜像启动过程中的快速密钥查找。在manifest的annotation中存储layer中的公钥信息，在外层完成解析后，快速与本地的公钥摘要进行对比，通过得到的公钥的数组下标，直接解密layer中对应的数组下标密文，当解密失败后，按照顺序依次尝试解密，失败即退出。将密钥和镜像元数据相关联，并使用哈希函数生成索引。通过在镜像启动时计算哈希值，并将其与预先生成的索引进行比对，我们可以在常数时间内检索到匹配的密钥。这样，解密和验证过程中的性能瓶颈得到明显缓解。新的加密过程如图9所示。按照OCI规范，在config的annotation中添加自定义项cn.csec.image.enc.recipients，存储多接收者的公钥摘要值数组。该公钥顺序与Layer中的密文顺序一一对应。加密镜像完整manifest的格式如图10所示。Layer中common对应的值经解码后，如图11所示，是包含两个接收者的JSON结构20通过快速匹配密钥和加密数据结构的优化，能够显著提升单一镜像在多接收者条件下的启动速度，并提供对多种密钥封装格式的支持。这将使得镜像加密技术在容器化环境中更加高效和灵活，提升数据安全性和系统性能。（二）设计新的密钥使用方案以常见的APIToken为例，我们提出了一个可替代Secret的优化方案，开发了名为SecretClientPlugin（简称，SCP）的测试程序，将应用层Token与控制层区分，控制层内Operator仅用于对Pod授信和Token转发等操作，不持久化任何密钥信息，整体关系如图12所示。旨在通过密钥不落地、密钥随机化等方法增强密钥在本地的安全性和抗泄露性。该方案通过复用Kubernetes中安全认证体系，密钥分发所使用信任链与Kubernetes已有认证体系相融合。21通过使用CustomResourceDefinition（CRD）定义SecretClient资源，建立密钥分发Operator，扩大IdP（Identityprovider，身份认证提供者）的边缘验证能力，应用可以结合自身所在容器及Pod的元数据，结合Kubernetes中的验证策略和随机信息，通过Operator向IdP申请访问密钥。1.信任关系绑定使用挑战－响应认证方法，通过Operator建立Kubernetes与IdP（IdProvider）之间的初始信任。运维部署人员从IdP申请本集群的用户统一标识，用来标识集群内Operator。Master节点在集群运行稳定后，不易出现增加、剔除主节点等操作，Operator通过收集Master节点信息，汇集处理后形成集群身份信息。作为集群的UUID在IdP进行身份绑定。Kubernetes中针对ServiceAccount的认证会采用OIDC规范，密钥及issuer都配置在apiserver中。若想验证ServiceAccount22的JWTToken，就需要在初始化时将集群内配置的OIDC公钥注册至IdP中，便于IdP对上传的JWTToken进行合法性验证。完整流程如图13所示。集群在IdP注册时，会上传主节点信息集合和OIDC的JWKS。IdP对信息验证完成后，会生成对应的绑定关系并入库。2.密钥不落地23通过SecretClientPlugin中转APIToken，可以实现密钥不落地的功能。Operator完成初始化后，SecretClientPlugin就会通过配置的标签信息来处理集群内Pod的请求，也会接收SecretClient资源的配置更新。一般配置如图14所示。当Operator配置有所更改，例如增加监测Pod。spec字段内的配置有所更新，SecretClientPlugin都会对自身内部的资源进行更新或者重建等操作。当应用需要APIToken来访问业务，24可由IdP服务来生成或获取密钥所需的身份信息，如证书、令牌等。通过Operator中转密钥操作，可以避免将密钥存储在本地3.应用密钥随机化确保应用不会长期保存API接口的访问密钥，通过授信的中间插件与外部IdP交互，在策略控制下获得短期的、有时效限制的访问密钥。以此来提高集群中密钥安全性和服务端的接口安全25性，以缓解密钥泄露导致的整体安全性。通过helm或kubectl向集群内部署SCP，所在命名空间默认为secret-client-system，如图16第一步所示。SCP完成初始化后会进入持续验证，如图16第二步所示。安全员可以根据部署应用的预分配信息，如命名空间、Pod名称、标签等规则内容，创建好SecretClientyaml配置文件并应用，如图16第三步所示。SCP在接收到配置后，会对规则内的Pod进行监控，一旦Pod部署就对其进行认证，在控制层面通过Kubernetesapiserver的List、Get指令对Pod进行监控和过滤，如图16第四步所示。SCPSDK通过DNS与SCP进行gRPC通信，默认域名为secret-client-service.secret-client-system:12456，当Pod内容器需要使用APIToken对外请求时，仅需调用SCPSDK的RetrieveSecretKey接口获取密钥，如图16第五步所示。应用端在使用时，没有繁杂的认证流程，仅需调用一个接口就可以得到访问密钥，认证操作都在控制平面完成。从以往容器的环境变量、指定文件中获取访问密钥，变更为通过SDK获取访问密钥，使得密钥不落地，达到预期目的。26因为集群中不再出现明文或者简单编码后的密钥/秘密文件等，提升整体集群系统的鲁棒性，降低系统泄露风险。六、测试及应用成果（一）加密镜像分发将测试分为构建和部署两个部分，其中构建部分旨在测试Java项目构建，以评估加密镜像的构建是否对常规Java项目的操作执行和打包耗时等产生影响，进而了解其对整个流水线的影响。部署部分分别对单机和Kubernetes集群环境下环境、安装和配置在解密性能上，分别进行了理想环境的单元测试和实际环境模拟测试。在单元测试中，通过优化镜像解密速度，单一接收者和多接收者在解密耗时上都有着明显的提升。测试了等长密文在27100个接收者的情况下，我们的优化方案仅需1ms即可找到指定接收者并完成解密操作，而原有JWE方案则平均需要消耗100ms以上。在实际环境中，通过端到端的镜像拉取测试，分别进行了10个和50个接收者的解密测试。10个接收者更接近常规使用场景，50个远超常规的接收者数量，用于测试密钥封装在大数据量下的解密性能。同样采用nginx:latest作为测试镜像，构建加密镜像整体耗时基本持平，镜像解密的优化方案可将耗时缩短40%，显著提升了性能。直接构建加密镜像，并导出加密镜像的压缩文件。模拟在流水线上的构建命令，测试输出明文镜像和加密镜像的耗时。测试数据如表1所示。以常见的500M镜像为例，构建明文镜像平均耗时为27秒，加密镜像的平均耗时为30秒。（二）数据层密钥分发在Kubernetes测试环境中，部署SecretClientPlugin以验证新的集群密钥管理策略。具体测试方法和内容见附录（四）。通过复用ServiceToken、ServiceAKubernetes内建安全机制，与IdP绑定后达到信任链延伸，扩展28IdP的边界认证授权能力。在Kubernetes中建立的密钥分发Operator使得应用可以更便捷地获取更换或者轮转访问密钥，通过该Operator屏蔽了复杂的密钥更新操作，应用无需做更多改造即可集成。在长时间的应用获取密钥测试中，应用都可以及时获取到有效的APIToken，不影响业务的连续性，符合设计预期。通过控制面与数据面分离，业务所用APIToken在控制层面不可见。以确保应用不会长期保存应用接口的APIToken，通过授信的Operator与外部IdP交互，获得短期的、有安全时效的访问密钥。以此来提高集群中密钥安全性和服务端的接口安全性。大大缓解密钥泄露导致的整体安全性。通过后台进入容器后，也无法在环境变量和文件中查询到使用的密钥，基本达到增强密钥安全性的目的，符合设计预期。七、总结展望当前，我们通过两种技术的相互组合，成功地保护了密钥等敏感信息在整个应用交付生命周期中的安全性。具体来说，镜像加密技术保证了应用和应用内敏感信息的传输和存储安全，而Kubernetes密钥安全分发技术则保证了数据层面使用高频访问密钥的安全性，通过信任链延伸和增大密钥随机性来缓解密钥泄露带来的安全风险。这些技术的应用，有助于提高应用的安全性和可靠性。在未来的发展中，我们需要关注并解决Kubernetes对密码设29备硬件虚拟化的整合调度能力不足的问题，以进一步推动混合云环境的融合，并提高密码资源利用效率和性能，以实现容器和密码硬件虚拟化设备的协同调度和资源管理，有助于推动密码基础设备在云上的发展和创新。我们相信，这些改进将对云计算密码应用等领域的发展产生积极的影响。30附录：测试方案（一）加密镜像单机部署测试单机环境部署测试包括：测试环境准备、明文镜像加密、密文镜像格式检查、密文镜像解密、加密镜像运行。1.测试环境准备测试所用系统为OracleLinux8，内核为5.4.17。安装并启动指定版本containerd、nerdctl。版本信息如图17所示。初始化创建测试密钥对，私钥为prikey.pem，对应公钥为pubkey.pem，如图18所示。然后使用nerdctl导入或拉取测试用明文镜像alpine:3.16，如图19所示。312.配置解密私钥将上一步生成的prikey.pem复制到containerd配置的目录内。containerd默认配置中包含加解密的流处理器stream_processors，其中私钥存储位置在args中的选项--decryption-keys-path的参数值，如图20所示。32使用公钥pubkey.pem加密明文镜像，密钥封装采用JWE格式。加密完成后，控制台会输出加密镜像的摘要值，同时生成apline:3.16-encrypted镜像。命令如图21所示。4.密文镜像格式检查可以通过查看镜像的manifest来确认其是否为加密镜像，在加密镜像的元数据中的每一层（Layers）中，在Mediatype最后会增加encrypted字段，同时在annotations字段中会增加密钥保护消息，这里就是经过Base64编码的JWE消息。如图22所示。335.密文镜像解密nerdctl通过decrypt命令，指定私钥来解密镜像。内部containerdconvert来加解密镜像，同步会修改manifest文件，可以通过inspect查看manifest来判断加解密情况。解密操作如346.加密镜像运行像docker命令一样，使用nerdctl的run命令直接启动加密镜像，执行echo“hello”命令。containerd会默认在私钥所在目到snapshotter并完成启动。成功输出hello。命令如图24所示。（二）加密镜像Kubernetes部署测试Kubernetes环境部署测试包括：测试环境准备、Deployment部署。提供了所需的测试文件和镜像，测试用目录结构内容如图2535所示。1.测试环境准备测试所用系统为OracleLinux8，内核为5.4.17。安装并启动指定版本Kubernetes。版本及节点信息如图26所示。36配置containerd，分发解密私钥到所有工作节点，确认ctd-decoder已配置。containerd配置与单机相同，额外需要确认key_model是否为node模式。配置如图27所示。先加载测试镜像ocicrypto-0.0.1-500M.tar.encrypted到containerd中，再将镜像推送到支持OCI的制品库中，供Kubernetes部署容器镜像使用。如图28所示。372.Deployment部署使用Deployment测试jib-oci加密镜像的启动效果，无需额外配置，yaml配置如图29所示。38部署成功后，可以再获取具体node信息来测试访问，如图30所示。39（三）镜像解密优化方案测试复用附录（一）准备的单机测试环境，部署修改的ctr，重命名为ctr-enc进行测试。测试包括，测试环境准备，明文镜像加密、密文镜像解密。1.测试环境准备将编译好的ctr-enc放于PATH中。分别生成10个和50个密钥，用于测试。生成10个密钥的脚本如图31所示，50个同理。2.明文镜像加密使用ctr-enc对镜像nginx:latest进行加密，指定使用优化的common模式，并输出为nginx:common-enc，同理使用jwe输出40为nginx:jwe