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