2020-12 - I did my first Capture The Flag (CTF) experience illustrating those concepts explained on this article, you could find more information here

While preparing my presentation with Maxime Coquerel for our 16 Security Best Practices with Kubernetes on Azure (AKS) presentation in French, I took the opportunity to learn about the Pod Security Context in Kubernetes. Here, in this blog article, are my learnings.

First of all I went through the official Kubernetes documentation: Configure a Security Context for a Pod or Container.

From there I did some research to see how I could apply this for my own projects, for example myblog - nginx and MyMonthlyBlogArticle.Bot - dotnetcore.

And I found these very insightful resources:

So here are the results of my own implementations based on this:

  • PR to implement this with myblog
    • Dockerfile to have the official base image nginxinc/nginx-unprivileged
    • Container’s port as 8080 instead of 80
    • podSecurityContext with securityContext.capabilities.drop: all, runAsNonRoot: true, allowPrivilegeEscalation: false, automountServiceAccountToken: false and readOnlyRootFilesystem: true
    • Mount tmp as emptyDir on Kubernetes
  • PR to implement this with MyMonthlyBlogArticle.Bot
    • Dockerfile to have these environment variables: ENV ASPNETCORE_URLS=http://+:5000 and COMPlus_EnableDiagnostics=0
    • Container’s port as 5000 instead of 80
    • podSecurityContext with securityContext.capabilities.drop: all, runAsNonRoot: true, allowPrivilegeEscalation: false, automountServiceAccountToken: false and readOnlyRootFilesystem: true

Notes: you could locally test your Docker container with:

  • docker run --read-only --cap-drop=ALL --user=1000 to anticipate few options on Kubernetes listed above
  • docker diff on your running container to see if there is any folder it is writing in that you could mount as emptyDir on Kubernetes
  • If you are using Istio, you will get an issue with the istio-proxy sidecar if you are using automountServiceAccountToken: false. The sidecar needs a service account token to talk to the control plane

Now on a policy or governance standpoint, how to control this across your kubernetes deployments? That’s where you could Use admission controllers to enforce policy.

As an illustration, you could also read here about the CVE-2020-14386, uses the CAP_NET_RAW capability of the Linux kernel to cause memory corruption, allowing an attacker to gain root access when they should not have. And that’s also a good opportunity to learn more about the investments and innovations Google is doing on an open source and security perspectives: the gVisor project is a great example.

Hope you enjoyed and learned something with this blog article and you will be able to leverage these resources for your own context and security posture!

Cheers! ;)