停止对’allowPrivilegeEscalation’的过度担忧
Kubernetes安全上下文允许您在pod或容器级别配置安全选项。虽然某些参数已被充分理解,但其他参数可能更加晦涩难懂。本文将揭穿关于allowPrivilegeEscalation选项的迷思。
TL;DR - allowPrivilegeEscalation是一个安全加固选项,仅此而已。如果您能将其关闭作为快速安全措施,请务必这样做!否则,它本身不会导致系统被入侵。如果您没有显式禁用它,可能也没问题。
什么是’allowPrivilegeEscalation’?
询问任何安全工程师是否应允许您的应用程序"提升权限",您可能会得到茫然的眼神、困惑的表情,甚至可能被质疑您的理智。
好消息是:这里存在误解。当您问: “如果我没有显式将’allowPrivilegeEscalation’标志设为false有关系吗?” …您的安全工程师听到的是: “如果我不安全的Java应用能逃逸容器并在集群中肆意妄为,这没问题吗?”
关于’allowPrivilegeEscalation’的常见误解
开门见山:虽然关闭allowPrivilegeEscalation很有价值,但它只是一个您可以利用来增强容器化环境安全的安全加固设置。
具体来说,如果您将allowPrivilegeEscalation保留为true(其默认值):
- 它不会神奇地允许容器中的非特权进程将其权限提升至root
- 它不会允许容器内运行的进程逃逸容器
- 它不会允许pod在集群内执行任何类型的权限提升
‘allowPrivilegeEscalation’实战
让我们重现一个场景:漏洞允许非特权进程在容器内将其权限提升至root。这可能发生在DirtyCow、DirtyPipe或OverlayFS中的CVE-2023-0386等内核级漏洞中。
我们使用以下程序,它使用setreuid和setregid有效地将权限提升至root:
|
|
当我们在Kubernetes集群中运行此容器并显式打开allowPrivilegeEscalation(尽管这是默认值)时,我们能够利用漏洞将权限提升至root。但如果我们将allowPrivilegeEscalation设为false,setreuid和setregid调用将失败。
‘allowPrivilegeEscalation’工作原理
根据Kubernetes文档:
AllowPrivilegeEscalation控制进程是否可以获得比其父进程更多的权限。此布尔值直接控制是否会在容器进程上设置no_new_privs标志。
no_new_privs标志是2012年发布的Linux 3.5内核中引入的功能。启用后,它确保没有子进程可以获得比其父进程更多的权限。
容器运行时(如runc)在创建新容器化进程时会执行此操作:
|
|
结论
安全就像大多数试图处理系统性故障的学科一样,是关于构建不同层次以确保单个缺陷不会变成数据泄露。
在此背景下:是的,显式关闭allowPrivilegeEscalation是一种合理的安全加固实践。关闭它可以大大提高攻击者入侵非特权应用程序后无法将其权限提升至容器内root的信心,从而降低利用需要root权限的进一步漏洞的风险。
如果您没有在工作负载上关闭它,这很糟糕吗?可能不会。将其视为您尚未启用的(又一个)加固机制。除非您是一个成熟的安全团队,否则您最好首先专注于容器安全路线图中更有价值的项目。
常见问题解答
‘allowPrivilegeEscalation’的默认值是什么? 默认为true。
如果我的工作负载在容器内以root身份运行,关闭’allowPrivilegeEscalation’有意义吗? 没有意义。如果工作负载以root身份运行,它们在容器内无法实现进一步的权限提升。
关闭’allowPrivilegeEscalation’是否能防止容器内的所有权限提升? 不能。例如,如果攻击者利用允许他们提升权限的内核漏洞,它将无济于事。也就是说,它应该阻止所有通过利用setuid/setgid工作的权限提升。