Kubernetes安全解析：为何无需过度担忧allowPrivilegeEscalation

本文深入剖析Kubernetes中allowPrivilegeEscalation安全选项的本质，澄清常见误解，并通过实际漏洞利用演示展示其真实作用机制，帮助开发者和安全团队正确评估其安全价值。

停止为’allowPrivilegeEscalation’担忧

Kubernetes安全上下文允许您在Pod或容器级别配置安全选项。虽然某些参数已被广泛理解，但其他一些可能更加晦涩难懂。在本文中，我们将揭开关于allowPrivilegeEscalation选项的迷思。

TL;DR——allowPrivilegeEscalation只是一个安全加固选项，仅此而已。 如果您能够将其关闭作为快速安全改进，那么请务必这样做！否则，它本身并不会导致您的系统被黑客入侵。如果您没有明确禁用它，您可能仍然是安全的。

什么是’allowPrivilegeEscalation’？

询问任何安全工程师是否应该允许您的应用程序"提升权限"，您很可能会得到茫然的眼神、困惑的表情，甚至可能有人质疑您的理智。

“提升他们的权限”？

幸运的是，这里存在一个误解。当您询问：

“如果我没有明确将’allowPrivilegeEscalation’标志设置为false，这重要吗？”

…您的安全工程师听到的可能是：

“如果我不安全的Java应用程序能够逃逸出它的容器并在我们的集群中像1999年一样跳舞，这可以吗？”

好消息！您们至少有一个共同点：您们都没有丝毫了解allowPrivilegeEscalation标志的含义——说实话，谁能责怪您们呢？

关于’allowPrivilegeEscalation’的常见误解

让我们开门见山：虽然关闭allowPrivilegeEscalation可能有价值，但它只是一个安全加固设置，您可以利用它来增加容器化环境的安全性。

具体来说，如果您将allowPrivilegeEscalation保持为true（其默认值）：

  • 它不会神奇地允许容器中的非特权进程将其权限提升到root
  • 它不会允许在容器内运行的进程逃逸出容器
  • 它不会允许Pod在集群内执行任何类型的权限提升

“但是Christophe，“我听到您问，“那它到底做什么呢？“让我们首先看看它能防止的攻击类型示例，然后深入了解容器运行时如何实现它。

‘allowPrivilegeEscalation’的实际应用

让我们重现一个场景：漏洞允许非特权进程在容器内将其权限提升到root。这可能发生在内核级漏洞中，如DirtyCow、DirtyPipe或OverlayFS中的CVE-2023-0386。我们也可以测试一个更简单（但同样现实）的场景：滥用具有setuid位设置的root所有二进制文件。

首先，让我们重现这个场景。然后，我们将看到关闭allowPrivilegeEscalation如何防止成功利用。

我们将使用以下程序，它使用setreuid（意为"设置真实和有效用户ID”）和setregid来有效地将权限提升到root。按照设计，这仅在二进制文件由root所有且设置了setuid位时才有效：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>

int main(void) {
    // 提升到root
    setreuid(0, 0); 
    setregid(0, 0);

    // 生成shell
    char* const argv[] = {"/bin/bash", NULL};
    char* const environ[] = {NULL};
    execve("/bin/bash", argv, environ);
}

1
2
3

gcc escalate.c -Wall -o /tmp/escalate
sudo chown root:root /tmp/escalate
sudo chmod +s /tmp/escalate

我们现在可以使用非特权用户来确认这个易受攻击的程序允许我们将权限提升到root：

1
2
3

$ /tmp/escalate
# id
uid=0(root) gid=0(root) groups=0(root),1000(user)

以下Dockerfile模拟了一个Alpine容器镜像，该镜像以非特权用户身份运行应用程序，并在其中包含易受攻击的二进制文件：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

FROM alpine:3.20 AS builder
WORKDIR /build
RUN cat > escalate.c <<EOF
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <errno.h>

int main(void) {
    // 提升到root
    setreuid(0, 0); 
    setregid(0, 0);

    // 生成shell
    char* const argv[] = {"/bin/bash", NULL};
    char* const environ[] = {"PATH=/bin:/sbin:/usr/bin:/usr/sbin", NULL};
    if (-1 == execve("/bin/bash", argv, environ)) {
        printf("Unable to execve /bin/bash, errno %d\n", errno);
    }
}
EOF
RUN cat /build/escalate.c
RUN apk add --no-cache gcc musl-dev
RUN gcc escalate.c -Wall -o escalate

FROM alpine:3.20 AS runner
WORKDIR /app
COPY --from=builder /build/escalate ./escalate
RUN chown root:root ./escalate && chmod +s ./escalate
RUN adduser app-user --uid 1000 --system --disabled-password --no-create-home
RUN apk add bash
USER app-user
ENTRYPOINT ["sh", "-c", "echo Application running && sleep infinity"]

让我们构建它并在Kubernetes集群中运行，明确打开allowPrivilegeEscalation（即使这是默认值）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

# 构建镜像
docker build . -t my-app:0.1

# 创建kind集群并在其中运行镜像
kind create cluster
kind load docker-image my-app:0.1

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 1000
  containers:
  - name: my-app
    image: my-app:0.1
    securityContext:
      allowPrivilegeEscalation: true
EOF

如预期所示，我们能够利用漏洞将权限提升到root：

1
2
3

$ kubectl exec -it my-app -- /app/escalate
# id
uid=0(root) gid=0(root)

然而，如果我们以allowPrivilegeEscalation设置为false的方式启动Pod，我们会得到：

1
2
3

$ kubectl exec -it my-app -- /app/escalate
$ id
uid=1000(app-user) gid=1000(app-user)

发生了什么？对setreuid和setregid的调用失败了。如果我们在"漏洞利用"代码中添加错误处理，错误会更加明确：

1
2
3
4
5
6
7

// 提升到root
if (setreuid(0, 0) != 0) {
    printf("setreuid(0, 0) failed: %s\n", strerror(errno));
}
if (setregid(0, 0) != 0) {
    printf("setregid(0, 0) failed: %s\n", strerror(errno));
}

1
2
3

$ kubectl exec -it my-app -- /app/escalate
setreuid(0, 0) failed: Operation not permitted
setregid(0, 0) failed: Operation not permitted

‘allowPrivilegeEscalation’的工作原理

根据Kubernetes文档：

AllowPrivilegeEscalation控制进程是否可以获得比其父进程更多的权限。这个布尔值直接控制是否将在容器进程上设置no_new_privs标志。

no_new_privs标志是3.5内核（2012年发布）中引入的内核功能。启用后，它确保没有子进程可以获得比其父进程更多的权限。

我们可以通过手动设置no_new_privs来确认这种行为，然后尝试执行权限提升，使用一个小的实用程序：

  • 使用prctl系统调用设置no_new_privs
  • 创建一个新的sh进程，该进程将"安全"地防御权限提升漏洞

我们需要第二个步骤，因为新设置的标志不会追溯适用于我们已经运行的shell进程。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

#include <string.h>
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <errno.h>
#include <sys/prctl.h>

int main(void) {
    // 设置no_new_privs
    if (-1 == prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)) {
        printf("Could not set prctl: %s\n", strerror(errno));
    }

    // 生成shell
    char* const argv[] = {"/bin/sh", NULL};
    char* const environ[] = {"PATH=/bin:/sbin:/usr/bin:/usr/sbin", NULL};
    if (-1 == execve("/bin/sh", argv, environ)) {
        printf("Unable to execve /bin/sh, errno %d\n", errno);
    }
}

当我们编译并运行这个实用程序时，我们看到它正确地在我们新的shell进程中设置了no_new_privs标志，正如我们可以通过读取/proc/self/status看到的那样：

1
2

$ cat /proc/self/status | grep NoNewPrivs
NoNewPrivs:    1

如果我们现在再次尝试权限提升，请注意它现在被阻止了——就像我们将allowPrivilegeEscalation设置为false时一样：

1
2
3

$ /tmp/escalate 
setreuid(0, 0) failed: Operation not permitted
setregid(0, 0) failed: Operation not permitted

这个小过程正是容器运行时在创建新的容器化进程时所做的事情。例如，以下是来自runc的容器初始化代码，该代码被大多数容器运行时使用，如containerd、CRI-O和Docker：

1
2
3
4
5
6

// 如果NoNewPrivileges为true（直接由allowPrivilegeEscalation控制），则调用prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) [编者注]
if l.config.NoNewPrivileges {
    if err := unix.Prctl(unix.PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0); err != nil {
        return &os.SyscallError{Syscall: "prctl(SET_NO_NEW_PRIVS)", Err: err}
    }
}

您可以看到它执行的过程与我们完全一样：

  1. 检查NoNewPrivileges是否为true（这直接由我们的Kubernetes安全上下文allowPrivilegeEscalation字段控制）
  2. 如果是这种情况，则在创建容器进程之前打开no_new_privs

那么问题是什么？

安全——就像大多数试图处理系统性故障的学科一样，是关于构建不同层次以确保单个缺陷不会变成数据泄露。

在这种情况下：是的，明确关闭allowPrivilegeEscalation是一种合理的安全加固实践。关闭它可以大大增加信心，即攻击者入侵非特权应用程序后无法在容器内将其权限提升到root，从而降低了利用需要root权限的进一步漏洞的风险。

如果您没有在工作负载上关闭它，这很糟糕吗？可能不是。将其视为您尚未启用的（又一个）加固机制。它不是会导致您被黑客入侵的原因。除非您是一个成熟的安全团队，否则您可能最好首先专注于容器安全路线图中更高价值的项目（请参阅我在KubeCon EU 2024上的演讲和文章，了解一些威胁导向的起点建议）。

也就是说，这不是您应该忽略的设置；确保它成为您容器安全路线图的一部分。

常见问题解答

‘allowPrivilegeEscalation’的默认值是什么？

默认为true。请参阅相关代码和相关问题，以在文档中使其更清晰。

如果我的工作负载在容器内以root身份运行，关闭’allowPrivilegeEscalation’有意义吗？

不，完全没有意义。如果您的工作负载以root身份运行，它们在容器内无法实现进一步的权限提升。

如果我的工作负载以"特权"模式运行或具有CAP_SYS_ADMIN能力，关闭’allowPrivilegeEscalation’有意义吗？

不，没有意义。事实上，您甚至无法这样做——API服务器将拒绝您的请求（请参阅相关验证代码）：

1

The Pod "my-app" is invalid: spec.containers[0].securityContext: Invalid value: cannot set `allowPrivilegeEscalation` to false and `privileged` to true

关闭’allowPrivilegeEscalation’是否能防止容器内的所有类型的权限提升？

不能。例如，如果攻击者利用允许他们提升权限的内核缺陷，它将无济于事。也就是说，它应该阻止所有通过利用setuid/setgid工作的权限提升。

‘allowPrivilegeEscalation’和’privileged’之间有任何联系吗？

没有。关闭allowPrivilegeEscalation是一种安全加固机制。如果您将其保留为默认值，容器内的进程仍然无法轻易提升其权限，也无法逃逸出容器。

以特权模式运行工作负载会使它们就像直接作为主机上的进程一样运行，使得容器逃逸在设计中变得简单。

如果攻击者设法在容器内提升到root，这不是世界末日吗？

又是一个误解，有时由驱动安全行业的FUD（恐惧、不确定性和怀疑）愉快地传播。以root身份在容器内运行的进程无法轻易逃逸到容器外部。它必须利用另一个漏洞或错误配置。

结论

希望本文提供了关于’allowPrivilegeEscalation’是什么、不是什么以及使用它的明显好处的更深入概述。当我第一次发现它时，我自己也感到困惑，而且由于它的不幸命名，似乎许多人对此感到困惑。

感谢您的阅读，让我们在Hacker News、Twitter或Mastodon上继续讨论！

感谢我的同事Rory McCune审阅了这篇文章。

comments powered by Disqus
© 2020 - 2026 qife
使用 Hugo 构建
主题 Stack 由 Jimmy 设计
本站总访问量次 本站访客数人次