借助 AI 规模化推广 Distroless 的应用

Distroless adoption at Grab

Grab 采用 Distroless

Grab is migrating from heavy base images to Distroless images to reduce security risks. By limiting each container to the application and its runtime dependencies, we shed non-essential binaries and associated Common Vulnerabilities and Exposures (CVEs).

为了降低安全风险,Grab 正在从庞大的基础镜像迁移到 Distroless 镜像。通过将每个容器限制为应用程序及其运行时依赖项,我们剔除了非必要的二进制文件以及相关的通用漏洞和暴露 (CVE)。

This migration is more than a compliance mandate; it is a strategic security decision to build a more resilient environment.

此次迁移不仅仅是一项合规指令;它更是一项战略安全决策,旨在构建一个更具韧性的环境。

Why Distroless requires rigorous testing

为什么 Distroless 需要严格的测试

Distroless adoption risk: Runtime failure

Distroless 采用风险:运行时故障

Shifting to Distroless images introduces a critical technical risk: Runtime Failure. A service might build perfectly in Continuous Integration (CI), but fail at the deployment stage due to:

转向 Distroless images 引入了一个关键的技术风险:Runtime Failure。服务可能在 Continuous Integration (CI) 中完美构建,但在部署阶段由于以下原因而失败:

  • Missing shared objects: Binaries might require specific libraries (.so files) present in Ubuntu but absent in Distroless.
  • 缺少共享对象:二进制文件可能需要特定的库(.so 文件),这些库存在于 Ubuntu 中,但在 Distroless 中缺失。
  • Implicit links: Third-party tools might expect specific system utilities or directory structures.
  • 隐式链接:第三方工具可能需要特定的系统实用程序或目录结构。

Testing is required to ensure two things:

需要进行测试以确保两件事:

  1. The service spins up with the correct configuration.
  2. 服务使用正确的配置启动。
  3. All runtime dependencies remain intact.
  4. 所有运行时依赖保持不变。

Scaling this verification across thousands of services manually? That would take years, unless we found a way to automate the trust.

手动将这种验证扩展到数千个服务?那将需要数年时间,除非我们找到了一种方法来自动化信任过程。

The testing methodology

测试方法

As we perform changes to the Dockerfile definition of our services, it is important for us to include the corresponding test strategy to ensure that the changes that we make do not introduce a regression to our running services. Assessing the change introduced to our services, the lowest possible testing boundary would be that of what we define as medium tests i...

开通本站会员,查看完整译文。

首页 - Wiki
Copyright © 2011-2026 iteam. Current version is 2.155.2. UTC+08:00, 2026-07-01 03:58
浙ICP备14020137号-1 $访客地图$