Kubernetes 集群不应授予 CAPSYSADMIN 安全功能
Vow*_*eee 0 azure kubernetes aks
在我们的 AKS 中，在 Azure 安全中心发现了与此相关的高严重性警报。
CAPSYSADMIN 的用途是什么？默认情况下 Pod 是否启用此属性？因为我们没有在 AKS 中专门启用它？那么这个警报的原因是什么？我们如何修复此警报？
解释：
\n\n\nCAPSYSADMIN 的用途是什么？
\n
Linux 功能本身是一个广泛的话题，但简而言之，您可以在此处阅读：
\n\n\n从内核 2.2 开始，Linux 将传统上与超级用户相关的权限划分为不同的单元，称为功能，可以独立启用和禁用。能力是每个线程的属性。
\n
换句话说，它们是不同的单元，可用于控制 Linux 操作系统中的权限升级。
\n并且CAP_SYS_ADMIN是其中之一，事实上它是非常强大的。它允许执行一系列系统管理操作，以及普通用户无法执行的特权操作。有关完整列表，请参阅本文档和Ctrl+ 。fCAP_SYS_ADMIN
正如您可以想象的那样，从安全角度来看，不建议使用此功能，除非绝对必要。这符合最小权限原则，该原则基本上意味着“仅向用户帐户或进程授予执行其预期功能所必需的权限”。
\n但让我们回到kubernetes、AKS和Azure的背景，因为您可能仍然好奇我上面提到的所有内容如何适合它们。
\n\n\n默认情况下 Pod 是否启用此属性？
\n
不，除非您在定义中明确启用它，否则不会Pod。因此，您收到的警告并不是关于您的任何 pod 使用此功能的事实，而是关于有权在 AKS 集群中创建新 pod 的任何用户使用此属性的可能性。换句话说，目前允许在AKSCAP_SYS_ADMIN集群上创建利用功能的 pod 。
您可以在下面看到这样的示例Pod：
apiVersion: v1\nkind: Pod\nmetadata:\n name: security-context-demo-4\nspec:\n containers:\n - name: sec-ctx-4\n image: gcr.io/google-samples/node-hello:1.0\n securityContext:\n capabilities:\n add: ["SYS_ADMIN"]\n有关更多详细信息，请参阅官方 kubernetes 文档中的为容器设置功能部分。
\n您可以轻松地自行测试它，您将看到上述内容Pod将成功创建，因为现在不以任何方式禁止它。
然后，您可以kubectl exec验证它确实使用了该功能Pod。CAP_SYS_ADMIN只需运行：
kubectl exec -it security-context-demo-4 -- /bin/bash\n连接到后Pod您可以运行：
capsh --print | grep cap_sys_admin\n您将看到该cap_sys_admin功能已启用。
Pod您可以在不使用此功能的a 中检查相同内容：
apiVersion: v1\nkind: Pod\nmetadata:\n name: security-context-demo-4-1\nspec:\n containers:\n - name: sec-ctx-4\n image: gcr.io/google-samples/node-hello:1.0\n当你kubectl exec进入其中时：
kubectl exec -ti security-context-demo-4-1 -- /bin/bash\n并运行相同的命令：
\ncapsh --print | grep cap_sys_admin\n您会看到它默认情况下未启用。
\n解决方案：
\n尽管AKS是一项托管的 kubernetes 服务，并且事实上 Microsoft 已经为您处理了许多安全层，但在管理AKS集群时，您仍然被授予相当广泛的职责。例如，您可以自行执行一些进一步的操作，以使其更加安全。
\n好消息是，您不会完全独自完成此类任务，并且我们为您提供了一堆现成的解决方案，您可以轻松地将它们应用到 Azure 环境中。
\n其中之一是Azure 安全中心，它减轻了您自行检测当前设置中新的潜在威胁的负担。正如您可以在此处阅读的，建议Kubernetes 集群不应授予 CAPSYSADMIN 安全功能是强化 Kubernetes 集群的新建议的一部分，该建议仍处于预览阶段，因此您之前可能没有见过它们：
\n\n\n强化 Kubernetes 集群的新建议（预览版）
\n以下建议可让您进一步强化\nKubernetes 集群
\n\n
\n- Kubernetes 集群不应使用默认命名空间 - 为了防止对 ConfigMap、Pod、Secret、Service 和 ServiceAccount 资源类型进行未经授权的访问，请阻止在 Kubernetes 集群中使用默认命名空间。
\n- Kubernetes 集群应禁用自动挂载 API 凭据 - 为了防止可能受到威胁的 Pod 资源针对 Kubernetes 集群运行 API 命令，请禁用自动挂载 API 凭据。
\n- Kubernetes 集群不应授予 CAPSYSADMIN 安全功能
\n
\n\n那么这个警报的原因是什么？
\n
鉴于上述情况，这个问题可以得到回答：让您有可能通过减少容器的潜在攻击面来提高 Kubernetes 集群的安全性。但是否决定遵循此建议完全取决于您。
\n威胁检测部分就这么多。修复部分呢？
\n\n\n我们如何修复此警报？
\n
Azure 策略就是这个问题的答案。您可能已经听说过它们。幸运的是，要修复这种特定威胁，您不必编写自己的自定义策略，因为 Azure为 Azure Kubernetes 服务提供了内置策略定义，您可以简单地在AKS集群上利用它们。
\n在第一列中，您将获得到Azure 门户的直接链接，该链接将带您进入策略定义页面，您可以在其中检查其详细信息以及可以将其分配给特定的订阅和资源组：
\n
更多详情请参考：
\n\n其他有用的链接：
\n- \n
- 强化 Kubernetes 集群的新建议（预览版） \n
- 适用于 kubernetes 的 Azure Policy 内置策略定义的完整列表 \n
- Azure Kubernetes 服务的 Azure Policy 内置定义 \n
- 什么是 Azure 策略？ \n
- 功能(7) \xe2\x80\x94 Linux 手册页 \n
| 归档时间： |
|
| 查看次数： |
2030 次 |
| 最近记录： |