{"id":45310,"date":"2023-04-17T10:48:59","date_gmt":"2023-04-17T17:48:59","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/dotnet\/?p=45310"},"modified":"2024-12-13T14:16:23","modified_gmt":"2024-12-13T22:16:23","slug":"running-nonroot-kubernetes-with-dotnet","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/running-nonroot-kubernetes-with-dotnet\/","title":{"rendered":"Running non-root .NET containers with Kubernetes"},"content":{"rendered":"
\n

This post was updated on April 25, 2024<\/strong> to reflect the latest releases.<\/p>\n<\/blockquote>\n

Rootless or non-root Linux containers have been the most requested feature for the .NET container team. We recently announced that all .NET 8 container images will be configurable as non-root<\/a> with a single line of code. This change is a welcome improvement in security posture. In that last post, I promised a follow-up on how to approach non-root hosting with Kubernetes. That’s what we’ll cover today.<\/p>\n

You can try hosting a non-root container on your cluster with our non-root Kubernetes sample<\/a>. It is part of a larger set of Kubernetes samples<\/a> we’re working on.<\/p>\n

This post will help you follow Kubernetes “Restricted” hardening best practices<\/a>. Non-root hosting is a key requirement of the guidance.<\/p>\n

runAsNonRoot<\/code><\/h2>\n

Most of what we’ll be discussing relates to the SecurityContext<\/code><\/a> section of a Kubernetes manifest. It holds security configuration that is applied by Kubernetes.<\/p>\n

    spec:\n      securityContext:\n        runAsNonRoot: true\n      containers:\n      - name: aspnetapp\n        image: mcr.microsoft.com\/dotnet\/samples:aspnetapp-chiseled\n        ports:\n        - containerPort: 8080<\/code><\/pre>\n
This securityContext<\/code> object in this example validates that all the containers in the pod will be run with a non-root user. It really is as simple as that.<\/p>\n
You can see this in a broader context in non-root.yaml<\/a>.<\/p>\n
runAsNonRoot<\/code> tests that the user (via UID) is a non-root user (> 0<\/code>), otherwise pod creation will fail. Kubernetes only reads container image metadata for this test.  It doesn’t read \/etc\/passwd<\/code> since that would require launching the container (which defeats the purpose of the test). That means that USER<\/code> (in a Dockerfile) must be set by UID. It will fail if USER<\/code> is set by name.<\/p>\n
We can simulate this same test with docker inspect<\/code>.<\/p>\n
$ docker inspect mcr.microsoft.com\/dotnet\/samples:aspnetapp-chiseled -f \"{{.Config.User}}\"\n1654<\/code><\/pre>\n
As you can see, our sample image sets the user by UID. However, whoami<\/code> will still report the user as app<\/code>, since it is natural for it is running on a live operating system.<\/p>\n
runAsUser<\/code> is a related setting, although not used in the example above. runAsUser<\/code> should only be used if USER<\/code> in the container image is unset, set by name rather than UID, or otherwise needs to be changed. We’ve made it very easy to use the new app<\/code> user as a UID, such that runAsUser<\/code> should not be commonly needed for .NET apps.<\/p>\n
USER<\/code> best practices<\/h2>\n
We recommend using the following pattern for setting USER<\/code> in a Dockerfile.<\/p>\n
USER $APP_UID<\/code><\/pre>\n
The USER<\/code> instruction is often placed just before the ENTRYPOINT<\/code>, although the order doesn’t matter.<\/p>\n
This pattern results in the USER<\/code> being set as a UID, while avoiding magic numbers in your Dockerfile. The environment variable already defines the UID value as declared by the .NET image.<\/p>\n
You can see the environment variable set in .NET images.<\/p>\n
$ docker run --rm -u app mcr.microsoft.com\/dotnet\/runtime-deps:8.0 bash -c \"echo \\$APP_UID\"\n1654<\/code><\/pre>\n
Our sample Dockerfile set the user by UID<\/a>. As a result, it works well with runAsNonRoot<\/code><\/a>.<\/p>\n
Non-root hosting in action<\/h2>\n
Let’s take a look at the experience of non-root container hosting using our non-root Kubernetes sample<\/a>.<\/p>\n
I’m using Docker Desktop<\/a> for my local cluster, but any Kubernetes-compatible environment should work well with kubectl<\/a>.<\/p>\n
$ kubectl apply -f https:\/\/raw.githubusercontent.com\/dotnet\/dotnet-docker\/main\/samples\/kubernetes\/non-root\/non-root.yaml\ndeployment.apps\/dotnet-non-root created\nservice\/dotnet-non-root created\n$ kubectl get po\nNAME                           READY   STATUS    RESTARTS   AGE\ndotnet-non-root-5b7fc97df7-476s9   1\/1     Running   0          13s<\/code><\/pre>\n
The pod was correctly deployed, since the status us reported as Running<\/code>.<\/p>\n
kubectl<\/code> reports that runAsNonRoot<\/code> was set.<\/p>\n
$ kubectl get pod dotnet-non-root-5b7fc97df7-476s9 -o jsonpath=\"{.spec.securityContext}\" \n{\"runAsNonRoot\":true}<\/code><\/pre>\n
Now onto using the app, first by creating a proxy to the service.<\/p>\n
$ kubectl port-forward service\/dotnet-non-root 8080\nForwarding from 127.0.0.1:8080 -> 8080\nForwarding from [::1]:8080 -> 8080<\/code><\/pre>\n
We can now call the endpoint, which also reports the user as app<\/code>.<\/p>\n
% curl http:\/\/localhost:8080\/Environment\n{\"runtimeVersion\":\".NET 8.0.4\",\"osVersion\":\"Ubuntu 22.04.4 LTS\",\"osArchitecture\":\"Arm64\",\"user\":\"app\",\"processorCount\":8,\"totalAvailableMemoryBytes\":4113563648,\"memoryLimit\":0,\"memoryUsage\":34082816,\"hostName\":\"dotnet-non-root-8467576789-9dj8g\"}<\/code><\/pre>\n
user<\/code> is displayed as app<\/code>, as expected.<\/p>\n
If we tried to deploy an image that used root<\/code> as the user, with runAsNonRoot<\/code> set to true<\/code>, we would see the following error.<\/p>\n
$ kubectl apply -f non-root.yaml\ndeployment.apps\/dotnet-non-root created\nservice\/dotnet-non-root created\n$ kubectl get po\nNAME                            READY   STATUS                       RESTARTS   AGE\ndotnet-non-root-6df9cb77d8-74t96   0\/1     CreateContainerConfigError   0          5s<\/code><\/pre>\n
With a bit of digging, we’d find the reason.<\/p>\n
$ kubectl describe po | grep Error\n      Reason:       CreateContainerConfigError\n  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)<\/code><\/pre>\n
With the tour over, we can delete the resources.<\/p>\n
$ kubectl delete -f https:\/\/raw.githubusercontent.com\/dotnet\/dotnet-docker\/main\/samples\/kubernetes\/non-root\/non-root.yaml\ndeployment.apps \"dotnet-non-root\" deleted\nservice \"dotnet-non-root\" deleted<\/code><\/pre>\n
dotnet-monitor<\/code><\/h2>\n
dotnet-monitor<\/code><\/a> is a diagnostic tool for capturing diagnostic artifacts from running applications. We offer a dotnet\/monitor<\/a> container image for it. Does it work well with non-root hosting? Yes.<\/p>\n
The dotnet-monitor<\/code><\/a> sample demonstrates both ASP.NET and dotnet-monitor<\/code> running as non-root.<\/p>\n
Summary<\/h2>\n
You can switch to non-root hosting in Kubernetes with a few straightforward configuration changes. Your app will be more secure and more resilient to attack. This approach also brings your app into compliance with Kubernetes Pod hardening best practices. It’s a small change with a big impact for defense in depth.<\/p>\n
We hope that our container security initiative enables the entire .NET container ecosystem to switch to non-root hosting. We’re invested in .NET apps in the cloud being high-performance and safe.<\/p>\n","protected":false},"excerpt":{"rendered":"
Learn how to run .NET containers in Kubernetes as a non-root user.<\/p>\n","protected":false},"author":1312,"featured_media":51617,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[685,7509,7237,2904,7720,326],"tags":[7701,89,7730,7729],"class_list":["post-45310","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-dotnet","category-aspnetcore","category-containers","category-docker","category-linux","category-security","tag-dotnet-8","tag-kubernetes","tag-non-root","tag-rootless"],"acf":[],"blog_post_summary":"
Learn how to run .NET containers in Kubernetes as a non-root user.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/45310","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/users\/1312"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/comments?post=45310"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/45310\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media\/51617"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media?parent=45310"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/categories?post=45310"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/tags?post=45310"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}