越来越多的企业在把自己的业务系统迁移到公有云上运行，采用容器化和微服务架构来获得弹性扩展和快速交付的能力。容器镜像仓库作为存储和分发应用镜像的核心组件，是云原生架构中的一个关键节点。如果镜像仓库的访问权限配置不当，攻击者就可能获取到整个业务系统的代码、配置和密钥，造成灾难性的后果。
一家互联网公司在公有云上一百多个微服务全部跑在容器集群中。技术团队使用了云厂商提供的镜像仓库服务来管理所有应用的镜像。为了提内部的开发效率，技术团队在工作文档中记录了镜像仓库的访问地址和公共访问凭证，这份文档存在公司内部的知识库平台上，本应该是内网才能访问的内容。但知识库平台在一次版本升级后，管理员没有注意到平台的访问控制规则被重置了，导致部分文档的访问权限从"仅内网可访问"变成了"任何人只要有文档链接都能访问"。更糟糕的是，文档链接的工作方式是通过数字编号递增，这意味着任何拿到了第一个链接的人都可以通过递增编号来浏览其他文档。
一个安全研究人员在进行日常互联网资产扫描的时候，偶然发现了这个知识库平台的公开页面。他注意到页面上列出的文档名称中，有一个看起来非常像是记录了运维访问方式的文档。出于安全研究的目的，他点开这个文档看到了镜像仓库的地址和访问账号密码。出于负责任的漏洞披露原则，他用这个账号尝试访问了镜像仓库，结果发现账号的权限是完整的管理员权限，可以浏览仓库中的所有镜像、查看镜像的历史版本、以及拉取任意仓库中的任意镜像到本地。
他在镜像仓库中看到了这个公司全部的微服务镜像。他随机拉取了一些镜像进行解包分析，其中包含了完整的应用程序代码、服务器之间的内部通信密钥、生产数据库的连接凭证和API密钥、以及第三方支付服务的签名密钥。拥有了这些信息，任何人都可以完全接管这个公司的线上业务系统，包括读取和篡改生产数据库的数据、拦截和伪造支付订单、以及与上游供应商系统进行未授权交互。
这位安全研究人员按照行业规范，通过邮件联系了这家公司的安全团队并提交了详细的漏洞报告。公司的安全团队收到报告后惊出了一身冷汗，立即封锁了知识库平台的文档公开访问，修改了镜像仓库的所有凭证，并逐一对所有微服务中的敏感配置进行了排查和轮换。事后确认没有发现被恶意利用的证据，算是侥幸逃过一劫。
这次事件虽然没有造成实际的业务损失，但暴露出的安全隐患足以让人后怕。核心问题是安全边界的疏忽，一个小小的知识库平台权限配置错误，连锁导致了镜像仓库完全暴露、进而威胁到了整个生产系统的安全。企业不管花了多少钱在云安全和网络安全上，一个简单的配置错误就可能让整座城堡变成一个纸做的门。
从防范的角度讲，企业应当从三个方面入手。第一是对所有内部工具和平台的访问权限进行定期审查，特别是那些存储了运维文档、凭证信息和系统架构配置的平台。第二是绝不能在代码仓库和镜像中硬编码或者明文存储任何密钥和凭证，必须使用专门的密钥管理服务，所有敏感凭据都应通过环境变量或挂载卷在运行时注入。第三是对云上资产建立持续性的外部暴露面扫描，实时发现那些不应该出现在公网上的服务和资源。
