Mount volumes as read-only to protect their contents from modification
ConfigMaps and Secrets referenced in a volume
and mounted in a container provide a writable filesystem. When a user chooses to add readOnlyRootFilesystem: true
to the container's securityContext
block via helm values, having the volumes mounted read/write provides a location which can be used to write arbitrary (potentially executable) files by malicious actors with sufficient privileges, despite the rest of the container's filesystem being mounted read-only.
Technically, yes, this is also the case without readOnlyRootFilesystem: true
, but the point here is that if I set that in helm values, I expect that gitlab agent would also have no other volumes which are writable unless gitlab-agent needs to write to them itself during runtime.
I have not found case where the gitlab agent needs write access to the volumes, and so in order to avoid situation described above, it's best to always mount volumes as read-only if they aren't intended to be modified after the container is started.
Closes: #4 (closed)