Kubernetes 安全最佳实践——K8s 程序的常见漏洞和暴露

Kubernetes 已成为容器化应用程序的编排、扩展、自动部署和管理的首选工具。

简而言之，Kubernetes 是一个在一组机器上维护不同应用程序之间协调的系统。

需要注意的是，该系统主要处理容器化应用程序，例如 Docker 镜像。这基本上是一种虚拟化形式，其中应用程序在被称为容器的隔离用户空间中运行。

容器的安全问题

一旦用户定义了应用程序应该如何运行以及与其他应用程序和外部交互的规则。任何涉及人为干预的事情都容易出现缺陷和错误。

错误的严重程度通常取决于管理容器的人员的技能。有时，即使是最轻微的错误也会破坏系统。一个值得注意的例子是 Java 中的Log4j 漏洞，该漏洞最近在互联网上引起了重大故障。

软件/应用程序通常不可能100% 的安全，不受攻击者的影响。但这不应错误地暗示存在漏洞是可行的。应该持续寻找安全漏洞和暴露，并在可用时对其进行修补。

这种缺陷可能会使集群或容器变得易受攻击，从而允许未经授权的个人利用它们。而随着 Kubernetes 越来越受欢迎，我们需要更仔细地考虑如何评估其功效和管理容器安全问题。

为了更好地保护您的 Kubernetes 配置和程序，让我们看看一些常见的漏洞、暴露和 Kubernetes 安全最佳实践。

配置困境

如果你是 Kubernetes 世界的新手，并且你正在自己部署一个项目，那么你可能很难弄清楚安全配置规则。这是因为， Kubernetes 在这种情况下没有提供足够安全的默认配置规则。

尽管在你尝试掌握环境时，安全配置的重要性并不高，但在部署到生产的后期阶段它变得至关重要。

类似的问题也存在于pod 之间的通信方式。这些通信权限是由网络策略定义，但默认情况下，没有这样的策略与 pod 关联。同样，这是您需要手动配置的东西。

解决此问题的一个简单方法是启用基于角色的访问控制 (RBAC) 来定义谁可以访问 API 以及他们拥有什么授权。

你可以使用诸如allowPrivilegeEscalation和readOnly等属性来升级可读性和特权级别方面的安全性。

下面的策略显示用户“bob”的授权级别：

{
    "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
    "kind": "Policy",
    "spec": {
    "user": "bob",
    "namespace": "projectCaribou",
    "resource": "pods",
    "readonly": true
    }
}

这里，用户“bob”只被授权从命名空间“projectCaribou”中读取对象。如果请求的类型是“写入”或“更新”，则操作将失败。

Docker 镜像中的恶意代码

由于 Kubernetes 经常处理容器化应用程序，通常是Docker 镜像[1]，因此攻击者经常通过从容器化应用程序内部获取访问权限来突破集群或 Kube 节点。

虽然有不同的解决方案可以避免不同类型的攻击，但你始终可以限制内存资源的使用以防止 DoS 攻击。

你可以通过配置一个入口控制器来做到这一点，该控制器被定义为限制某一时间范围内的请求数量——例如，每秒 10 个请求或每分钟 1000 个请求。

你可以通过限制每个客户端 IP 的请求或通过在服务主机级别限制请求来实现这一点。

另外，也可以定义访问控制列表，只允许单个或选定的 IP。这种缓解技术确保没有匿名请求流量涌入服务器，同时也确保只处理来自可靠来源的流量/请求。

在部署前扫描应用程序也是一个很好的经验法则，以检测恶意代码并立即采取行动。

集群安全，传输不安全

通常，我们只优先考虑集群的安全性，因为这是处理应用程序的地方。但有一件事常常被忽视，那就是传输系统默认不包含任何形式的安全措施或加密。

这是一个常见的暴露问题，忽视它可能为入侵者打开大门，让他们未经授权访问你的系统。这意味着传输安全层(TLS) 应该处理集群中服务集群间的通信。

网络技术的改进导致出现了 LinkerD 等产品，这些产品可以默认启用 TLS，同时还提供有关服务事务的额外遥测信息。

同样的原理也适用于存储集群状态的“ etcd ”。如果不加以保护，这将成为攻击者的一个有吸引力的目标，因为攻击者有可能接管整个集群。即使他们只有读取权限，他们也可能滥用它来提升权限。

关注运行时

即使你成功克服了与策略和配置相关的漏洞，运行时也会出现一系列新的障碍。运行时安全漏洞的一个例子是一个运行恶意进程的被破坏的容器。

尽管加密货币开采成为闯入容器设置的恶意行为者的热门目标，但攻击者可以从受被破坏的容器中进行其他敌对行动，例如网络端口扫描，以开放访问所需资源。你可以主动监控对安全至关重要的容器的运行时活动，例如进程活动和网络通信，以解决这些和其他运行时问题。

此外，还强烈建议你合并构建和部署时间信息，将观察到的活动与运行时的预期活动进行比较。这样可以更容易地发现任何异常行为。

合规问题

在云原生系统中，遵守安全标准、监管要求和规范以及组织的内部规定可能很困难的。

合规失败的最常见原因是在采用容器的过程中忽略了安全方面。

缓解此类漏洞的最佳方法是在容器生命周期的早期采用安全控制。最大限度地自动化必要的检查也是减少管理费用的好方法。

总结

安全性对容器很重要，这也是在使用Kubernetes时需要考虑和管理的问题。归根结底，最终目标应该是让入侵者难以访问你的系统。即使他们碰巧成功了，基础设施也应该足够好，可以检测到异常活动并调度行动以防止其传播。

正如NCC Group首席安全顾问 Rory McCune所说，

“Kubernetes 非常复杂，很容易在配置上出错。”

Kubernetes 和容器漏洞，如果不打补丁，可能会导致严重的暴露。

本文译自：Kubernetes Security – Common Vulnerabilities and Exposures for K8s Programs[2]作者：Prajwal Kulkarni

引用链接

[1]

Docker 镜像: https://docs.docker.com/engine/reference/commandline/image/

[2]

Kubernetes Security – Common Vulnerabilities and Exposures for K8s Programs: https://www.freecodecamp.org/news/kubernetes-security-common-vulnerabilities-and-exposures/"