Skip to content

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)

Edited by Thomas Spear

Merge request reports