Have you set your security context recently?

You’d be shocked at how few people copy these few lines into their YAML in Kubernetes. Highly recommend you do this.

Why? Well, lets walk through them.

runAsNonRoot: self explanatory. Why would you want root permission inside this container? What possible good could come of that? is it because you need to bind to < 1024?  Maybe you want “cap_net_bind_service” instead. Or more likely you can just run your container on a port > 1024 since there’s some redirection occurring anyway. Is it just vanity keeping your http-container on port 80?

The second, well, this is a bit controversial. Maybe your container was built with a certain ‘user’ as the user inside it, and you want the GECOS name to match? I guess you can avoid this in some cases.

Side note: why not just have a USER line in the container build you ask? Well, what if someone removes that, you don’t want them getting into your infrastructure w/ that suddenly privileged container. This is your seatbelt.

As for the ‘capabilities: drop all’. Seems obvious, you can add specific ones back (e.g. the bind one we talked about above), but start empty and add back is better.

As for the read-only root. What good would come from writing inside the rootfs of your container? Its disposable after all. Make it hard for an attacker to get in and get around, give them a scorched earth policy.

OK, now this all seems common sense. But I bet the next helm chart you install has none of this. Check.

      securityContext:
        runAsNonRoot: true
        runAsUser: 10001
        capabilities:
          drop:
            - all
        readOnlyRootFilesystem: true