容器安全技术Grafeas

Kubernetes 开源安全工具

除了商业软件以外，不断发展的开源软件
项目也能够提供一定的安全功能。以下是其中的一些开源项目，它 们一般被用在非关键业务的保护场景中。#### Kubernetes 原生网络策略
Kubernetes 网络策略提供 L3/L4（IP 地址 / 端口）级别的网络隔离。Kubernetes 本身并不提供网络功能， 它只是将网络接口开放出来，进而使用相关的网络插件来支持网络策略的执行。比如 Flannel[25]、Calico
[26]、 Contiv[68]、Cilium[69]、Kube-router[70]等。#### Istio
Istio 是由 Google、IBM 和 Lyft开源的微服务管理、保护和监控的框架。它通过创建一个服务网格（Service Mesh）来管理服务到服务通信，包括路由、认证、授权和加密。其架构图如下：

Istio 的定义可以简述为提供一种简单的方式来建立已部署服务的网络，具备负载均衡、服务到服务认证、监 控等功能，而不需要改动任何服务代码。
如上图所示，Istio 主要由控制平面和数据平面组成：
（1）数据平面

• Envoy：Envoy[71]是 C++ 开发的高性能
  代理，用于调解服务网格中所有服务的所有入站和出站流量。 （2）控制平面- Mixer：Mixer 负责在服务网格上执行访问控制
  和使用策略，并收集 Envoy 代理和其它服务的遥测数据。- Pilot：负责收集和验证配置策略并将其传播到各个 Istio 组件，它从 Mixer 和 Envoy 中抽取环境特定的实 现细节，为它们提供用户服务的抽象表示，独立于底层平台。
• Citadel：提供强大的服务到服务和终端用户
  认证，使用交互 TLS、内置身份和凭据管理方式。
  Istio 同时提供了一套安全机制，秉承着不更改服务代码的原则，通过在微服务所属容器旁部署一个 Sidecar 容器 [^1] 来对服务的安全进行防护。主要分为以下两个方面：
  （1）认证
  Istio 提供以下两种类型的身份验证：
• 传输身份验证（服务到服务身份验证）：Istio 提供双向 TLS作为传输认证的完整解决方案。
• 来源身份验证（最终用户身份验证）：验证原始客户端请求作为最终用户或设备。Istio 通过 JSON Web Token（JWT）验证和 Auth0、Firebase Auth、Google Auth 和自定义身份验证来简化开发人员体验，并 且轻松实现请求级别的身份验证。
  在这两种情况下，Istio 都通过自定义 Kubernetes API 将身份认证策略存储在 Istio 配置存储中。 Pilot 会在适 当的时候为每个代理保持最新状态以及密钥。此外，Istio 支持在许可模式下进行身份验证，以帮助用户了解策略 更改在其生效之前如何影响用户的安全状态。
  网格操作者可以使用身份认证策略为在 Istio 网格中接收请求的服务指定身份验证要求。认证的架构如图 5.2 所示。网络管理员（Administrators）使用 yaml 配置文件来设置策略，分别在 Namespace Foo 及 Namespace Bar 上部署，部署后策略保存至 Istio 配置存储（Istio Config Store）中，由 Pilot 监视配置存储，当有策略发生变 更后，Pilot 会将新的策略转换为适当的配置并告知和服务实例位于同一位置的 Envoy Sidecar 代理如何执行所需 的身份验证机制。Namespace Foo 中定义的策略目标服务为 SvcA，所以对应策略的执行指向 SvcA 中的 Envoy Sidecar 代理。同理，下方定义的两个策略目标服务分别为 ALL和 SvcB，所以对应策略的执行分别指向各自的代理。

（2）授权
Istio 的授权功能也可称为基于角色的访问控制（RBAC），RBAC 为 Istio Mesh 中的服务提供命名空间级别， 服务级别和方法级别的访问控制，其特点为：

• 基于角色的语义，简单易用。
• 服务到服务和最终用户对服务的授权。
• 通过自定义属性支持的灵活性，例如条件，角色间绑定。
• 高性能，因为 Istio 授权是在 Envoy 本地强制执行的。
  Istio 官方给出的授权架构如下图 5.3 所示。网络管理员可设置 yaml 配置文件的 Istio 授权策略并进行部署， 部署后 Istio 将策略保存在 Istio 配置存储中，并由 Pilot 监 Istio 授权策略的变更。如果 Pilot 发现任何更改，将 获取新的授权策略。Pilot 将 Istio 授权策略分发给服务实例位于同一位置的 Envoy Sidecar 代理。每一个 Envoy Sidecar 代理都运行一个授权引擎，该引擎在运行时授权请求。当请求到达代理时，授权引擎根据授权策略评估 请求上下文并返回授权结果（ALLOW 或 Deny）。

Grafeas

Grafeas[72]是 2017 年 Google 联合 JFrog、IBM和其它一些公司推出的一款用于审计和管理软件供应链的工具。
随着 DevOps、微服务的不断发展，软件交付的速度越来越快，交付的二进制包（包括 Docker 镜像）基本呈 现出指数增长的趋势。由于软件开发中多种语言的数据规范存在较大差异，例如 Go 语言使用 URL定义自己的组 件地址、Java 有自己的相应规范、Docker 使用 Sha256 表示每一层，这些规范的差异性，导致容器镜像在交付 生产环境前，很难判断容器镜像内包含的多种语言的二进制包的质量信息以及漏洞信息。
Grafeas 起源于容器的安全质量管理，但从官方对其定义来看它并不局限于容器，而是通过开源工件元数据 API提供统一方式来审计、监控软件组件。这里的“软件”可以是容器镜像，也可以是 war、jar 或 zip 包。
图 5.4 展示了在容器环境中，在镜像交付生产环境之前，多方参与的编码、构建、扫描、测试、部署步骤。 在上述每个阶段，Grafeas 都会通过 Grafeas API 将其关键元数据进行收集。特别在部署阶段，可以有效地检测 是否符合最终的安全规范。

Grafeas 的安全策略可以通过与第三方工具的集成来执行，它可以用于管理 CI/CD管道，但并不会管理运行 时的容器安全。

Clair

Clair 是 CoreOS 于 2015 年 11 月发布的开源容器分析工具，旨在解决容器镜像的安全漏洞问题。Clair 对容 器镜像执行静态分析，并将其内容与公共漏洞数据库相关联，形成对应的分析报告。

Clair

Image Scan Worker Notifier
PostSQL DB
Detector WebHook
Clair 模块主要包括检测器（Detector）、获取器（Fetcher）、通知器（Notifier）和数据库（PostSQL）等。 当对某个镜像进行检测时，首先对镜像进行特征的提取，然后再将这些特征匹配 CVE漏洞库。具体流程包括：

• 用户调用 Clair 的 REST API，上传待检测镜像的每一个 layer，对应每一个 layer，Clair 都会创建一个 Worker 对其进行处理；
• 每一个 Worker 启动一个 Detector 来对收到的 layer 进行扫描；
• Detector 首先对上传的 layer 压缩包进行解压，然后解析出操作系统的类型以及版本，最后解析出其所 安装应用的名称及版本；
• Updater 启动一个 Fetcher，Fetcher 根据前一步解析到的操作系统类型，查找对应的 CVE漏洞库，查看 当前版本的操作系统以及其上的应用程序是否存在漏洞。
  对于漏洞信息，Clair 将会启动一个 Notifier+WebHook 的异步流程。WebHook 不断的在各大 CVE网站爬取 最新的漏洞信息，当暴露出新的 CVE漏洞时，通知 Notifier 并将漏洞信息更新到数据库中。

从history 中获取lay erIDs
否
存 在 是
镜像分析 保存镜像到本地 读取m anifest.json 解析每一层
layerIDs
获取漏洞信息 匹配C VE漏洞 解析特征版本 解析nam espace 发送lay er.tar到API 打印扫描报告 CVE漏洞入库 定时抓取C VE漏洞
用户可以通过轻量的 Clair 客户端工具 Clairctl[73]执行简单的命令行，实现镜像的上传、扫描、输出报告等。

参考资料

绿盟 容器安全技术报告

友情链接

GA 313-2021 警鞋 男毛皮鞋