如何保障微服务和 Kubernetes 的持续安全性

Mateo Burillo 认为，安全需要适应容器/Kubernetes 世界中日益快速的持续交付，这意味着安全性即代码。在RebelCon.io 2019 大会上，他展示了如何实现具备持续安全性的 DevSecOps 流程。

人类无法相当好地审查每天的多个构建；我们需要一个安全团队，能够考虑安全要求、限制和最佳实践，并使用本身了解微服务的工具将它们自动化。要充分利用 DevOps 的灵活性和响应能力，安全性必须在应用程序的整个周期中发挥综合作用。Burillo 说，应该将安全性集成到管道中，使用安全性即代码方法。

Burillo 提到了将安全性实现为代码的好处：

第一个也是最重要的是自动化：你需要扩展并加速建立你的安全流程，以适应微服务/容器的世界。

可见性：任何团队成员都可以访问和讨论安全规则，消除专有技术竖井。

可跟踪性：现在，你对所做的每个更改都拥有版本控制和所有权。

Burillo 说，容器是黑盒子，这对运营有利，但对安全不利。可能需要几天或几周的时间才能发现漏洞。这就像 CSI 一样，但是没有尸体，因为容器很可能在漏洞出现后就不见了。

在构建时，要将安全性构建到产品中，最明显的步骤是将 CI/CD 工具与镜像扫描器集成在一起。Burillo 说，人们经常将容器镜像扫描与公共漏洞列表（称为 CVE 列表或“漏洞”）以及漏洞扫描关联在一起，但这只是开始。使用高级镜像扫描器，你可以做很多事情：遵从性检查（NIST、PCI、MITRE）、发现泄漏的凭证、实现你自己的应用程序级安全实践……

Burillo 提出，Kubernetes 提供了一些特定于容器的安全遵从性标准和一组很好的开箱即用的安全功能，因此要避免重复发明轮子。

现在最常见的用例是将镜像扫描软件与你的 CI/CD 管道集成在一起，无论是 Jenkins、AWS CI/CD、Bamboo 还是其他任何东西。Burillo 提到了另一个用例，这个用例可能更具创新性，但并非没有必要：对运行时容器进行常规镜像检查。他提出了疑问，如果在 CI/CD 声明镜像“干净”后发现一个新的零天漏洞，或者如果容器受到攻击，修改了原始条件，会发生什么情况？

Burillo 提到，镜像扫描是必要的，但还不够；你还需要运行时安全性。传统的 Linux 安全工具不提供容器运行时可见性；他建议对这套工具进行现代化改造。

在 Sysdig 技术作家Mateo Burillo结束了他在RebelCon.io 2019大会上的演讲后，InfoQ 与他进行了交谈。

InfoQ：我们可以做些什么来为安全领域带来敏捷性？

Mateo Burillo：我认为，要采用的主要概念与 IT 基础设施或 QA 所经历的变革没有太大区别：将安全性实现为代码。

安全性即代码意味着你的规则需要进行版本控制并保存在存储库中。你的安全运维团队将向该存储库推送，你的环境应该能够动态地拉取并执行这些规则。

让我用一个例子来帮助阐明这个概念。

例如，使用 Anchore 实现镜像扫描，你的容器镜像将始终被扫描以检测 CVE。然后，你的安全团队决定你不希望任何容器以 root 身份运行或泄漏 AWS 凭据。

• 安全团队修改*扫描策略*并将新版本推送到内部存储库。

• 编写 Anchore 引擎脚本，用于检测、下载和应用此更新。

• 你的 CI/CD 工具，比方说 Jenkins，负责构建镜像。它可以很容易地*与Anchore集成*，构建管道的其中一个步骤会运行这个镜像扫描验证。只有获得 Anchore 批准的镜像才会被 Jenkins 签名并推送到内部注册中心。

• 使用 Admission Controller 配置 Kubernetes，以拒绝运行任何 CI/CD 工具没有签名的镜像。

在上面的例子中，安全团队只需要设计高层次的安全目标；其他一切都是自动化的。

InfoQ：我们可以做些什么来确保在容器中运行的应用程序以一种安全的方式运行？

Burillo：要知道，IT 不存在 100%的安全性保证，我们可以做几件事来尽可能接近 100%：

• 镜像扫描，以检测已知的漏洞，并遵循与你的 IT 部门和你部署的应用程序类型更相关的最佳安全实践，例如：

• 你知道你的应用程序只需要从外部卷装载/web/html；Dockerfile 中的任何其他文件系统操作都应该发出警告；

• 你有与 GLPv3 不兼容的许可；任何声明需要该许可的软件包都要报告。

• 根据容器特定的安全遵从性框架验证容器。不重复发明轮子是安全的黄金法则之一，这就是为什么我们有标准，举几个例子：

• NIST SP 800-190应用程序容器安全指南；

• 互联网安全中心（CIS） Kubernetes 基准测试；

• 支付卡行业数据安全标准或PCI DSS。

• 你需要深入的可见性和可跟踪性，以了解容器是如何构建的，以及它们在运行时是如何操作的。你无法阻止你看不到的安全威胁；

• 实现运行时安全规则和自动修复。容器是简单的机器，这在运行时是一个巨大的优势，因为你可以很容易地预测它们的行为，并立即检测是否有可疑的事情发生。让我们使用该特性来提高 IT 安全性。

InfoQ：Kubernetes 有哪些安全特性，你有什么使用建议？

Burillo：特性真的有很多，最好的（最差的？）的方面是这个名单在不断增长：RBAC、准入 webhook,、pod 安全策略、网络策略、自动证书轮换、资源配额……

我的建议是像统计学家一样思考。这有一个超速驾驶的危险，只是尽可能地实现你能想到的规则。从过去的攻击、开发者的经验、生态系统中臭名昭著的安全漏洞、面向安全的 Kubernetes 通讯和博客中收集数据。然后思考：下一个将最大化安全性并最小化我需要引入的复杂性的安全性规则是什么？

有一个很好的例子，我们将一个脆弱的Kubernetes集群作为一个蜜罐暴露在互联网上。该集群是故意留有缺陷的，但是攻击、攻击检测和取证是真实的。这些安全漏洞演练将帮助你识别和阻止你的生态系统中的实际攻击活动。记住，它们总是在变异和适应；安全是一场军备竞赛。

InfoQ：我们如何检测在容器中运行的软件的异常？

Burillo：正如我前面提到的，容器的主要优点是它们本质上是“简单的”，所以你可以轻松地找出规则来确定在运行期间允许什么和禁止什么。然而，主要的障碍是，在容器出现之前存在的大多数安全软件都完全无视运行时容器操作——你可以分析输入和输出的内容，但除此之外，它只是一个黑盒。

我们一直推荐使用Falco进行运行时异常检测；它的设计从一开始就考虑了容器，得益于它的内核级检测，你可以获得全面的可见性和可跟踪性。最后同样重要的是，它是完全开源的，并且是一个 CNCF 沙箱项目。你可以立即开始尝试，甚至将你的容器安全规则贡献给社区:)。

原文链接：

Implementing Continuous Security for Microservices and Kubernetes