您现在的位置是：首页 >技术杂谈 >使用 Kubernetes 运行 non-root .NET 容器网站首页技术杂谈

翻译自 Richard Lander 的博客

Rootless 或 non-root Linux 容器一直是 .NET 容器团队最需要的功能。我们最近宣布了所有 .NET 8 容器镜像都可以通过一行代码配置为 non-root 用户。今天的文章将介绍如何使用 Kubernetes 处理 non-root 托管。

您可以尝试使用我们的 non-root Kubernetes 示例在集群上托管 non-root 容器。它是我们正在处理的一组更大的 Kubernetes 示例的一部分。

runAsNonRoot

我们将要讨论的大部分内容都与 Kubernetes 清单的 SecurityContext 部分有关。它包含 Kubernetes 应用的安全配置。

spec:      containers:      - name: aspnetapp        image: dotnetnonroot.azurecr.io/aspnetapp        securityContext:          runAsNonRoot: true

此 securityContext 对象验证容器将以 non-root 用户运行。

runAsNonRoot 测试用户（通过 UID）是 non-root 用户（> 0），否则 pod 创建将失败。Kubernetes 仅为该测试读取容器镜像元数据。它不会读取/etc/passwd，因为这需要启动容器（这违背了测试的目的）。这意味着 USER（在 Dockerfile 中）必须由 UID 设置。如果 USER 按名称设置，将会失败。

我们可以使用 docker inspect 模拟相同的测试。

% docker inspect dotnetnonroot.azurecr.io/aspnetapp -f "{{.Config.User}}"64198

我们的示例镜像通过 UID 设置用户。但是，whoami 仍会将用户报告为应用程序。

runAsUser 是一个相关的设置，尽管在上面的示例中没有使用。只有当容器镜像未设置 USER、通过名称而非 UID 进行设置，或者其他情况不需要时，才应该使用 runAsUser。我们已经让使用新应用程序用户作为 UID 变得非常容易，这样 .NET 应用程序应该会不再需要 runAsUser了。

USER 最佳实践

我们建议在 Dockerfile 中设置 USER 时使用以下模式。

USER $APP_UID

USER 指令通常放在 ENTRYPOINT 之前，尽管顺序无关紧要。此模式导致 USER 被设置为 UID，同时避免在 Dockerfile 中使用幻数。环境变量已经定义了 .NET 镜像声明的 UID 值。

您可以看到 .NET 镜像中设置的环境变量。​​​​​​​

% docker run mcr.microsoft.com/dotnet/runtime-deps:8.0-preview bash -c "export | grep UID"declare -x APP_UID="64198"

non-root 示例根据此模式通过 UID 设置用户。因此，它适用于 runAsNonRoot。

non-root 托管

让我们看看使用 non-root Kubernetes 示例进行 non-root 容器托管的体验。

我们正在为本地集群使用 minikube，但任何兼容 Kubernetes 的环境都应该能很好地与 kubectl 配合使用。​​​​​​​

$ kubectl apply -f https://raw.githubusercontent.com/dotnet/dotnet-docker/main/samples/kubernetes/non-root/non-root.yamldeployment.apps/dotnet-non-root createdservice/dotnet-non-root created$ kubectl get poNAME                           READY   STATUS    RESTARTS   AGEdotnet-non-root-68f4cd45c-687zp   1/1     Running   0          13s

该应用程序正在运行。让我们检查一下用户。​​​​​​​

$ kubectl exec dotnet-non-root-68f4cd45c-687zp -- whoamiapp

我们也可以在应用程序上调用一个端点。首先，我们需要创建一个代理来连接它。

% kubectl port-forward service/dotnet-non-root 8080

我们现在可以调用端点，它也将用户报告为 app。​​​​​​​

% curl http://localhost:8080/Environment{"runtimeVersion":".NET 8.0.0-preview.3.23174.8","osVersion":"Linux 5.15.49-linuxkit #1 SMP PREEMPT Tue Sep 13 07:51:32 UTC 2022","osArchitecture":"Arm64","user":"app","processorCount":4,"totalAvailableMemoryBytes":4124512256,"memoryLimit":0,"memoryUsage":35004416}

删除资源。​​​​​​​

$ kubectl delete -f https://raw.githubusercontent.com/dotnet/dotnet-docker/main/samples/kubernetes/non-root/non-root.yamldeployment.apps "dotnet-non-root" deletedservice "dotnet-non-root" deleted

在撰写本文时，官方示例尚未移动到使用 non-root 用户。当我们将示例移动到 .NET 8 时，可能 .NET 8 RC1，我们会这样做。可以使用 aspnetapp 镜像来演示当 runAsNonRoot 与使用 root 的镜像一起使用时会发生什么。它应该失败，对吧？稍微更改一下清单，让我们从没有 securityContext 部分开始。​​​​​​​

  spec:      containers:      - name: aspnetapp

检查一下用户。​​​​​​​

$ kubectl apply -f non-root.yamldeployment.apps/dotnet-non-root createdservice/dotnet-non-root created$ kubectl get poNAME                            READY   STATUS    RESTARTS   AGEdotnet-non-root-85768f6c55-pb5gh   1/1     Running   0          1s$ kubectl exec dotnet-non-root-85768f6c55-pb5gh -- whoamiroot

不出所料。现在，把 runAsNonRoot 加回来。​​​​​​​

spec:      containers:      - name: aspnetapp        image: mcr.microsoft.com/dotnet/samples:aspnetapp        securityContext:          allowPrivilegeEscalation: false          runAsNonRoot: true​​​​​​​

$ kubectl apply -f non-root.yamldeployment.apps/dotnet-non-root createdservice/dotnet-non-root created$ kubectl get poNAME                            READY   STATUS                       RESTARTS   AGEdotnet-non-root-6df9cb77d8-74t96   0/1     CreateContainerConfigError   0          5s

失败了，但就是我们想要的。我们可以更多地了解下原因。​​​​​​​

$ kubectl describe po | grep Error      Reason:       CreateContainerConfigError  Warning  Failed     7s (x2 over 8s)  kubelet            Error: container has runAsNonRoot and image will run as root (pod: "dotnet-non-root-6df9cb77d8-74t96_default(d4df0889-4a69-481a-adc4-56f41fb41c63)", container: aspnetapp)

我们可以尝试 kubectl exec 到 pod，但它会失败。这表明 Kubernetes 阻止了容器的创建（如错误状态所示）。​​​​​​​

$ kubectl exec dotnet-non-root-6df9cb77d8-74t96 -- whoamierror: unable to upgrade connection: container not found ("aspnetapp")

dotnet-monitor

dotnet-monitor 是一种诊断工具，用于从正在运行的应用程序中捕获诊断工件。我们为其提供了一个 dotnet/monitor 容器镜像。它适用于 non-root 主机。

hello-dotnet Kubernetes 示例演示了以 non-root 用户身份运行的 ASP.NET 和 dotnet-monitor。它还继续演示如何在云端和本地收集 Prometheus 指标数据。

您可以通过几个简单的配置更改在 Kubernetes 中切换到 non-root 托管。您的应用程序将更加安全，对攻击也更具弹性。这种方法还使应用程序符合 Kubernetes Pod 强化最佳实践。这是一项小变革，但对深度防御有着巨大影响。

希望我们的容器安全计划能够让整个 .NET 容器生态系统都转向 non-root 托管，我们致力于使云中的 .NET 应用程序高效且安全。

 点我前往原博客~