前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >容器安全 101:安全高效操作指南

容器安全 101:安全高效操作指南

作者头像
云云众生s
发布2024-03-27 19:32:51
1040
发布2024-03-27 19:32:51
举报
文章被收录于专栏:云云众生s

容器安全 101:安全高效操作指南

翻译自 Container Security 101: A Guide to Safe and Efficient Operations

容器是交付云原生应用程序的事实标准。以下是有关它们所带来的安全风险以及采取哪些对策来保护它们的指南。

这篇文章是 KubeCon + CloudNativeCon Europe 2023 预览系列的一部分,该活动将于 4 月 18 日至 21 日在阿姆斯特丹举行。加入我们,了解更多关于云原生应用程序和开源软件的变革性质。

在过去的几年里,容器的采用彻底改变了一切。容器成为软件部署的事实标准,提供了广泛的优势,例如:

  • 快速部署
  • 自动化
  • 资源隔离
  • 工作负载可移植性
  • 更好的可观测性

在我们深入讨论技术细节之前,让我们通过简要回顾容器在软件开发上下文中的含义来确保我们理解一致。

容器是使用专用资源运行的系统进程(从主机的角度来看)。现在,下一个可能出现的逻辑问题可能是:这些容器是如何创建的?

回答这个问题可以让我们进一步理解本文主题的核心。

镜像

容器是从 OCI 镜像生成的,这些镜像包括以容器化方式运行应用程序所需的元素,例如代码、配置文件、环境变量、库以及描述其需求和能力的元数据。

容器生成中最常见的场景是开发人员依赖从公共注册表中获取的基础映像,并将开发的软件添加到其中。

开发人员可以使用不同类型的基础镜像;它们可以是“简单的”,如基本操作系统镜像,也可以是“复杂的”,并且已经包含特定系统库或工具等信息。

正如“魔鬼藏在细节中”,DevSecOps 也是如此。

  • 你真的可以信任并依赖别人制作的基础镜像吗?
  • 考虑基于公共镜像的“生产就绪”软件是否安全?

确保选定的基础镜像在执行时不会产生任何安全影响可能具有挑战性,尤其是当您依赖“复杂”镜像时。

安全?是的,请!

让我们从基础开始:意识到风险是采取对策的良好起点。

开发人员可以从不同的来源拉取基础镜像来构建他们的容器,主要来自公共 registry ,例如:

  • Docker HUB
  • Quay.io
  • 云提供商 registry(Amazon ECR、Azure Container Registry 等)

其他常见来源是 git 仓库,开发人员可以在其中轻松找到包含构建所需说明的 Docker 文件。

这是开源力量的一个很好的例子,因为它使每个人都可以从别人的工作开始构建自己的镜像。

缺点是在生产中部署它们时需要考虑风险:

  • 恶意代码
  • CVEs
  • Bugs
  • 镜像错误配置

让我们深入了解这些问题,并介绍开发人员可以实施的最简单的最佳实践,以避免它们。

恶意代码

限制镜像带有恶意代码的风险的一个好方法是仅从官方来源或经过验证的开发人员处提取基础镜像。

知名的公共 registry 有许多经过验证的官方开发人员/公司,他们推送和维护更新的镜像。

CVEs

以所有 registry 为例,它们都会定期进行漏洞扫描,提供有关当前检测到的漏洞的报告。

如果镜像没有经过定期扫描和修补处理,那么就没有官方仓库可以完全解决这个问题。

Bug 和镜像错误配置

仅使用最近和定期更新的镜像可以减轻 Bug 和镜像配置错误。例如,从 Kubernetes 的安全角度来看,一个好的缓解措施可能是一个 admission webhook,它拒绝部署基于早于给定日期的镜像的容器。

涉及的风险

. 在这个阶段,应该清楚的是,使用容器和镜像是一件令人兴奋的事情,但需要以正确的方式或至少有意识地进行。

不幸的是,在过去几年中,许多安全漏洞都被利用在受损的 CI/CD 供应链上,有时是由注入到图像中的恶意代码驱动的,有时是利用已知的 CVE。

在 2023 年,DevOps 绝对应该意识到这些风险,并相应地与内部安全团队合作以减轻这些风险。

如何规避风险? (容器安全黄金法则)

现在情况很清楚了。我们怎样才能安全地生活,或者至少降低风险?

答案可能很长很复杂,并且取决于生产工作负载所需的安全级别。

一些基本的一级规则:

  • 仅从受信任的 registry 中检索镜像。
  • 仅使用官方镜像。
  • 在考虑使用之前检查漏洞数量。
  • (至少)修复图像的严重漏洞。
  • 可用时使用最近的镜像。

关于容器镜像的另一个重要建议是越小越好。

使用完整的操作系统作为基础容器镜像可能有助于故障排除,但镜像中更多的库和可执行文件也意味着更大的攻击面。

作为风险缓解,DevOps 应考虑使用最小的 Linux 基础镜像(如 Alpine)或无发行版容器镜像。

不过,请考虑一下,这种策略会使故障排除变得更加困难。仅在生产环境中使用最少的基础镜像可能是安全性(最重要的地方)和开发期间故障排除之间的良好折衷。

结论

考虑到基础镜像的安全方面,随着时间的推移保持它们的更新和安全可能具有挑战性。通常,依靠可信来源、经过验证的注册表和使用更新的镜像就足够了,但情况并非总是如此。

如果容器化工作负载的高安全级别是强制性的,例如金融、保险或任何其他高风险环境,那么一个好主意可能是依赖提供安全、经过验证和定期更新镜像的专用服务。

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2023-04-11,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 容器安全 101:安全高效操作指南
    • 镜像
      • 安全?是的,请!
        • 恶意代码
        • CVEs
        • Bug 和镜像错误配置
      • 涉及的风险
        • 如何规避风险? (容器安全黄金法则)
          • 结论
          相关产品与服务
          容器服务
          腾讯云容器服务(Tencent Kubernetes Engine, TKE)基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务,覆盖 Serverless、边缘计算、分布式云等多种业务部署场景,业内首创单个集群兼容多种计算节点的容器资源管理模式。同时产品作为云原生 Finops 领先布道者,主导开源项目Crane,全面助力客户实现资源优化、成本控制。
          领券
          问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档