☰

Kubernetes 集群不应授予 CAPSYSADMIN 安全功能

tag-icon • tag-icon azure kubernetes aks
Kubernetes 集群不应授予 CAPSYSADMIN 安全功能

在我们的 AKS 中，在 Azure 安全中心发现与此相关的高严重性警报。

CAPSYSADMIN 的用途是什么？默认情况下，Pod 是否启用了此属性？因为我们没有在 AKS 中专门启用它？那么此警报的原因是什么？我们如何补救此警报？

答案1

解释：

CAPSYSADMIN 的用途是什么？

Linux 的功能本身就是一个广泛的话题，但简而言之，正如你所读到的这里：

从内核 2.2 开始，Linux 将传统上与超级用户相关的权限划分为不同的单元，称为能力，这些单元可以单独启用和禁用。能力是每个线程的属性。

换句话说，它们是不同的单元，可用于控制 Linux 操作系统中的权限升级。

并且CAP_SYS_ADMIN是其中之一，事实上它非常强大。它允许执行一系列系统管理操作，这些操作是普通用户无法执行的特权操作。有关完整列表，请参阅这个文件和Ctrl+f为CAP_SYS_ADMIN。

可以想象，从安全角度来看，除非绝对必要，否则不建议使用此功能。这符合最小特权原则这基本上意味着“仅向用户帐户或进程授予执行其预期功能所必需的权限”。

但让我们回到Kubernetes，安克萨斯和Azure因为你可能仍然好奇我上面提到的所有内容是如何适用的。

pod 是否默认启用此属性？

不，除非您在定义中明确启用它，否则不会Pod。因此，您收到的警告不是关于此功能被任何 pod 使用的事实，而是关于任何有权在 pod 中创建新 pod 的用户都可以使用此属性的可能性安克萨斯集群。换句话说，目前，CAP_SYS_ADMIN允许在您的安克萨斯簇。

下面你可以看到这样的一个示例Pod：

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-4
spec:
  containers:
  - name: sec-ctx-4
    image: gcr.io/google-samples/node-hello:1.0
    securityContext:
      capabilities:
        add: ["SYS_ADMIN"]

更多详情请参阅设置容器的功能官方 kubernetes 文档中的部分。

您可以轻松地自行测试，您会发现上述内容Pod将被成功创建，因为现在没有任何方式禁止它。

然后，您可以kubectl exec这样做Pod并验证它CAP_SYS_ADMIN确实使用了该功能。只需运行：

kubectl exec -it security-context-demo-4 -- /bin/bash

一旦连接到Pod您可以运行：

capsh --print | grep cap_sys_admin

您将会看到该cap_sys_admin功能已启用。

Pod您可以在不使用此功能的情况下检查相同内容：

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-4-1
spec:
  containers:
  - name: sec-ctx-4
    image: gcr.io/google-samples/node-hello:1.0

当你kubectl exec进入它时：

kubectl exec -ti security-context-demo-4-1 -- /bin/bash

并运行相同的命令：

capsh --print | grep cap_sys_admin

您会发现它默认并未启用。

解决方案：

虽然安克萨斯是一个托管的 kubernetes 服务，事实上微软已经为你处理了很多安全层，在管理你的安克萨斯集群。例如，您可以自行执行一些进一步的操作，以使其更加安全。

好消息是，您不会完全独自完成这些任务，并且我们为您提供了一系列现成的解决方案，您可以在 Azure 环境中简单地应用它们。

其中之一是Azure 安全中心，这减轻了您自行检测当前设置中新潜在威胁的负担。正如您所读到的这里建议Kubernetes 集群不应授予 CAPSYSADMIN 安全功能是的一部分强化 Kubernetes 集群的新建议这些仍处于预览阶段，因此您可能之前没有见过它们：

强化 Kubernetes 集群的新建议（预览版）

以下建议可帮助您进一步强化 Kubernetes 集群

  • Kubernetes 集群不应使用默认命名空间 - 为防止对 ConfigMap、Pod、Secret、Service 和 ServiceAccount 资源类型的未经授权的访问，请防止在 Kubernetes 集群中使用默认命名空间。
  • Kubernetes 集群应禁用自动挂载 API 凭证 - 为防止可能受到损害的 Pod 资源针对 Kubernetes 集群运行 API 命令，请禁用自动挂载 API 凭据。
  • Kubernetes 集群不应授予 CAPSYSADMIN 安全功能

那么出现此警报的原因是什么？

鉴于上述情况，可以回答这个问题：通过减少容器的潜在攻击面，可以提高 kubernetes 集群的安全性。但是否遵循此建议完全取决于您自己。

威胁检测部分就讲这么多。那么补救部分呢？

我们该如何补救这个警报？

Azure 策略就是答案。你可能已经听说过它们了。幸运的是，为了补救这一特定威胁，你不必编写自己的自定义策略，因为 Azure 提供了Azure Kubernetes 服务的内置策略定义你可以简单地利用它们安克萨斯簇。

在第一栏中，您将看到直接链接到您的 Azure 门户，它将带您进入策略定义页面，您可以在其中检查其详细信息并将其分配给特定的订阅和资源组：

在此处输入图片描述

在此处输入图片描述

更多详细信息请参阅：

其他有用链接：

相关内容