Hardening an ASP.NET container running on Kubernetes
source link: https://techcommunity.microsoft.com/t5/azure-developer-community-blog/hardening-an-asp-net-container-running-on-kubernetes/ba-p/2542224?WT_mc_id=DOP-MVP-4025064
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Hardening an ASP.NET container running on Kubernetes
In my day to day job, I often stumbled upon a surprising fact: many ASP.NET Core (or .NET 5) K8s deployments are too permissive when it comes to the execution context. Basically, most deployments are not hardened properly, and I see countless ASP.NET containers running as root. Admitedly, there is a lack of guidance from Microsoft in that matter. At the time of writing, I challenge you to find a single source of truth (feel free to add it in comment if I missed any), endorsed by Microsoft on how to to harden an ASP.NET Docker image. You'll rather stumble upon GitHub issues and questions here and there.
As you know, ASP.NET relies on the built-in Kestrel web server and most ASP.NET applications are either MVC, either Web APIs, meaning that they are unlikely going to leverage operating system level capabilities that require high privileges.
That said, if you take the simplest ASP.NET web API project and choose the default Visual Studio 2019 template, you'll end up with the following Dockerfile:
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1-buster-slim AS base
WORKDIR /app
EXPOSE 80
FROM mcr.microsoft.com/dotnet/core/sdk:3.1-buster AS build
WORKDIR /src
COPY ["simpleapi/simpleapi.csproj", "simpleapi/"]
RUN dotnet restore "simpleapi/simpleapi.csproj"
COPY . .
WORKDIR "/src/simpleapi"
RUN dotnet build "simpleapi.csproj" -c Release -o /app/build
FROM build AS publish
RUN dotnet publish "simpleapi.csproj" -c Release -o /app/publish
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "simpleapi.dll"]
If you build an image and run this, you must run it as root. If you don't, by requesting it specifically in your deployment through a securityContext:
securityContext:
runAsNonRoot: true You'll encounter the following issue:
Describing the pod with Kubectl quickly shows that the container tried to start as root:
Warning Failed 94s (x8 over 2m53s) kubelet, aks-agentpool-38789445-vmss000001 Error: container has runAsNonRoot and image will run as rootWhat K8s tells you is that the image wants to start as root because no other user has been defined, so it defaults to root. But, because you explicitely added a runAsNonRoot instruction, it can't start it. Never mind, just specify a user and it should work, right? Let's try:
securityContext:
runAsNonRoot: true
runAsUser: 1000
runAsGroup: 2000By the way, if you wonder, when no user is specified in the Docker image itself or through a securityContext, user 0 is assumed and 0 stands for root. Linux needs to have a user identifier (not name) as an input. Trying with the above config results in another error:
This time it goes further as the container starts, crashes and restarts. Looking at the container logs with Kubectl logs reveals the problem (shortened for brevity):
←[41m←[1m←[37mcrit←[39m←[22m←[49m: Microsoft.AspNetCore.Server.Kestrel[0]
Unable to start Kestrel.
System.Net.Sockets.SocketException (13): Permission deniedThis could make you think that being root is required to start Kestrel but that is not the culprit. The problem is the port number it tries to bind to, which in the default image, is either 80 either 443. Both ports are below 1024 and today, you must be root to bind to a port that is < 1024. In Linux, the alternative to bind to a low port while not being root is to use Linux capabilities. However, ambient capabilities are still not available in K8s. So, first take away is: do not use port 80 or 443 in your ASP.NET Core images. Whatever setup you are using, I don't see how you could justify to bind to either of these ports. Most webapps/APIs are:
So, I see no reason to stick to these ports. Therefore, the first thing to do is to pick another bunc of ports, right in the DockerFile. So, for example, you can simply achieve this with the following instructions in the Dockerfile (the same applies to 443 and TLS):
EXPOSE 8080
ENV ASPNETCORE_URLS=http://*:8080When changing the default port, you also need to instruct ASP.NET (core in this example) about it through an environment variable. Adding those two lines to our former DockerFile and deploying it with the above securityContext will result in an up and running ASP.NET container running as non-root. To enforce non-root, you may even do it right from the Dockerfile itself, yet, using another bunch of Docker instructions:
RUN addgroup --group friendlygroupname --gid 2000 \
&& adduser \
--uid 1000 \
--gid 2000 \
"friendlyusername"
RUN chown friendlyusername:friendlygroupname /app
USER friendlyusername:friendlygroupname If you build and push the new Docker image and redeploy it, you will have an up and running ASP.NET container, running with its own user and group objects.
This approach is even preferred because even if you ommit the security context in the K8s deployment, the container will be started with the user and group specified in the image, meaning as a rootless container. But is it enough to consider this hardened? Well, we are in a much better situation than with the default image because:
But, we can do even more than this. For example, depending on the ASP.NET distrib you work with, curl might be available in the container, facilitating attacks such as downloading a binary or shell file from a remote endpoint. Of course, you should always make sure that the egress traffic is controlled correctly, which goes beyond the management of the container itself. However, such attacks could not be done in a read-only file system because the binary/archive/shell could not be stored locally in the container. So, we might be tempted to add another line to our securityContext:
readOnlyRootFilesystem: trueWhich will cause the container to fail at startup. In the logs you'll find:
Failed to create CoreCLR, HRESULT: 0x80004005And that is because you should disable some debugging telemetry setting in the Dockerfile by adding an extra ENV statement:
ENV COMPlus_EnableDiagnostics=0Note that it depends on the base image (ASP.NET version) you use and it is still debated whether ASP.NET runs smoothly or not on a read-only filesystem. You might have edge cases where the system needs to buffer "stuff" on the filesystem. So, use it with caution and make sure you spot any potential issue during your integration tests.
Last but not least and because it never hurts, you should always drop all capabilities by default (full securityContext for clarity):
runAsNonRoot: true
runAsUser: 1000
runAsGroup: 2000
allowPrivilegeEscalation: false
privileged: false
readOnlyRootFilesystem: true
capabilities:
drop:
- allBecause if you don't bind to a low port, you will not even need NET_BIND_SERVICE and because should you still run a container as root, dropping all these capabilities will still prevent root from leveraging some system capabilities, making it harder for an attacker to harm your environment. Of course, if you are running edge cases, you may add some capabilities as needed, but removing all by default sounds like a good idea.
Is that all? Well, no! There is still something that help harden not the image, but the container itself. You should always define resource requests and limits to make sure a single container cannot take up all CPU and Memory of the node it runs on. That will also help you detect unexpected memory leaks.
Jul 14 2021 01:22 AM
Jul 14 2021 07:35 PM
Jul 15 2021 01:31 AM
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
%3CLINGO-SUB%20id%3D%22lingo-sub-2542224%22%20slang%3D%22en-US%22%3EHardening%20an%20ASP.NET%20container%20running%20on%20Kubernetes%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2542224%22%20slang%3D%22en-US%22%3E%3CP%3EIn%20my%20day%20to%20day%20job%2C%20I%20often%20stumbled%20upon%20a%20surprising%20fact%3A%20many%20ASP.NET%20Core%20(or%20.NET%205)%20K8s%20deployments%20are%20too%20permissive%20when%20it%20comes%20to%20the%20execution%20context.%20Basically%2C%20most%20deployments%20are%20not%20hardened%20properly%2C%20and%20I%20see%20countless%20ASP.NET%20containers%20running%20as%20root.%20Admitedly%2C%20there%20is%20a%20lack%20of%20guidance%20from%20Microsoft%20in%20that%20matter.%20At%20the%20time%20of%20writing%2C%20I%20challenge%20you%20to%20find%20a%20single%20source%20of%20truth%20(feel%20free%20to%20add%20it%20in%20comment%20if%20I%20missed%20any)%2C%20%3CEM%3Eendorsed%20by%20Microsoft%3C%2FEM%3E%20on%20how%20to%20to%20harden%20an%20ASP.NET%20Docker%20image.%20You'll%20rather%20stumble%20upon%20GitHub%20issues%20and%20questions%20here%20and%20there.%3C%2FP%3E%0A%3CP%3EAs%20you%20know%2C%20ASP.NET%20relies%20on%20the%20built-in%20Kestrel%20web%20server%20and%20most%20ASP.NET%20applications%20are%20either%20MVC%2C%20either%20Web%20APIs%2C%20meaning%20that%20they%20are%20unlikely%20going%20to%20leverage%20operating%20system%20level%20capabilities%20that%20require%20high%20privileges.%3C%2FP%3E%0A%3CP%3EThat%20said%2C%20if%20you%20take%20the%20simplest%20ASP.NET%20web%20API%20project%20and%20choose%20the%20default%20Visual%20Studio%202019%20template%2C%20you'll%20end%20up%20with%20the%20following%20Dockerfile%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%20class%3D%22lia-code-sample%20language-bash%22%3E%3CCODE%3EFROM%20mcr.microsoft.com%2Fdotnet%2Fcore%2Faspnet%3A3.1-buster-slim%20AS%20base%0AWORKDIR%20%2Fapp%0AEXPOSE%2080%0A%0AFROM%20mcr.microsoft.com%2Fdotnet%2Fcore%2Fsdk%3A3.1-buster%20AS%20build%0AWORKDIR%20%2Fsrc%0ACOPY%20%5B%22simpleapi%2Fsimpleapi.csproj%22%2C%20%22simpleapi%2F%22%5D%0ARUN%20dotnet%20restore%20%22simpleapi%2Fsimpleapi.csproj%22%0ACOPY%20.%20.%0AWORKDIR%20%22%2Fsrc%2Fsimpleapi%22%0ARUN%20dotnet%20build%20%22simpleapi.csproj%22%20-c%20Release%20-o%20%2Fapp%2Fbuild%0A%0AFROM%20build%20AS%20publish%0ARUN%20dotnet%20publish%20%22simpleapi.csproj%22%20-c%20Release%20-o%20%2Fapp%2Fpublish%0A%0AFROM%20base%20AS%20final%0AWORKDIR%20%2Fapp%0ACOPY%20--from%3Dpublish%20%2Fapp%2Fpublish%20.%0AENTRYPOINT%20%5B%22dotnet%22%2C%20%22simpleapi.dll%22%5D%0A%0A%3C%2FCODE%3E%3C%2FPRE%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EIf%20you%20build%20an%20image%20and%20run%20this%2C%20you%20must%20run%20it%20as%20root.%20If%20you%20don't%2C%20by%20requesting%20it%20specifically%20in%20your%20deployment%20through%20a%20securityContext%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%20class%3D%22lia-code-sample%20language-bash%22%3E%3CCODE%3EsecurityContext%3A%0A%20runAsNonRoot%3A%20true%20%20%20%20%20%3C%2FCODE%3E%3C%2FPRE%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EYou'll%20encounter%20the%20following%20issue%3A%3C%2FP%3E%0A%3CP%3E%3CSPAN%20class%3D%22lia-inline-image-display-wrapper%20lia-image-align-inline%22%20image-alt%3D%22stephaneey_0-1626175023077.png%22%20style%3D%22width%3A%20400px%3B%22%3E%3CIMG%20src%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fimage%2Fserverpage%2Fimage-id%2F295431i6148D566A5AD1758%2Fimage-size%2Fmedium%3Fv%3Dv2%26amp%3Bpx%3D400%22%20role%3D%22button%22%20title%3D%22stephaneey_0-1626175023077.png%22%20alt%3D%22stephaneey_0-1626175023077.png%22%20%2F%3E%3C%2FSPAN%3E%3C%2FP%3E%0A%3CP%3EDescribing%20the%20pod%20with%20Kubectl%20quickly%20shows%20that%20the%20container%20tried%20to%20start%20as%20root%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%20class%3D%22lia-code-sample%20language-bash%22%3E%3CCODE%3EWarning%20Failed%2094s%20(x8%20over%202m53s)%20kubelet%2C%20aks-agentpool-38789445-vmss000001%20Error%3A%20container%20has%20runAsNonRoot%20and%20image%20will%20run%20as%20root%3C%2FCODE%3E%3C%2FPRE%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EWhat%20K8s%20tells%20you%20is%20that%20the%20image%20wants%20to%20start%20as%20root%20because%20no%20other%20user%20has%20been%20defined%2C%20so%20it%20defaults%20to%20root.%20But%2C%20because%20you%20explicitely%20added%20a%20%3CEM%3ErunAsNonRoot%3C%2FEM%3E%20instruction%2C%20it%20can't%20start%20it.%20Never%20mind%2C%20just%20specify%20a%20user%20and%20it%20should%20work%2C%20right%3F%20Let's%20try%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%20class%3D%22lia-code-sample%20language-bash%22%3E%3CCODE%3EsecurityContext%3A%0A%20%20%20%20%20%20%20runAsNonRoot%3A%20true%20%20%20%20%20%20%20%0A%20%20%20%20%20%20%20runAsUser%3A%201000%0A%20%20%20%20%20%20%20runAsGroup%3A%202000%3C%2FCODE%3E%3C%2FPRE%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EBy%20the%20way%2C%20if%20you%20wonder%2C%20when%20no%20user%20is%20specified%20in%20the%20Docker%20image%20itself%20or%20through%20a%20securityContext%2C%20user%200%20is%20assumed%20and%200%20stands%20for%20root.%20Linux%20needs%20to%20have%20a%20user%20identifier%20(not%20name)%20as%20an%20input.%20Trying%20with%20the%20above%20config%20results%20in%20another%20error%3A%3C%2FP%3E%0A%3CP%3E%3CSPAN%20class%3D%22lia-inline-image-display-wrapper%20lia-image-align-inline%22%20image-alt%3D%22stephaneey_1-1626175696989.png%22%20style%3D%22width%3A%20400px%3B%22%3E%3CIMG%20src%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fimage%2Fserverpage%2Fimage-id%2F295432iD0C4482CA431535E%2Fimage-size%2Fmedium%3Fv%3Dv2%26amp%3Bpx%3D400%22%20role%3D%22button%22%20title%3D%22stephaneey_1-1626175696989.png%22%20alt%3D%22stephaneey_1-1626175696989.png%22%20%2F%3E%3C%2FSPAN%3E%3C%2FP%3E%0A%3CP%3EThis%20time%20it%20goes%20further%20as%20the%20container%20starts%2C%20crashes%20and%20restarts.%20Looking%20at%20the%20container%20logs%20with%20Kubectl%20logs%20reveals%20the%20problem%20(shortened%20for%20brevity)%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%20class%3D%22lia-code-sample%20language-bash%22%3E%3CCODE%3E%E2%86%90%5B41m%E2%86%90%5B1m%E2%86%90%5B37mcrit%E2%86%90%5B39m%E2%86%90%5B22m%E2%86%90%5B49m%3A%20Microsoft.AspNetCore.Server.Kestrel%5B0%5D%0A%20%20%20%20%20%20Unable%20to%20start%20Kestrel.%0ASystem.Net.Sockets.SocketException%20(13)%3A%20Permission%20denied%3C%2FCODE%3E%3C%2FPRE%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EThis%20could%20make%20you%20think%20that%20being%20root%20is%20required%20to%20start%20Kestrel%20but%20that%20is%20not%20the%20culprit.%20The%20problem%20is%20the%20port%20number%20it%20tries%20to%20bind%20to%2C%20which%20in%20the%20default%20image%2C%20is%20either%2080%20either%20443.%20Both%20ports%20are%20below%201024%20and%20today%2C%20you%20must%20be%20%3CEM%3Eroot%3C%2FEM%3E%20to%20bind%20to%20a%20port%20that%20is%20%26lt%3B%201024.%20In%20Linux%2C%20the%20alternative%20to%20bind%20to%20a%20low%20port%20while%20not%20being%20root%20is%20to%20use%20Linux%20capabilities.%20However%2C%20ambient%20capabilities%20%3CA%20href%3D%22https%3A%2F%2Fgithub.com%2Fkubernetes%2Fkubernetes%2Fissues%2F56374%22%20target%3D%22_self%22%20rel%3D%22noopener%20noreferrer%22%3Eare%20still%20not%20available%3C%2FA%3E%20in%20K8s.%20So%2C%20first%20take%20away%20is%3A%20do%20not%20use%20port%2080%20or%20443%20in%20your%20ASP.NET%20Core%20images.%20Whatever%20setup%20you%20are%20using%2C%20I%20don't%20see%20how%20you%20could%20justify%20to%20bind%20to%20either%20of%20these%20ports.%20Most%20webapps%2FAPIs%20are%3A%3C%2FP%3E%0A%3CUL%3E%0A%3CLI%3EProxied%20by%20a%20K8s%20Service%20which%20can%20listen%20to%2080%20and%20forward%20to%208080%20for%20example%2C%20same%20with%20443%20of%20course%3C%2FLI%3E%0A%3CLI%3EProxied%20by%20a%20sidecar%20container%2C%20which%20is%20part%20of%20a%20service%20mesh%20or%20solutions%20such%20as%20Dapr.%20Here%20again%2C%20the%20proxy%20can%20easily%20fallback%20to%208080%20or%204433%3C%2FLI%3E%0A%3C%2FUL%3E%0A%3CP%3ESo%2C%20I%20see%20no%20reason%20to%20stick%20to%20these%20ports.%20Therefore%2C%20the%20first%20thing%20to%20do%20is%20to%20pick%20another%20bunc%20of%20ports%2C%20right%20in%20the%20DockerFile.%20So%2C%20for%20example%2C%20you%20can%20simply%20achieve%20this%20with%20the%20following%20instructions%20in%20the%20Dockerfile%20(the%20same%20applies%20to%20443%20and%20TLS)%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%20class%3D%22lia-code-sample%20language-bash%22%3E%3CCODE%3EEXPOSE%208080%0AENV%20ASPNETCORE_URLS%3Dhttp%3A%2F%2F*%3A8080%3C%2FCODE%3E%3C%2FPRE%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EWhen%20changing%20the%20default%20port%2C%20you%20also%20need%20to%20instruct%20ASP.NET%20(core%20in%20this%20example)%20about%20it%20through%20an%20environment%20variable.%20Adding%20those%20two%20lines%20to%20our%20former%20DockerFile%20and%20deploying%20it%20with%20the%20above%20%3CEM%3EsecurityContext%3C%2FEM%3E%20will%20result%20in%20an%20up%20and%20running%20ASP.NET%20container%20running%20as%20non-root.%20To%20enforce%20non-root%2C%20you%20may%20even%20do%20it%20right%20from%20the%20Dockerfile%20itself%2C%20yet%2C%20using%20another%20bunch%20of%20Docker%20instructions%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%20class%3D%22lia-code-sample%20language-bash%22%3E%3CCODE%3ERUN%20addgroup%20--group%20friendlygroupname%20--gid%202000%20%5C%0A%26amp%3B%26amp%3B%20adduser%20%5C%20%20%20%20%0A%20%20%20%20--uid%201000%20%5C%0A%20%20%20%20--gid%202000%20%5C%0A%20%20%20%20%22friendlyusername%22%20%0A%0ARUN%20chown%20friendlyusername%3Afriendlygroupname%20%20%2Fapp%0AUSER%20friendlyusername%3Afriendlygroupname%20%3C%2FCODE%3E%3C%2FPRE%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EIf%20you%20build%20and%20push%20the%20new%20Docker%20image%20and%20redeploy%20it%2C%20you%20will%20have%20an%20up%20and%20running%20ASP.NET%20container%2C%20running%20with%20its%20own%20user%20and%20group%20objects.%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CSPAN%20class%3D%22lia-inline-image-display-wrapper%20lia-image-align-inline%22%20image-alt%3D%22stephaneey_0-1626176706154.png%22%20style%3D%22width%3A%20400px%3B%22%3E%3CIMG%20src%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fimage%2Fserverpage%2Fimage-id%2F295435i61AC98E75C70C958%2Fimage-size%2Fmedium%3Fv%3Dv2%26amp%3Bpx%3D400%22%20role%3D%22button%22%20title%3D%22stephaneey_0-1626176706154.png%22%20alt%3D%22stephaneey_0-1626176706154.png%22%20%2F%3E%3C%2FSPAN%3E%3C%2FP%3E%0A%3CP%3EThis%20approach%20is%20even%20preferred%20because%20even%20if%20you%20ommit%20the%20security%20context%20in%20the%20K8s%20deployment%2C%20the%20container%20will%20be%20started%20with%20the%20user%20and%20group%20specified%20in%20the%20image%2C%20meaning%20as%20a%20rootless%20container.%20But%20is%20it%20enough%20to%20consider%20this%20hardened%3F%20Well%2C%20we%20are%20in%20a%20much%20better%20situation%20than%20with%20the%20default%20image%20because%3A%3C%2FP%3E%0A%3CUL%3E%0A%3CLI%3EThe%20non-root%20user%20will%20be%20restricted%20even%20if%20the%20container%20itself%20is%20privileged%20in%20the%20K8s%20deployment%20(which%20should%20never%20be%20the%20case%20of%20an%20ASP.NET%20app%20by%20the%20way)%3C%2FLI%3E%0A%3CLI%3EThe%20non-root%20user%20will%20be%20restricted%20in%20the%20container%20itself.%20For%20example%2C%20installing%20extra%20packages%20through%20%3CEM%3Eapt-get%3C%2FEM%3E%20will%20be%20denied%2C%20which%20could%20make%20it%20harder%20to%20setup%20tools%20in%20a%20remote%20code%20execution%20attack.%20By%20the%20way%2C%20the%20default%20ASP.NET%20base%20image%20does%20not%20ship%20with%20many%20tools%2C%20which%20makes%20it%20harder%20(good%20thing)%20to%20discover%20and%20run%20attacks.%20If%20on%20top%20of%20it%2C%20you%20make%20sure%20that%20no%20extra%20tools%20can%20be%20installed%2C%20you're%20already%20preventing%20most%20attacks.%3C%2FLI%3E%0A%3C%2FUL%3E%0A%3CP%3EBut%2C%20we%20can%20do%20even%20more%20than%20this.%20For%20example%2C%20depending%20on%20the%20ASP.NET%20distrib%20you%20work%20with%2C%20curl%20might%20be%20available%20in%20the%20container%2C%20facilitating%20attacks%20such%20as%20downloading%20a%20binary%20or%20shell%20file%20from%20a%20remote%20endpoint.%20Of%20course%2C%20you%20should%20always%20make%20sure%20that%20the%20%3CEM%3Eegress%3C%2FEM%3E%20traffic%20is%20controlled%20correctly%2C%20which%20goes%20beyond%20the%20management%20of%20the%20container%20itself.%20However%2C%20such%20attacks%20could%20not%20be%20done%20in%20a%20read-only%20file%20system%20because%20the%20binary%2Farchive%2Fshell%20could%20not%20be%20stored%20locally%20in%20the%20container.%20So%2C%20we%20might%20be%20tempted%20to%20add%20another%20line%20to%20our%20securityContext%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%20class%3D%22lia-code-sample%20language-bash%22%3E%3CCODE%3EreadOnlyRootFilesystem%3A%20true%3C%2FCODE%3E%3C%2FPRE%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EWhich%20will%20cause%20the%20container%20to%20fail%20at%20startup.%20In%20the%20logs%20you'll%20find%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%20class%3D%22lia-code-sample%20language-bash%22%3E%3CCODE%3EFailed%20to%20create%20CoreCLR%2C%20HRESULT%3A%200x80004005%3C%2FCODE%3E%3C%2FPRE%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EAnd%20that%20is%20because%20you%20should%20disable%20some%20debugging%20telemetry%20setting%20in%20the%20Dockerfile%20by%20adding%20an%20extra%20ENV%20statement%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%20class%3D%22lia-code-sample%20language-basic%22%3E%3CCODE%3EENV%20COMPlus_EnableDiagnostics%3D0%3C%2FCODE%3E%3C%2FPRE%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3ENote%20that%20it%20depends%20on%20the%20base%20image%20(ASP.NET%20version)%20you%20use%20and%20it%20is%20still%20debated%20whether%20ASP.NET%20runs%20smoothly%20or%20not%20on%20a%20read-only%20filesystem.%20You%20might%20have%20edge%20cases%20where%20the%20system%20needs%20to%20buffer%20%22stuff%22%20on%20the%20filesystem.%20So%2C%20use%20it%20with%20caution%20and%20make%20sure%20you%20spot%20any%20potential%20issue%20during%20your%20integration%20tests.%3C%2FP%3E%0A%3CP%3ELast%20but%20not%20least%20and%20because%20it%20never%20hurts%2C%20you%20should%20always%20drop%20all%20capabilities%20by%20default%20(full%20securityContext%20for%20clarity)%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%20class%3D%22lia-code-sample%20language-bash%22%3E%3CCODE%3ErunAsNonRoot%3A%20true%0A%20runAsUser%3A%201000%0A%20runAsGroup%3A%202000%0A%20allowPrivilegeEscalation%3A%20false%0A%20privileged%3A%20false%0A%20readOnlyRootFilesystem%3A%20true%0A%20capabilities%3A%0A%20%20drop%3A%0A%20%20%20-%20all%3C%2FCODE%3E%3C%2FPRE%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EBecause%20if%20you%20don't%20bind%20to%20a%20low%20port%2C%20you%20will%20not%20even%20need%20NET_BIND_SERVICE%20and%20because%20should%20you%20still%20run%20a%20container%20as%20root%2C%20dropping%20all%20these%20capabilities%20will%20still%20prevent%20root%20from%20leveraging%20some%20system%20capabilities%2C%20making%20it%20harder%20for%20an%20attacker%20to%20harm%20your%20environment.%20Of%20course%2C%20if%20you%20are%20running%20edge%20cases%2C%20you%20may%20add%20%3CA%20href%3D%22https%3A%2F%2Fgithub.com%2Ftorvalds%2Flinux%2Fblob%2Fmaster%2Finclude%2Fuapi%2Flinux%2Fcapability.h%22%20target%3D%22_self%22%20rel%3D%22noopener%20noreferrer%22%3Esome%20capabilities%3C%2FA%3E%20as%20needed%2C%20but%20removing%20all%20by%20default%20sounds%20like%20a%20good%20idea.%26nbsp%3B%3C%2FP%3E%0A%3CP%3EIs%20that%20all%3F%20Well%2C%20no!%20There%20is%20still%20something%20that%20help%20harden%20not%20the%20image%2C%20but%20the%20container%20itself.%20You%20should%20always%20define%20resource%20requests%20and%20limits%20to%20make%20sure%20a%20single%20container%20cannot%20take%20up%20all%20CPU%20and%20Memory%20of%20the%20node%20it%20runs%20on.%20That%20will%20also%20help%20you%20detect%20unexpected%20memory%20leaks.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-TEASER%20id%3D%22lingo-teaser-2542224%22%20slang%3D%22en-US%22%3E%3CP%3EWonder%20how%20to%20harden%20an%20ASP.NET%20container%20running%20in%20Kubernetes%3F%20Come%20and%20read%20this!%3C%2FP%3E%3C%2FLINGO-TEASER%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2545879%22%20slang%3D%22en-US%22%3ERe%3A%20Hardening%20an%20ASP.NET%20container%20running%20on%20Kubernetes%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2545879%22%20slang%3D%22en-US%22%3E%3CP%3EThanks%20for%20the%20article.%20I%20thought%20that%20the%20default%20aspnet%20Dockerfile%20is%20%22good%20enough%22.%3C%2FP%3E%3CP%3EThere%20is%20definitely%20something%20to%20think%20about%20my%20current%20Dockerfile%20in%20production.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2550465%22%20slang%3D%22en-US%22%3ERe%3A%20Hardening%20an%20ASP.NET%20container%20running%20on%20Kubernetes%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2550465%22%20slang%3D%22en-US%22%3E%3CP%3EThis%20is%20helpful.%20We%20can%20prevent%20many%20attacks%20by%20having%20restricted%20access.%20Thanks%3C%2FP%3E%3C%2FLINGO-BODY%3E
Jul 13 2021 10:11 AM
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK