滥用 Kubernetes 资源登上月球

Sysdig 2024 年云原生安全和使用报告强调了不断变化的威胁形势，但更重要的是，随着容器和 Kubernetes 等云原生技术的采用不断增加，并非所有组织都遵循最佳实践。当攻击者在 Kubernetes 等操作中利用容器来利用资源时，这最终会给攻击者带来优势。

平衡资源管理与安全不仅是一项技术挑战，也是一项战略任务。令人惊讶的是，研究报告发现，不到一半的 Kubernetes 环境有 CPU 和内存使用警报，而且大多数环境对这些资源缺乏最大限制。这种趋势不仅仅是忽视安全实践；它反映了优先考虑可用性和开发敏捷性而不是潜在的安全风险。

未经检查的资源的安全风险

Kubernetes Pod 中的无限资源分配为攻击者提供了绝佳的机会。如果没有限制，恶意实体可以利用您的环境，发起加密劫持攻击或发起横向移动以瞄准网络中的其他系统。缺乏资源限制不仅会加剧安全风险，而且还可能由于这些攻击者不受控制的资源消耗而导致巨大的经济损失。

具有成本效益的安全策略

在当前的经济形势下，每一分钱都很重要，了解和管理资源使用既是一种财务策略，也是一种安全策略。通过识别和减少不必要的资源消耗，组织可以显着节省成本——这在云和容器环境中都是至关重要的方面。

在 Kubernetes 中实施资源限制

在 Kubernetes 中实施资源限制既简单又有效。要将资源限制应用于atomicredKubernetes 中的示例工具部署，用户只需修改其部署清单以包含resources请求和限制。

以下是 Kubernetes 项目建议实施这些更改的方式：

kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: atomicred
  namespace: atomic-red
  labels:
    app: atomicred
spec:
  replicas: 1
  selector:
    matchLabels:
      app: atomicred
  template:
    metadata:
      labels:
        app: atomicred
    spec:
      containers:
      - name: atomicred
        image: issif/atomic-red:latest
        imagePullPolicy: "IfNotPresent"
        command: ["sleep", "3560d"]
        securityContext:
          privileged: true
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"
      nodeSelector:
        kubernetes.io/os: linux
EOF

在此清单中，我们设置 CPU 和内存的请求和限制，如下所示：

requests：Kubernetes 将为容器保证的 CPU 和内存量；在本例中，内存为 64Mi，CPU 为 250m（其中 1000m 等于 1 个 CPU 核心）。
limits：容器允许使用的最大CPU和内存量；
如果容器试图超过这些限制，它将被限制（CPU）或终止，并可能重新启动（内存）。这里设置为128Mi内存和500m CPU。

此设置可确保为该atomicred工具分配足够的资源以高效运行，同时防止它消耗过多的资源，从而影响 Kubernetes 集群中的其他进程。这些请求约束保证容器至少获得指定的资源，而限制则确保它永远不会超出定义的上限。此设置不仅优化了资源利用率，还可以防止资源耗尽攻击。

监控 Kubernetes 中的资源约束

要检查 Kubernetes 中正在运行的 pod 的资源限制，请使用以下 kubectl describe命令。提供的命令将自动描述atomic-red命名空间中带有标签的第一个 Pod app=atomicred。

kubectl describe pod -n atomic-red $(kubectl get pods -n atomic-red -l app=atomicred -o jsonpath="{.items[0].metadata.name}")

如果我们滥用这些限制会发生什么？

要测试 CPU 和内存限制，您可以运行一个故意尝试消耗比其限制允许的资源更多的资源的容器。然而，这可能有点复杂：

CPU：如果容器尝试使用超过其限制的 CPU 资源，Kubernetes 将限制容器的 CPU 使用率。这意味着容器不会被终止，但运行速度会变慢。
内存：如果容器尝试使用超过其限制的内存，一旦超过限制，它将被 Kubernetes 终止。这称为内存不足 (OOM) 终止。

创建压力测试容器

您可以创建一个有意强调资源的新部署。

例如，你可以使用像stress这样的工具来故意消耗CPU和内存：

kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: resource-stress-test
  namespace: atomic-red
spec:
  replicas: 1
  selector:
    matchLabels:
      app: resource-stress-test
  template:
    metadata:
      labels:
        app: resource-stress-test
    spec:
      containers:
      - name: stress
        image: polinux/stress
        resources:
          limits:
            memory: "128Mi"
            cpu: "500m"
        command: ["stress"]
        args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]
EOF

部署规范使用映像polinux/stress定义单个容器，该映像通常用于生成工作负载和压力测试。在资源部分下，我们定义容器的资源要求和限制。我们请求 150Mi 内存，但内存的最大阈值固定为 128Mi 限制。

在容器内运行一条命令，告诉 K8s 创建 150 MB 的虚拟工作负载并挂起一秒钟。这是使用该容器映像执行压力测试的常见方法。

正如您从下面的屏幕截图中看到的，OOMKilled出现了输出。这意味着容器将因内存不足而被杀死。如果攻击者在行动时正在 Pod 内运行加密货币挖掘二进制文件OOMKilled，他们将被踢出，Pod 将返回到其原始状态（有效地删除挖掘二进制文件的任何实例），并且 Pod 将被删除。重新创建。

对在没有资源限制的情况下部署的 Pod 发出警报

您可能想知道是否必须描述每个 Pod 以确保它具有适当的资源限制。虽然您可以做到这一点，但它并不完全可扩展。当然，您可以将 Kubernetes 日志数据提取到 Prometheus 中并相应地报告。或者，如果您的 Kubernetes 集群中已安装 Falco，则可以应用以下 Falco 规则来检测在没有资源限制的情况下成功部署 pod 的实例。

- rule: Create Pod Without Resource Limits
  desc: Detect pod created without defined CPU and memory limits
  condition: kevt and pod and kcreate 
             and not ka.target.subresource in (resourcelimits)
  output: Pod started without CPU or memory limits (user=%ka.user.name pod=%ka.resp.name resource=%ka.target.resource ns=%ka.target.namespace images=%ka.req.pod.containers.image)
  priority: WARNING
  source: k8s_audit
  tags: [k8s, resource_limits]

- list: resourcelimits
  items: ["limits"]

请注意：根据您的 Kubernetes 工作负载的设置方式，此规则可能会针对有意在没有资源限制的情况下部署的合法 Pod 生成一些误/正警报检测。在这些情况下，您可能仍然需要微调此规则或实施一些例外，以最大限度地减少这些误报。然而，实施这样的规则可以显着增强您的监控能力，确保遵守 Kubernetes 中资源分配的最佳实践。

对开源的承诺

许多组织中 Kubernetes 缺乏强制的资源限制，这凸显了当前安全框架中的关键差距，凸显了提高认识的迫切需要。作为回应，我们将我们的发现贡献给了 Kubernetes 的 OWASP Top 10 框架，解决了无可否认的不安全工作负载配置的示例。我们的贡献因其价值而得到认可，已被适当纳入该框架。利用 OWASP 框架固有的开源特性，我们在 GitHub 上提交了Pull Request (PR)，提出了这一新颖的增强功能。这种为建立安全意识框架做出贡献的行为不仅增强了云原生安全性，还提高了其透明度，标志着迈向更加安全和感知的云原生生态系统的关键一步。

连接安全性和可扩展性

维护、监控和修改资源限制的复杂性常常会阻碍组织实施这些关键安全措施。考虑到开发环境的动态特性，应用程序需求可能会根据需求、功能推出和可扩展性要求而波动，因此团队可能将资源限制视为敏捷性的潜在障碍，这是可以理解的。然而，这种观点忽视了 Kubernetes 资源管理功能固有的灵活性，更重要的是，跨职能通信在优化这些设置的安全性和性能方面的关键作用。

灵活约束的艺术

Kubernetes 提供了一个用于管理资源约束的复杂模型，该模型不会从本质上抑制应用程序增长或操作灵活性。通过使用请求和限制，Kubernetes 允许指定为容器保证的最小资源（请求）和容器不能超过的最大上限（限制）。该模型提供了一个框架，应用程序可以在其中高效运行，并在预定义的范围内进行扩展，从而在不影响性能的情况下确保安全性。

有效利用该模型的关键在于采用持续评估和调整的方法。定期检查资源利用率指标可以提供有关应用程序如何针对其分配的资源执行的宝贵见解，从而确定调整约束以更好地满足实际需求的机会。这一迭代过程可确保资源限制保持相关性、支持应用程序需求并防止安全漏洞。

促进开放的沟通渠道

成功实施灵活资源限制的核心是开发、运营和安全团队之间的协作。开放的通信线路对于了解应用程序需求、分享对配置更改的潜在安全影响的见解以及就资源分配做出明智的决策至关重要。

鼓励透明和协作的文化可以揭开调整资源限制过程的神秘面纱，使其成为开发生命周期的常规部分，而不是一项艰巨的任务。定期的跨职能会议、资源利用率和绩效指标的共享仪表板以及统一的事件响应方法可以促进更加集成的团队活力。

简化维护、监控和修改

有了正确的工具和实践，就可以简化资源管理并将其集成到现有的开发工作流程中。自动化工具可以简化资源约束的部署和更新，而监控解决方案可以提供资源利用率和性能的实时可见性。

培训和授权，加上明确的指导方针和易于使用的工具，可以使调整资源限制成为一项简单的任务，同时支持安全态势和操作敏捷性。

结论

在 Kubernetes 中设置资源限制不仅仅是一种安全措施；这是在运营效率与强大安全性之间取得和谐平衡的关键战略。鉴于不断发展的云原生威胁，特别是加密货币挖矿攻击，这种做法变得更加重要，由于其省力、高回报的性质，这些攻击越来越成为攻击者的首选方法。

回顾2022 年云原生威胁报告，我们观察到一个值得注意的趋势。研究团队介绍了 TeamTNT，这是一个臭名昭著的云原生威胁参与者，以云和容器环境为目标，主要用于加密货币挖掘目的。他们的研究强调了令人震惊的经济失衡：攻击者每从被盗资源中赚取 1 美元，加密劫持就会让受害者损失惊人的 53 美元。这种差异凸显了此类攻击除了明显的安全漏洞之外的财务影响。

TeamTNT 的方法重申了为什么攻击者选择利用容器资源限制未定义或不受监控的环境。容器中资源使用缺乏限制或监督，为攻击者部署加密劫持恶意软件创造了一个开放的领域，利用不受监控的资源以牺牲受害者的利益为代价获取经济利益。

根据这些见解，很明显，在 Kubernetes 中实施资源约束和监控 Kubernetes 中的资源使用情况不仅是安全性和运营效率的最佳实践，而且也是安全性和运营效率的最佳实践。它们是抵御不断增长的经济枯竭加密货币挖矿攻击趋势的重要防御手段。随着 Kubernetes 的不断发展，这些实践的重要性只会不断提升。组织必须通过设置适当的资源限制和建立警惕的监控系统来主动适应，确保在面对此类潜在威胁时拥有安全、高效和财务健全的环境。