readOnlyRootFilesystem needs a higher score than 1

[huornlmj]

Describe the bug
"ReadOnlyRootFilesystem" is currently only awarded a +1 score despite it being one of the most effective mitigations against adversaries. As the official Kubesec documentation states:

"Without a writable filesystem the attack surface is dramatically reduced."

To Reproduce
Steps to reproduce the behaviour:

1. Create a pod spec that does not use the .securityContext .readOnlyRootFilesystem == true
2. Scan the pod spec with Kubesec.
3. Observe it being shown as an advisory with a +1 awarded.

Expected behaviour
The value of this needs to be reevaluated and given a much higher score. I suggest making it comparable to .securityContext .runAsNonRoot == true which currently awards 10 points.

[06kellyjac]

Yeah agreed, we can probably boost it.
Although I think running as non-root is probably a bigger deal as if your rootfs has sensible permissions most of that should be non-writable for you as non-root anyway, and if you have some other writable mount you'd still have somewhere to write with a readonly rootfs.

I'll have a chat with some colleagues at some point :)

[huornlmj]

ok great! Consider this attack BTW, to compare running as non-root against read only FS. If, as an attacker, I gain a remote shell (e.g. via a revshell for example) into a container that has a read-only mounted fs, then it is trickier for me to get attack tools into the container, like linpeas. But if the fs is read & write then I can get linpeas or Peirates in there and they will then tell me (the attacker) all of the available potential methods to escalate to root and possible escape anyway, whether the container is running as root or not.